As a tech team lead, how should I handle team members' coding mistakes and bad practices? [duplicate]

Question

I'm a tech team leader on a team of about 5 developers. The team size is somewhat dynamic as team members periodically leave for other projects and others join the team from other projects.

Periodically I stumble upon my team members' code, either when making modifications to it, writing something nearby, or just reviewing their code. Sometimes (often enough to write this post, I guess) their code is poorly written, with either small mistakes (like converting two Date objects to strings in order to compare them) or larger ones (writing 2+ almost identical medium-to-large sized functions with only one line differences, instead of one function that can handle both cases.)

What's the best way to improve their skills and point out these mistakes to them? Sometimes I go over these segments of code with them, explaining why they should be written differently. But I don't want to be nitpicky and have them come over too often to review their code. Are code reviews the answer here? If so, how should they be organized? Should they include all team members or be individual? How often should they be held? Any other advice?

There is another question that reads similar, but it is actually different, because in addition to being curious about code reviews, I'd also like to know of other possible ways of improving my team members' coding skills. Also, deadlines don't play a role in my question because we can easily review and/or fix the code either before or after an upcoming version delivery.

Answer 1

There are a few things you can do for this situation. First, do what you can to have a rulebook to refer them to. In other words, when things like this come up, it's best to say, "Have a look at page 6 of the style guide." Or, "Here's a link to a website that will explain something I want you to know," and save that link for your library. As a tech lead, its part of your job to avoid technical debt, so that's your obligation to them.

Secondly, rather than point to what they've done wrong, ask them questions about their own code. For example, my mentor caught me copying arrays when I didn't need to, so he asked me, "What do you suppose this code here is really doing?" We had a culture of mutual respect that made questions like that stimulating, rather than nit-picky.

If you govern from policy, maintain your role as the gatekeeper, and treat people respectfully, the good employees will love it and the bad ones will find another job. Remember to praise publicly but criticize in private. And feedback is a gift; the good coders will tell you how you're doing if you ask them.

Answer 2

Here's my thoughts on code reviews.

Great idea in theory but you have to manage things carefully. Programmers are creative, egotistical & can be extremely thin skinned. An open team code review can all too easily turn into the Roman Colosseum. Coders can pick each other's work to pieces viciously and unproductively. Even if you do it one-on-one it can still turn into a negative experience. Gavin's advice about criticising in private is great advice and something that's hard to maintain when there are open code reviews.

Gavin's (again) suggestion about writing a style guide or coding standards document is again great but you have to have the authority to enforce it. I strongly suggest finding a good model online and adapting that otherwise there will be blood between factions of those who put the opening "{" on the same line and those who put it on its' own line etc. I have seen (seriously) a command-line code formatting tool built into the check-in workflow to enforce the company style (good - I suppose) but then also saw renegade coders at the same company use the same tool with different style parameters to format the code "their way" on check-out (not so good).

On to the new content, buy a library of good books about programming e.g. "Clean Code", "Clean Coder", and "Code Complete" and try to start a culture of learning and improvement.

Answer 3

I'm not a team lead, so I haven't used that in practice.
But, in my view a healthy contest is the way to go.
Have your developers solve a challenge unrelated to work. Same challenge for all developers.
Make sure you explain beforehand what makes a good solution (short functions, meaningful names, efficiency etc.).
When everybody is done, vote for the best implementation.
The fact that everyone is working on the same problem will allow deeper discussions, since everybody has thought about the solution.
The fact that it's not work related will reduce anxiety of failure and make people more responsive to critique.
Making such contents a tradition will gradually improve coding skills of entire team without the need to go through code review process.