Communication. The activity of conveying information. The exchanging of thoughts. It’s incredibly easy to do — we do it all the time, consciously or otherwise — but incredibly hard to do well. Unfortunately, it’s a core part of being a good developer, and one that we all too often forget about.
Of course, that doesn’t mean that we all have to write prose like Shakespeare, or give speeches like Pericles. But we all write code. And we should strive to write good code. That’s not (necessarily) the same as clever code, or short code. It’s code that is understandable. Because we don’t write code just to make computers do things. If that were the case, we’d still all be writing bytecode. Instead, we’ve come up with a whole host of languages, covering countless paradigms, to allow us to better understand what it is we’re trying to achieve.
And we’re not writing this code in a vacuum. Even if we do work alone, there will always be someone else looking at it. That might be the next developer we hand off to. Or it might be us 12 months down the road. But there’s always someone. Of course, the majority of us work in a group of some description, and that someone else may well be looking over our output the very same day, if not directly over our shoulder.
On one level, I agree that “developers don’t have a common consensus on what code review actually means“, but ultimately I don’t think that’s cause for ignoring mandatory code review entirely. Forcing other people to look at our code reminds us that ultimately it’s there to be read by humans, and not just to instruct machines.
Yes, there are many different ways of approaching a code review, and we don’t all do it in the same way. And no, I don’t think it should mean “acting like a human computer and painstakingly processing every line of code like a computer would” — that’s what we have computers for. When I ask someone to review my code, I’m really trying to find out if it makes sense, if it’s eloquent and approachable.
Because I want to be the best programmer I can be. That doesn’t mean remembering every little nuance and technicality. Nor does it mean being able to churn out lines fastest. It means being able to write code that other developers can appreciate, and enjoy reading. It means being able to convey information as concisely and expressively as possible, without losing any meaning.