There is an idea floating around that if you are pairing on a piece of development, that work does not need to be code reviewed. The reasoning being that a pair of developers will be able to hold each other to a much higher standard together, than they would if they were working alone.
He gives an example of a situation where his team was gathered to compare three different solutions to a very similar problem. The discussion wasn’t centred around what is good or bad, it was:
- What are the tradeoffs of one approach versus the others?
- What choices did the author make to arrive at this solution?
- What ideas did they try, and subsequently discard on their way to that solution?
Code review is great for critique on the code that exists at the point that it is checked-in. What we miss is all of the work and experimentation leading up to that check-in. If a developer goes through 5 different ideas before settling on a solution, we have no view of that. To put it more practically, if you are trying to learn to write in the way that another person does, you miss out on the entire thought process.
He talks about the process as “sketching” with code. Each idea or “sketch” tackles the problem in a slightly different way, and may have different pros and cons, or interesting characteristics that are worth talking about and learning from.
The overarching purpose of these critiquing sessions is to create team-wide idioms.
We sometimes talk about programming languages or frameworks being opinionated or not. A language or framework is opinionated when there is an idiomatic way of writing it. That is, there is a correct or a natural way of writing the language as agreed upon by the community that writes it.
So what happens when we use a language that is not opinionated (like C#), a language that allows for many approaches to the same problem, and all are equally valid?
You end up with code that contains combinations of all of the valid approaches, all jumbled together, with different people preferring one approach or another for any given problem.
You end up with high cognitive load needed to read and understand other people’s code because everyone writes slightly (or massively) differently.
We need some sense of what good looks like here.
Code Critique is for creating that idiomatic insert x language here. It is for agreeing as a collective on what good looks like around here.
If we establish those idioms, then anything that comes up which does not follow the idioms is (hopefully) doing so for a good reason.
A good code critique model is to have junior developers critiquing more experienced people’s code. Junior developers ask questions like, why did you do that? Prompting the more experienced developer(s) to actually reflect on precisely that. This allows idiomatic language to emerge safely and naturally.