At my day job, I just had a code review. Code reviews are, in general, awesome, because you find out what you’re doing right and wrong, and you get to talk to other programmers; talking to other programmers is awesome because they know things you don’t, so talking to them causes learning, which is our goal.
Anyway, at this code review, we talked about some stylistic inconsistencies I had introduced into the code base. (In this case, using named booleans in conditional checks, rather than inlining the whole check, but that’s not what this article is about.)
One of my colleagues said something very wise (paraphrased heavily): Lots of stylistic decisions don’t matter that much, but introducing stylistic differences is bad; code is easier to read if it all follows the same conventions, even if those conventions are not the best conventions in the world.
Now, I knew I was introducing a stylistic difference; the problem isn’t that I wasn’t paying attention. The problem is that I thought I knew better. Maybe named booleans make if statements easier to follow, and maybe they don’t. But a code base where half the people follow one convention and half the people follow the other is definitely harder to read than a code base where people consistently follow either convention.
There’s a short, unpleasant word for making the wrong decision because you think you know better: arrogance. Looking back, I realized I was sitting there thinking, “these guys obviously didn’t read Code Complete enough times; I’ll show them.” Instead, I should have been thinking, “why am I the only one here whose code looks like this?”
I still like named booleans, because they tell future programmers what you thought the result of the conditional check meant, and in my own projects I’ll probably continue to use them. But I learned an important lesson at this code review: If you find yourself doing something the other developers don’t, because you “think you know better,” please reconsider. Or better yet, ask someone why they do it that way. But don’t sit in your cube, decide they’re wrong, and make the code a little uglier in the process.
Arrogance is a major obstacle to learning, and I’m glad I went through a code review before this particular instance of it went on any longer.
Here’s a thought: the next time you think, “this is an ugly method. I would have written a method that was elegant, and efficient, and easy to read, where everything had clear, even beautiful names. I could do so much better,” copy the signature of that method into a blank code file and try to write it better. There are only two possible outcomes of this exercise, and they’re both good: You’ll either come up with a better method, which you can suggest as an improvement. Or, and much more likely, you’ll realize that the problem that method solves is harder than you thought, and you’ll be a little more generous when you read code in the future. In both cases, you learn.
Till next week, happy learning!