The internet is not lacking tales of all-night coding sessions. Or non-stop, no-time-for-weekends crunch periods at critical and not-so-critical times. So, it would seems to be the case that it is possible to program constantly, only taking breaks for as long as it takes to answer a call of nature or maybe scarf down a pizza.
Which is really strange to me.
I feel like I have never been as productive as I have been since starting at
Buffer. And yet, I have never spent as much time away from my computer as I have during my time here.
Weird, eh?
How a crunch begins
It all starts with a deadline. Maybe the latest release of the brand new Frozzle library needs to be out by the end of the quarter for various contractual/accountancy reasons. So there is a gaping chasm ahead.
And gaping chasms are very noticeable. Everyone talks about them. Everyone can see them. And as they draw inexorably closer, everyone gets more and more aware of them. Eventually, there is nothing else to see, and panic sets in and people start to do anything to avoid the long drop into that abyss.
So, if you’re on the coding team for the Frozzle library, you know that there is a deadline. People likely won’t stop talking about it. Most conversations begin to take the form of “How long will that take?” whenever some new task arises. Paranoia is everywhere—no one wants to be responsible for the straw that breaks the camel’s back. No one wants to take the step that ultimately makes the encroaching crevasse unavoidable.
At first, tasks can be framed in weeks, which start out as 5 working days but soon become 6 or even 7. Then, because the week is just about full, the concept of a working day becomes a little bit more “agile.” Sure, 8 hours a day is a solid regular amount of work, but this is a special case, so if we could work for 16 hours, it’s like we suddenly have twice as much time before the chasm engulfs us! Great thinking.
Now the mindset has become such that if you’re not working, you’re not helping. And if you’re not helping, you must be hindering. So, back to the desk you go – implement this, fix that, break the other, fix that again, break something else, add some special case code for the time being here. It looks like you are being really busy. And you are busy, but you’re not really being productive. Unfortunately, inertia sets in quickly, and there is no way to get out of it. Everyone else is doing it after all – and that deadline is fast approaching.
Time to reflect
I work from home. Which is to say, don’t have an office to go to. What I do have are a lot of pubs, most of which are pretty quiet during the day. And I have evolved a routine that gets me out of the house, gets me fresh air, keeps me productive and goes some way to keeping me active.
The magic ingredient – changing where I work every ninety minutes or so.
It’s that simple. Every 90 minutes, I finish whatever delicious beverage I have been imbibing, pack up my stuff and stroll sedately to my next port of call. I’m lucky that I live in a small city which has no lack of pubs all within walking distance of each other, so my strolls are usually no more than 15 minutes at most.
But those 15 minutes are worth their weight in gold. Which makes no sense, but I don’t care – because I get a solid 15 minutes where I am not bashing my head against a wall because some function won’t work the way I expect it to. 15 minutes where I am not struggling to figure out why the production environment is behaving differently to the test environment. 15 minutes where I can’t actually do anything except think.
The importance of not being able to do anything
The beauty of my stroll is that I can’t think up a half-baked idea and immediately grab a keyboard to see how this new hare-brained scheme works. I don’t start tweaking one thing and then another and then another all in the vague desperate hope that it will somehow sort itself out in the end.
Instead I am liberated from the keyboard. Free to think things through. Free to take that step back and re-evaluate. Free to realise that there is a better way to do things.
Free, in fact, to be more productive.
Bashing away at a keyboard feels productive – lots of characters appear on the screen, so it even looks productive. But unless the idea behind the characters have been thought through, it probably isn’t very productive. At the very least, it isn’t efficient.
Thinking, on the other hand, doesn’t look productive. Most of the time it doesn’t even feel productive. Until that inspiration hits you. And then you feel energised, having a solid plan to implement. Something that will work and can be implemented as a complete piece of work rather than as a stack of bodges each trying to fix whatever the most recent broke.
Part-time programming
That’s why programming should be a part-time job. Part of the time should be spent thinking, and part of the time programming.
Try it—get out of your seat once an hour or so, take a quick stroll, do something completely different. Clean a whiteboard. Put out some rubbish. Do some laundry. Make a coffee. Anything to get away from that keyboard. The keyboard is the problem—it entices you into believing you are productive, where the reality is that the keyboard is stealing your productivity by preventing your mind from working at its full potential.
Give your fingers a break, and let your mind take over once in a while. You will feel the benefit. I know I do.
Interested in thinking more, working smart and helping Buffer grow? We’re hiring!
This post originally appeared on my personal blog. Follow me there for more adventures in web development.
Try Buffer for free
140,000+ small businesses like yours use Buffer to build their brand on social media every month
Get started nowRelated Articles
Nine years ago, we decided to launch a new free product alongside Buffer. We called it Pablo, and it was a huge hit in our community. Within just seven months of its launch, half a million photos were created using Pablo. Similarly, we had the initial ideas for Stories Creator and Remix many years ago now. All three of these tools have been an important part of Buffer’s story. They’ve taught us lessons and helped us connect with a wider audience. In Pablo’s case, the idea for this tool happene
If you use Buffer, you might have experienced us having more downtime than usual recently. We want to start with an apology for not sharing more transparently along the way what’s been happening. We’ve been caught up in the work and haven’t invested enough in communicating with our community, and we’re so sorry about this misstep. We know some of our customers have had a frustrating time using Buffer recently and we need to do better by you. This past August and September were the months we’ve
As part of our commitment to transparency and building in public, Buffer engineer Joe Birch shares how we’re doing this for our own GraphQL API via the use of GitHub Actions.
