Having worked in a centralised application support team I have had the opportunity to study the personality traits that make a good fit for support and which don’t. When I say support I am talking about supporting the operation of an application in production, whether it is in a centralised team or in a dev ops team that supports what it builds.
The Freedom Quadrant
What is it about programming that most programmers love? Creativity, problem-solving, analysis and critical thinking are just a few. However, when a senior developer explains to a junior, to the letter, how to implement something, we are taking away those great things about programming from the junior and we are taking away the opportunity for learning. But that doesn’t mean that we should give free rein to anyone in the team to implement solutions as they wish. It all depends on the level of the developer and the complexity of the problem/solution space.
Logging Query Language (LQL) – a DSL for Log Analytics
LQL came about because of a log analytics platform that I developed for Vueling Airlines. Being a backend developer and a self-confessed newbie at front end (HTML, CSS and Javascript), I originally created LQL in order to avoid having to develop complex front end code for generating queries. I decided that instead I would create a Domain Specific Language (DSL) that would allow users to write the queries and all I would need to provide was a text area.
Bitching will erode your team
"We"
As a team leader you are directly responsible for the moral and attitudes of your team. One of the most important things you can do is strive for an attitude of team positivity, comradery and togetherness. If you get this right then you are on track to having a successful team, get this wrong and no matter what else you do you’ll hit a wall and you won’t be able to progress. Not to mention that working in a team that likes each other and believes in what they do is really fun and rewarding.
Breaking your own code and designs
Most developers start out their career with an aversion to knowing the failure modes of the software that they write. They treat the software that they write as their baby, and don't like to see it get hurt. This isn't necessarily a conscious decision but more a subconscious mind-set. So when I am coaching a junior, one of the things I concentrate on is breaking them out of this mind-set.
Make mini technical leads
In a previous team of mine we created mini tech leads, this entailed taking a mid-range developer and making them responsible for a junior. So that means the mini tech lead is the first port of call for the junior when they have problems or questions. Mini tech leads need to perform code reviews with the junior and work hard to iron out early problems. The technical team lead coaches the mini tech lead and reviews the code reviews of the mini tech lead. The responsibility of the team lead has only changed in that they are now coaching a select few on technical leadership.
Code analysis rules versus training and coaching
I have an ongoing and friendly disagreement with colleagues over the value of code analysis rules and training. I focus part of my time on training and coaching as I feel that this is a great investment both in people and also in the quality of the software that is developed. The argument of my colleagues is that training needs to be repeated over and over again in order to cover the large developer base and as new people arrive. Also you can do a training session with a development team but that doesn't stop them from committing bad code.
Code Analysis Rules and the Click Through Culture
Code analysis rules to me are a bit contentious and I often have friendly disagreements with my colleagues responsible for developing custom in-house code analysis rules. I am not an expert in code analysis and have never written one but as a technical lead I have seen them in action daily and have a few opinions about them.
Being Open, Sharing Your Knowledge
If you're a team lead then being open is part of your job description, if you're not a team lead but want to be one then being open will help you get there. Sharing knowledge isn't just for team leads and senior developers, it is for everyone and should be part of the team mind-set. Sharing your knowledge with other people makes your team and organisation more successful, it makes you more successful and helps you build relationships with others. I cannot recommend more highly sharing your knowledge openly with others.