This week I've been doing a lot of code review and I must say, it's always.. an acquired taste. The more you do, the more comfortable you feel, and in turn, the more enjoyable (or bearable) it can be. Over the past 7 years, I've been embedded on teams that don't have any concept of QA or code review. That was particularly earlier in my career. Since then, I've been fortunate to experience a wide range of software development team structures, and many of which have had rather rigorous code review cultures. This probably goes without being said, but learning how to read and understand code quickly prevailed as one of the most useful skills you could have as an individual contributor.

On the team I'm currently embedded on, code review is a bit of a hot topic. About half of the developers and leadership tend to think that manual code review is a thing of the past. We have automated review bots that run in GitHub, and we have refined a couple of different skills for developers reviewing code locally too. While everyone is using these things, we still have a portion of the developers that are bought in on the important of proper manual code review too. Because of the differing mindsets on the project, we don't exactly have a consistent process across the board right now. All that is to say that things are clearly changing; a year ago manual code review (even if you use a skill), was less of a topic to debate, it just came with the territory.

Over the past few months, I've been hearing more and more chatter online and at work about how the days of manually reviewing code are behind us. I've even heard a fair amount of, "If you're still reviewing code manually, you're falling behind. Your NGMI! ". While I think that is a dangerous sentiment for every engineer to live by, I can definitely see that things are changing and moving in that direction more than ever. I do believe that if you are leaning into automatic code review, you better have a really good code review setup. It should ideally be self-improving, it should be connected to the right systems to gather context, and it should be fully tuned into the codebase patterns. Setting up the perfect automated code review system will likely look different for every team, and it will inevitably take a lot of iteration. It also depends on the product and the time of code system a team is working on. If there are millions of real users, financial or health data at stake, it might not be smart to risk taking production down just to move a little faster.

If I try to extrapolate a years time, I can imagine a world where code review tooling has progressed enough and become trustworthy enough that all teams will start to phase-out manual code review. But there will be an important trade-off to consider: if developers aren't manually reviewing code, will they still be able to understand the system they are building? Do they need to? Well, again I think that depends. If you're building a simple restaurant website, or some kind of low-stakes internal web app, maybe it won't be that important for developers to intimately understand the codebase. As long as they can prompt a fix and push it to prod without unnecessary friction, maybe that is good enough in certain spaces.

For the teams and products that can't afford to live by "good is good enough", I could still envision a world where manual code review will mostly be sunset. But I think in order to imagine that world, I also have to imagine a world where QA practices are more robust and thorough than ever before. Everyone is talking about building a software factory right now; this appears to be the direction things are heading. Your software factory needs strict rules for generating code and problem solving, it needs robust testing standards, and it certainly needs a durable QA process that can collect and output just the right information.

Until next time.. 🦥