A myth is going around in programming circles of a mythical beast called The 10x Programmer. These creatures eschew laws of nature, compared to average Joe Programmer they produce more high quality work in less time.
But are they really some special superhero? Born with a keyboard in their hands, mind made of linear algebra and visualising complex systems before they can walk? Or just normal people with an opportunity to actually work?
I think everyone can be a 10x programmer.
Flow
Objectively measuring developer productivity is folly, but everyone can tell a productive day from a day wasted. You know, those days where you smash your brain against a bug all day and nothing seems to budge? Days when you come to work; there’s an urgent email, right after that an emergency phone call, then it’s already lunch time and … stuff happens. A lot of stuff. You’ve been busy all day, but you didn’t get any work¬†done.
Yeah, those days.
The problem with those days is you couldn’t achieve flow. That most awesome of states when you get to completely focus on the problem you’re solving, become so engrossed in the zone the program feels plastic in your mind. Fingers effortlessly gliding over the keyboard you can shape the code into anything you want just by thinking about it.
After four or five hours without a break, you feel energised, like you’ve just had sex or eaten the perfect piece of bacon (replace with chocolate cake at will) - hardly noticing any time has passed at all, you ask for more.
Looking back at what you’ve done … wow, it’s like you’ve been working for five days!
Hopefully tomorrow you will still understand the epic elegance.
This is called flow. It’s awesome. The only difference between you and 10x programmers is how often you get to work while in a state of flow.
Unfortunately, you’re a freelancer or an indie, this is hardly up to you. Especially for work projects.
Things that kill flow
Two things kill flow faster than you can say schadenfraude: you and your work environment.
Dealing with yourself is pretty easy, all it takes is a little discipline, gravitating towards projects you find interesting and a little discipline.
Discipline is important because of two things.
First and foremost, you must avoid working tired, working when you’re stressed and generally when you are unable to focus on what you’re doing. Things hanging over your head is a common problem. Deal with anything annoying, everything you’ve been putting off. Now!
Putting it off will not get it done, it’s only going to get worse. The best way to get rid of things you don’t want to do is to begin.
This clears your mind so it can focus on the code. Don’t believe me? Try. Handle all the annoying little bits and pieces in the morning and get to real work later.
Another common problem is The Internet.
Not much you can do here. I couldn’t code my way out of a wet paper bag without immediate access to documentation. But keep your compilation and test run times low, this keeps you out of temptation to get dragged into the world of funny cat pictures every time you press “Test”.
Use cat pictures as a barometer - if you see more than X in time span Y then you are tired. Get a break. Stop working. Your brain is trying to tell you things and it’s only going to get worse.
This gradual decline in ability to avoid impulsive behaviour is called ego depletion. Replenish your ego by stepping away from the computer and getting a proper break.
A good approach is the Pomodoro technique - focusing for 25 minutes, followed by a 5 minute break. This has enabled me to work all day without getting burned out after four hours and wasting the rest of the day.
Work environment
The most interesting project you can think of combined with all the discipline in the world can be completely trumped by a bad work environment.
Perhaps even more important, work/office culture counts as environment as well.
Trust.
That’s the main property of a good work environment. Without trust, things happen that kill a programmer’s productivity. What I mostly mean by this are interruptions.
While distractions are internal and can be avoided with a bit of discipline, the real problem are interruptions. Every time your boss asks what you’re doing, or checks how far along you are on that thing he’s asked you to do, they interrupt.
Every time a colleague needs their answer now, they’re interrupting. When an email must be answered now, same. Phone call, even worse.
Never expect a programmer to respond immediately.
A good office environment will favour asynchronous communication. This allows programmers to respond when they have time, preferably in batches. Let requests accumulate for a few hours, even a whole day, then answer everything and don’t stop until you do.
This requires trust that you won’t just sweep things under the carpet and the developer’s discipline to actually respond to everything in a timely manner.
Managers like to check in on people, it makes them feel productive. It quenches their inner fear that programmers have wandered off and are spending too much time yak shaving and not enough producing valuable output. This fear must be quenched; again, trust. Trust that you will tell them as soon as you finish, trust that you will notify them when something starts taking too long … and you have to trust that they won’t bother you while you’re deep in thought.
Not to even mention the physical properties of environments - good lighting, comfy chairs, everything juuuuust right. Don’t share rooms with people not in your immediate team, don’t share rooms with people who use phones etc. etc.
So, 10x work?
It seems, then, that every each one of us can be a 10x developer. All we need is an environment that lets us adopt the right work practices and some discipline on our part.
Work in long stretches of time, avoid meetings, communicate asynchronously, take scheduled breaks, don’t worry about stuff.
You should read my book, Why programmers work at night.
