Make The Thing Better

30 Oct 2018 by AJ

I recently read Nelson Elhage’s blog post from 2010 - Confessions of a programmer: I hate code review when it popped up on the front page of Hacker News. At the time Nelson was ‘confessing’ to his dislike for the process of code review. It got me a little charged, because I’ve recently been musing on the concept of this general category of blog post.

The most pure way I can summarize this kind of post is a general headline - “hey this new/cool/accepted way of doing things is actually kind of bad and here’s why”

Why Thing Is Bad

It’s a classic post and it shows up every week in the top results of Hacker News. The formula is simple. Take something that people have accepted to be a standard, or that people happen to be hyped about, or something new gaining momentum, and you explain why you actually don’t like it that much.

People flock to these posts because they’re simple, emotional, and usually reinforce the views of a majority of people. It efficiently segments people into two categories, and both of these people will read your post.

The interesting thing about the people who actually like thing is that usually they also agree with a lot of what the post is saying. Because so frequently the frameworks, libraries, processes we follow as developers are compromises. There is no perfect way of working, there is no silver bullet. So, of course, there are going to be issues that we all agree are issues.

My primary complaint is that the formula ends with “this is why thing is bad”.

How Can We Improve Thing?

I rarely read posts like these that transition into this incredibly important second phase. Moving from the complaint to the resolution.

Yes, I get it code review is hard. I understand, a Scrum practice isn’t always the most efficient. Okay, so you don’t like an open floorplan, where is the comprimise?

Thank you for identifying the issues - that’s a valuable first step - but can we collectively attempt to go one step further to make some incremental progress?

Using the example of the code review - we as developers probably all agree that we’d rather be coding than reviewing code. We agree that switching context and waiting on dependencies are some of the most frustrating challenges we face in our daily workflow. We also agree that code review holds some value, and we agree that ditching the idea completely is probably a bad idea.

So what now? What is the incremental step we can take to make this process better?

To me there are some obvious answers. Like improving the tools we use for code review - primarily around the workflow. Make sure the right developers know they’re needed for code review in a timely but non-intrusive way. Make your product owners aware of the overhead of writing good code, and integrate that into your planning - include it in your unit of work. Make sure you have a way to facilitate conversation in a PR. Find ways to give developers the appropriate context, and do whatever you can to create targeted and small pull requests.

In the end, all of this, including all of my potential improvements or methods for dealing with the struggles of code review, require some significant effort. They require time, and they require some awareness of the problem and what actually needs to be solved.

To put it simply - hard problems are hard for a reason.

In your next Why Thing Is Bad post…

Try to highlight why the thing matters. Try to investigate around the edges of the thing to the related stumbling blocks that might make the thing seem worse than it is. Suggest what could be done to make a thing more valuable and less difficult.

Understand that everything has pitfalls, and encourage developers to do something about it.