One of the first questions I ask when joining a new team is: Where do code reviews happen?
The answer, and experience of joining in on such reviews, instantly tells you a lot about a team:
And so very much more.
As a technical leader and manager, code reviews and checkins are literally the heartbeat of your team. Reading them religiously – although admittedly time consuming – is an absolute requirement for truly understanding what the team is doing and its strengths and weaknesses. If you’re joining a new team, it puts you right at the heart of the engineering dialogue, and in a position to start fixing whatever is broken (opening it up, encouraging debate, changing technical direction, etc). When it comes time to calibration meetings, you’ll already have a deep awareness of who’s actually getting stuff done, and who is writing the quality code. You’ll see the technical leaders very visibly, including who is really setting the pace for the rest of the team (coding output, good feedback, work ethic, etc).
And from time to time, you may even find the opportunity to offer up a small suggestion yourself. Some might see this as micromanagement, however I’ve found that developers sincerely appreciate when their boss or boss’s boss or whatever really cares enough to take the time to understand their work at this level of detail.
There’s also the converse of this, which is that it helps to keep the team on its toes.
I even recommend that other developers on the team go out of their way to read code reviews and checkins in areas totally unrelated to their day jobs. This helps for the same reason it helps managers: you can learn from others, understand how the team operates and the expected level of output amongst different peer groups (or even those more senior than you), pick up tips and tricks, and so on. Even though I manage a group focused on a developer platform, you bet I go out of my way to read changes to device drivers, kernel, filesystem, networking, browser, etc. I always learn something new.
Now, of course, reading the code doesn’t tell you everything. It won’t give you a complete picture of the design and architecture. It won’t tell you who is going out of their way to collaborate with the team and helping others with their designs behind closed doors. It won’t always tell you who is not a team player (although more often than not it will). It won’t tell you whose code is most effective when it lands in the hands of customers. All of these things are critical, and must not become blind spots, so you’ll need to rely on other data points to supplement the code-oriented perspective.
But I really do believe that reading code is the most effective way to understand the inner workings of your team at a very intimate level. And hey, as the hair gets pointier over time, at least you can fantasize that it is you who is writing it ;-) So much code, so little time!