> They can request a review if they want somebody else to take another look at their code.
This can work sometimes and with some groups of engineers, but the engineers I worked with in my career who most needed this (1) would never ask for another set of eyes and (2) were the exact type of person who think a code review equals "people don't trust me."
When I started at my current large tech company as a senior software engineer, I learned a ton from having "more junior" engineers review my code. I also learned a ton from reviewing other people's code. Even now that I have the fancy title of Principal Software Engineer, if I want to make a change to our team's code, I need two ship-its from my teammates, same as everyone else. It's not about "not being trusted," it's about earning trust of others by not pretending your poop doesn't smell.
> Code reviews aren't high priority for engineers.
Well there's your problem. On teams I've been on that do code reviews well, code reviews are considered a high priority. When code reviews are given high priority, and when engineers take the time to plan their work so that changes are small enough to understand, code reviews really don't take that long and are not a blocker to productivity.
> It's up to you and your colleagues to set the rules for your team. Don't adopt best practices in a dogmatic fashion. Rather, ask yourself if the circumstances of others apply to you.
This is true - companies shouldn't blindly copy practices from other companies. I have been a part of teams before that didn't have required code reviews and were still effective, but this required a unique set of circumstances in which all engineers were pretty senior, and so we were doing a lot of owning features end-to-end. It is fun to be part of a team like that, but it doesn't scale very well.
What this article also doesn't address is that reviewing code is its own skill, and many engineers are not naturally good at it. Just as it is bad to blindly copy other companies, it's also not great to blindly equate "we're not good at a thing" with "this thing isn't useful."
This can work sometimes and with some groups of engineers, but the engineers I worked with in my career who most needed this (1) would never ask for another set of eyes and (2) were the exact type of person who think a code review equals "people don't trust me."
When I started at my current large tech company as a senior software engineer, I learned a ton from having "more junior" engineers review my code. I also learned a ton from reviewing other people's code. Even now that I have the fancy title of Principal Software Engineer, if I want to make a change to our team's code, I need two ship-its from my teammates, same as everyone else. It's not about "not being trusted," it's about earning trust of others by not pretending your poop doesn't smell.
> Code reviews aren't high priority for engineers.
Well there's your problem. On teams I've been on that do code reviews well, code reviews are considered a high priority. When code reviews are given high priority, and when engineers take the time to plan their work so that changes are small enough to understand, code reviews really don't take that long and are not a blocker to productivity.
> It's up to you and your colleagues to set the rules for your team. Don't adopt best practices in a dogmatic fashion. Rather, ask yourself if the circumstances of others apply to you.
This is true - companies shouldn't blindly copy practices from other companies. I have been a part of teams before that didn't have required code reviews and were still effective, but this required a unique set of circumstances in which all engineers were pretty senior, and so we were doing a lot of owning features end-to-end. It is fun to be part of a team like that, but it doesn't scale very well.
What this article also doesn't address is that reviewing code is its own skill, and many engineers are not naturally good at it. Just as it is bad to blindly copy other companies, it's also not great to blindly equate "we're not good at a thing" with "this thing isn't useful."