Thinking of the next developer
I’ve ended up on countless projects that were started prior to my arrival. This isn’t uncommon; more often than not throughout any career in development, you’ll find that you’re spending a lot of time trying to understand someone else’s code. It may have been written a few days ago, and it may have been written years ago. The original author may still be on-hand to talk you through it, or they may have moved on. But regardless of the circumstances, you will often find yourself spending time figuring out what a codebase you’re looking at is doing, and why.
In a more extreme case (not at my current company, I hasten to add), I found myself working on a project that had been worked on up until then by two contractors, both of whom had been very suddenly let go. They had done a great deal of work, but each of them had only worked on one side of the application (one on the front end, one on the back). To make things more exciting, neither had been reviewing the other’s code. There were no tests, no readme files, and there was no handover.
It took a good few weeks for me and the team I was on to carry out enough archaeology to fix this problem. We spent time investigating, documenting, adding tests, and fixing a number of issues that had slipped through the cracks as a result of code reviews not being carried out.
But we still shouldn’t have been in this position in the first place — and our organisation shouldn’t have lost months of (cumulative) development time to this.
This whole experience made me think a lot more seriously about the code that I write too. And it made me acutely aware of how much we, as developers, end up having to think like a compiler.
Now, that’s fine in general — when we’re developing new functionality, our brains need to be bent out of shape to consider how the code we’re writing will be interpreted — that’s part of the job. But when you’re looking at a module for the first time, should you have to go through that to understand what that module is doing?
Consider this function (written in Haskell, but the language here isn’t what’s important), which takes a message and returns a response:
If you’re not familiar with Haskell, you probably just skipped straight over all that, right? I don’t blame you; what a mess!
But in my experience of picking up other people’s code, it feels like we often end up delivering code like this. People will get their code working, and then move on to the next problem.
That’s understandable, of course. We’ve all got deadlines, and project managers, and product owners, and stakeholders. We can’t make everything absolutely perfect all of the time. But consider how little time it takes to break out the logic of your functions and make them more readable. Literally a couple of extra minutes of your time could save hours of other people’s time when they look at your code next — in most cases the time will be saved immediately when your work goes through a code review.
Consider this very quick revision to the above code snippet:
Obviously I’ve omitted the actual logic here — although it is basically the same as in the first example (https://github.com/dnimmo/haskell-exercises/blob/master/bob/src/Bob.hs) — but by replacing it with useful function names, you don’t need to see it any more.
If you wanted to know what the responseFor function was doing, you’d be able to tell nice and quickly, unlike in the first example I gave you. You don’t have to know that the isShouting function checks to make sure that there are letters in the message, and then checks to see if they’re all uppercase, because you’re not a compiler. You just need to know that if the message passed in is shouting, the response will be “Whoa, chill out!”.
It’s often fun to write functions that do a lot on a single line, but for a long time now I’ve made a conscious effort to ensure that I ask myself “how well would I understand what was happening here if I was seeing it for the first time”. I want code that can be understood by reading it like a human, not like a machine. And I’ve been pleased with the results so far.
I reckon that there are big benefits to thinking about the next developer that will look at your code. After all, half of the time it’s probably going to be you.
