I was recently talking to a developer who had just been promoted to tech lead. They were asking what they should be doing differently now. I suggested the first things I’d focus on are that their job is now…
- less about delivering code and more about growing the skills of the other developers
- focused on the overall quality and architecture and not just of the pieces he personally touches
One way of tackling both of these is to do code reviews of everything and providing comprehensive feedback. The problem with this is that they’ll always be reactive, not proactive. They’ll be looking at work after it’s done and trying to make sense of the thinking that went into it.
A better way is to actively work with the other developers on the code. To write the code together so that each of you understands what the other is thinking and so that you can provide feedback and corrections in the moment. This is a far more effective form of peer review than looking at already completed work.
Pair and ensemble programming at the two ways I suggested they start. Actively work together and learn together. Not only will the work get done faster than with after-the-fact reviews, it will likely be of higher quality1 and more enjoyable.
-
See Pair Programming Illuminated for the formal research on pair programming ↩