Saw a tweet that said a tech lead should review all code and have final say for approving it. I couldn’t disagree more. Beyond the implied fault & blame culture, this is asking for bottlenecks, messed up power dynamics, & lack of shared ownership.
If your team culture assigns blame for bugs or tech debt, that is something to fix, not enable further by escalating it. Bugs and tech debt are a reality of this industry. And to pretend that they are all avoidable and someone’s fault is naive.
A bug may happen because of badly defined requirements. Or clear requirements and poor communication. Or churn in your staffing, pair rotations, or just interrupting a dev’s flow.
Yes, we should be testing our code (yay unit tests!) but that won’t catch every bug and neither will the “expert” tech lead who now has to review every line of code. Sorry, but no one can stay attentive for more than a couple hundred lines.
Tech debt may occur because of a tight deliverable timeline or assumptions that had to be made in order to move forward. Or a lack of information. To assume that a code review from the lead solves this problem is absurd.
As a tech lead, I’m sharing the project experience with the team. If we have to incur some tech debt to get something out the door or because we don’t have all the info, I’m not going to be able to do a better code review than anyone else.
The tech lead should want to foster a safe environment for everyone on the team to speak up about bugs and tech debt. If everyone is afraid of a fault & blame culture, bugs go longer without being fixed and tech debt goes longer without being refactored and paid down.
Moving past assigning fault for unavoidable realities of software development, what does it look like to have a single person responsible for final say over the code?
Idk about you but as a lead at a small company, my time is split between delivery and high-level product discussions. It’s just part of the job. If my team relied on my final approval for everything, our merge times would slow down. I don’t want to be a bottleneck.
And just because someone is tech lead does not mean that they’re all-knowing. More brains are better than one and frankly, I love crowdsourcing our code reviews because each member of the team strengthens our code in a different way.
I don’t want to lose out on a team member’s feedback because I get a big head and start to think my opinion is the only one that matters (a natural side effect of having final say).
And finally, let’s talk shared ownership. To all the naysayers who want to point out that when everyone does code reviews, no one cares and everything is “LGTM”, I would argue that you don’t actually have shared ownership.
When every member of the team has equal say and equal responsibility for the code, every member is committed to the quality of the code base. Everyone wants to write high quality code for their team members and wants their team members to write high quality code for them.
But you can’t just pay lip service to this. You need to walk the walk. Every piece of feedback has equal weight regardless of who left it and every person can review any PR regardless of who opened it.
Just this week, the newest dev on our team left great feedback in a senior dev’s PR about how to remove an if statement in a render function and instead use a variable for which component to render. Small suggestion, but small suggestions add up to much cleaner code.
Now from a logistics standpoint, it’s not realistic that every team member review every PR but the important part is they could and their feedback would be welcome. How each team implements the actual approval process is another thread for another day.
I’ve shared my thoughts on team code review in the past and received pushback based on disengaged or low-performing team members. To that I would ask what support are you giving them to solve those problems? I don’t think those are symptoms of a faulty code review process.
They’re symptoms of a faulty culture or support system. If you fix those, I really believe shared ownership of your code and code reviews results in much higher code quality.
The team, not the tech lead, should be responsible for code reviews.
</end>
</end>
