This is an ironically long article, so in the interests of time I have written a short version for each section. If you’re in a skimming mood, you should be able to power through it in under 100 seconds (depending on your reading and scrolling skills).
If you’re not a developer but responsible for the performance of developers, you might want to skip way way down to “The upside down” section.
A long meandering intro
When I speak to people about fast development (and I do, often) some people display a peculiar desire to translate the concept of fast into fast initially, but in a shortsighted way, so actually, slow.
It’s tempting to attribute this tendency to NND (Negative Nelly Disorder), but I think it goes deeper than that, and further back; I blame the famous fable of The Tortoise and the Hare.
This is a story in which an erratic rabbit and a tortoise with a purpose battle it out until a conclusion is reached:
Slow and steady wins the race
This is a reassuring message for (slow) children, but I propose the introduction of a new element to this fable, and I humbly present it to you now: The Tortoise, the Hare, and the Herd of Buffalo.
In this variation of the tale, the hare and the tortoise are busy hip hopping over one another when on the horizon appears an unstoppable wall of thundering buffalo. The buffalo storm past in a cloud of hooves and productivity to win the race. The moral of this revised story will be:
Fast and steady wins the race
Epilogue: the hare and tortoise were trampled to death. Their remains were turned into a creamy chowder and fed to the crowd from a tortoiseshell bowl. (Fun fact: after Charles Darwin documented the existence of the magnificent Galapagos tortoise, he took a couple with him as a snack to eat on the way home. Fact.)
So, we’ve established that ‘fast and steady’ beats ‘slow and steady’ every time.
But there’s some bad news…
The world favours those who move slow
Have you even walked down a crowded footpath in a hurry? Bobbing and weaving through the crowd, scanning for overtaking opportunities, side-stepping the oblivious phone gazers.
Imagine the path you weave, if viewed from above — a complicated, twisted line.
Contrast that to those who move the slowest. They don’t need to take the fast people into account, they only need to worry about themselves, plodding forward in a perfectly straight, simple line.
Slow is the default. Slow is easy. Fast is hard.
What this post is really about
This post is actually about happiness. Seriously. I only used the word ‘fast’ in the title as click-bait for those who wanted to come and tell me that ‘fast’ is actually ‘slow’.
When you are faster, when you are more productive, you will feel proud of what you have achieved, proud of this thing you spend a third of your life doing.
You must have experienced this at least once: that feeling when everything came together on a day and you really got shit done. Maybe it was writing code, or gardening, or fixing something on your car. Whatever it was, you went to bed with a warm sense of accomplishment.
That feeling is important, says me, and a worthy goal.
Oh and also, if you’re faster, you’re worth more money, and money is the root of all happiness.
Let’s begin with the nuggets of advice…
1. Measure how you spend your time
Get some software that can record and report to you where you spend your time. It might just provide you with the motivation to cut back on the short-term temptations that don’t pay off.
The first step to faster development is to get organised about time. And the first step to getting organised is to measure.
There are lots of tools out there to track where you’re spending your time. I use one called RescueTime which is not bad. It records open application windows and URLs and I can group these into activities. Here I can see where I’m spending my time each day:
What you’re looking for with tools like this are actionable metrics. Information that makes you think I need to change that.
For me, it raises questions like: “Did I really spend 2 hours in Slack yesterday? Could it have been less?” It also revealed to me that sometimes I will spend hours in Jira (writing and refining requirements for tasks), when ideally a professional requirements-writer would be doing that (I’ll address this further in section 8: Make some noise).
Personally, I used the app for a few weeks, got a feel for areas I could improve, and it’s been of limited use since.
2. Stop multitasking
Chunk your coding time into distraction-free sessions of at least 30 minutes. 2 hour sessions are the best.
We’re getting into obvious-self-help territory here, but I think it’s worth elaborating on since it makes such a big difference, and so few people do it.
Let’s assume that on a given day, there is a fixed amount of time that you’ll spend writing code — the rest of it spent talking to co-workers, emails, meetings, and all the other fluff. How you go about organising this time can make an enormous difference to how much you get done in that day.
Below are two timelines involving the same tasks, where blue is development time, and the pastels are the other things that vie for your time.
So-called multitasking is the default mode for most people. Your phone rings, you answer it. A colleague comes up to your desk, you take off your headphones to see what they have to say, a chat notification pops up on your screen and — at that moment — there is nothing more important in this world than clicking on it and reading what it has to say.
(Worst idea ever: notifications that show you a teaser of the message, to entice you even further to stop what you’re doing and switch tasks. We really do set ourselves up for failure.)
When we’re ‘multitasking’, our response time to any new demand for our attention is fast, so we feel good. We are multitasking. We are being productive!
But of course, we aren’t. Multitasking is very unproductive. And this is doubly true when it comes to writing code.
The activity of writing code is special because it requires hefty usage of short-term memory. It’s full of little strings of letters like
parseResults() that can represent hundreds lines of code. If you haven’t memorised what
parseResults does, you need to go and look at it to comprehend what the code is doing, which is slow. If you have memorised what it does, then you can move a lot faster. It’s similar to the difference between reading from disk and reading from RAM.
Consider this snippet:
If you’re not familiar with any of this you’d need to find out what
goGetResults does, then what
parseSortAndFilterResults does, what that result object contains. Then understand what
status is, when and where it can be changed. And where can that ‘ready’ event be triggered from and what’s the payload it’s called with? And so on.
When you first sit down to work on the code, you will jump about the place to familiarise yourself. Over 5, 10, 15 minutes you’ll load more and more logic into your short-term memory and your magnificent brain will begin to build a map of the logic landscape.
Things begin to flow. You’re in the zone.
And then your phone rings.
You answer it, you speak about important things. When you return to the code you discover that your brain has done a garbage collection and some information is lost. Stupid volatile memory.
Now you need to go bouncing around the codebase again — loading once more from disk into RAM. It takes maybe 5 minutes of jogging your memory and you’re back into flow.
Then a Slack notification pops up.
Then an email, then a colleague taps you on the shoulder, then a text message, and on and on.