Good developers help other developers be good developers.
That sounds like a truism, but it’s really important to learn. Take, for example, code reviews.
Back in the olden days at the turn of the millennium, a group of experienced programmers refined a group of programming techniques called Extreme Programming. The name may sound a little awkward in retrospect (and it grabbed attention then), but a lot of the ideas were smart back then and you might recognize several of them now.
One of those ideas was that every piece of code approved for release to users should have at least two people go through it line by line. This had several advantages, including reducing bugs, improving design, and ensuring that no piece of code had only one person who could ever maintain it.
You can see similar principles in coding for secure environments, like handling credit card data, financial data, private information, or other financial or sensitive systems.
Back in the Extreme Programming days, before we had ubiquitous video calls and screen sharing and the easy ability to collaborate on documents in real time in web applications and IDEs, Extreme Programmers often sat together, two at a computer, to review code as it was being written.
A couple of decades later, it’s not always that easy.
I’ve written code with lots of people I’ve never met in person. Sure, I’ve met many of my coworkers at my current job in person, but not all of them. I’ve also worked with people I’ve never met nor chatted with on a video call nor even talked to in person.
Yet we’ve written code together and shipped that code to real users in the real world.
Some of the magic in the intervening years comes from good tools like distributed source control systems (I’m thinking Git here but there are several other good options) and collaboration systems like Github.
Some of the same systems that make things like Dogecoin possible make distributed development and collaboration possible, and they make it easier year after year.
All of this distributed collaboration makes things like code reviews and trust even more important, too. Can you trust that me, an experienced developer sitting in the warm glow of an LED bulb in a rocking chair watching the sun set over the hills has your best interests in mind? Can you trust that a seemingly innocent code change I’ve proposed does what it says, without holding any nefarious purposes behind it or without any obvious bugs we’re all going to regret later?
That’s why code reviews are so important.
Consider PR 2754. This is an update to some code I originally wrote (I’ll talk about that PR later). There’s a good reason for this change; it improves the information provided to users by reducing artificial precision.
If you read the comments carefully, you’ll see that I managed to get one thing wrong, even if my heart was in the right place.
It’s not worth going into the IEC standards for multi-byte prefixes, but suffice it to say there are two schools of thought: how computers count and how people who aren’t computers count.
I have a preference, but when it comes time to do a code review, it’s important to keep a couple of things in mind.
First, what are you trying to achieve?
Second, what are you trying to achieve?
If everything else were equal, you can see that Patrick and I would prefer to count like computers do. Beep boop, we’re nerdy that way.
But that’s not how the rest of the code works.
In this case, it’s better for users if we’re consistent with the rest of the code than if we’re counting the way computers count. Maybe it’s more accurate, with whatever definition of “accurate” we want to claim when we’re feeling really nerdy.
It’s better for users where we’re consistent, and it’s better for other developers (including ourselves in the future) if we’re consistent. If I were starting this project from an empty text editor and hadn’t written a line of code, I’d probably count like a computer and then consistency would match my preference, but that’s not the world we live in now and that’s fine.
One approach is as good as the other, so let’s stick with the one we’ve been using.
That’s one of the secret benefits of code reviews here. Sure, we do them because it’s important to achieve all of the benefits I mentioned earlier. The Extreme Programming folks knew a few things, after all.
Yet this experience (and writing it up just now) reminded me of one other thing that’s subtle but oh-so-very important. Code reviews, especially in a persistent form like this, where I can look at it after the fact and share it with everyone reading this, help us remind each other what we’re trying to achieve.
We want good code. We want trustworthy code. We want thoughtful code. We want to collaborate. Most of all, we want to be good developers who help other developers be good developers.
Otherwise what fun would this be?
