Sometimes it only when you lose a particular tool is it that you come to really understand its worth.

When I worked at Crytek we used peer reviewed code tools, a lot. In fact, as all good studios should have by now, we had pre-commit hooks that required that a code review be done one every single commit.

I. Loved. This. [^1]

You could learn the codebase faster, you would learn and see new techniques, you could share your experience with others, discuss and design code on a different level. We ended up working very quickly and efficiently not in-spite of code-reviews (as many think) but because of it. Code-review elevated the team.

This was particularly relevant at Crytek UK because we needed to keep up with the engine innovations in Frankfurt, and had to rewrite the games several times (mostly just vertical slices, thank goodness), and code review really helped. I should probably mention that the UK Studio was really effective at this, successfully innovating and building on top of the core-tech, even whilst the other studios found it a bit more tricky to follow the rapidly changing ecosystem.

I also found that code-review really was one of the best way to understand one's peers, get insights on their internal processes, see how diligent (or not) they were, how clear their thinking was; it really can be a great way to gather the data for peer-reviews.

It was also an incredible way to communicate with teams around the world, across timezones, asynchronously, and still ensure fast turnaround and shared understanding.

I have to admit that I am a stickler for the fastest, neatest, most modular and, yes, even const-correct code, and peer-2-peer code-reviews did nothing to dampen my strongly help views on this... so I used get a lot of stick for it at work, because I was very, very picky, even when looking at someone else's code as I held it under the same scrutiny as I hold my own. This was ok working at somewhere like Crytek where the general quality was so high, so well thought through and performance and elegance was embedded at all levels. But, I was very picky, so much so that at crunch time they did turn to me to gatekeep commits, mainly because I learned to be fast and accurate with my reviews.

Code review are a great way to learn a codebase, and new techniques. But not only is it a way to learn from peers and those who have more experience, a way to disseminate knowledge of a code-base, and its systems, but it's a great way to see how people code and how they act toward code and coding guidelines, how much they care about the product and the company, not just "getting the job" done.

I have noticed that devs who have not been lucky enough to experience working with and collaborating with excellent teams - vs a group of individual contributors posing as a team - how useful and liberating good code review can be; to those types code-review feel like it's a "'heavy-weight" process that "gets in the way" or "wastes time", the worser the software-dev, the higher their self-importance the less they understand the benefits of code-review. But, and having seen it, I know, that we can deliver features fast, whilst also delivering performant, stable, neat and modular code.

I'm currently pushing, hard, to introduce these practises at my current film-tools dev house. [^2] We have serious internal knowledge gaps (bus-factors), and many, many embarrassing customer-facing problems, both of which would be quickly solved with code reviews. But the culture just isn't the same, it's looking more and more like Crytek UK was unique.

[^1]: mainly because I'm a masochist

[^2]: Editors note 2025: I failed and I hear that the problems remain. I guess culture is everything.