Why programmers work at night
Why programmers work at night
Swizec Teller
Buy on Leanpub

From disgruntled developer, to founder, to burnout

I was 21 when I quit my first real job.

What started as a great opportunity for a high school senior to sharpen his coding chops, turned into daily frustration over management, stress and terrible working conditions.

The small advertising agency was a creative’s dream. Offices showered in natural light. Large windows overlooking a lush green park, playful decor, walls covered in old design projects, sofas in the lounge, shelves full of books on design and marketing. A relaxed culture.

It was amazing. But also terrible.

Nobody had any real idea how programmers function. How we think, how we work, what we need to feel productive. For a long time I was the only programmer on the team.

On day one I was given an old laptop, a comfy chair and a spot on the large desk occupying most of an open-floor office. Across from me was a chatty copywriter. On the right was the main designer. In the opposite corner sat another designer.

The boss who talked on the phone a lot was hiding behind a tall book shelf. When somebody went to ask him about something, the whole office could hear. Eventually a project manager joined our big desk … she wasn’t even half as quiet as the boss. I still know that printers often need to be talked to angrily to get a move on.

At first I was happy. The work was fun, it was new, and I even got paid to do what I loved. Jackpot!

But as months passed the job became more and more stressful. The projects became a slog, always the same. Waves upon waves of client work made it completely impossible to work on that one cool internal project. By the time I was finishing up coding for the previous project, a new one was already specified and all conversations with the clients done.

I could never get a word in on the design part. They thought I didn’t care, but I just didn’t have the time to attend meetings.

At one point there were so many things on my plate I couldn’t even get more than a half hour of focused work until everyone went home already.

Word of Google being a super awesome place to work for reached my radar at about the same time. A company by engineers for engineers. A place you can work at.

I dreamt of founding the perfect company to work for. I didn’t know what that meant, but I knew it was going to be cool and I would love working there.

After a few months of working on a side-project late into the night I quit my job and started working from home. Finally I could work only on what I wanted, there was nobody to boss me around and I could work distraction-free as much as I wanted!


Mum didn’t get “working from home” at all.

“You’re home arsing about all morning. What do you mean you couldn’t wash the dishes and vacuum the floor and cook lunch for everyone and your room is still a mess?”

“But muuuuum, I was working. No I don’t have time to sit down with you for an hour when you come home every day. I’m busy!”

“Are you even making any money? Did you pass any exams yet this month?”

“Sheesh mum it’s not all about money …”

“Then you’re not working!”

Not that this has been much different now that I do make plenty of money by working from home. Mums just don’t understand. I guess nobody who doesn’t work from home understands …

But eventually the side-project started taking off. Two guys agreed to work with me for free. I couldn’t really pay them anyway. We convinced a local hackerspace to give us an office - also for free - and we set off to build the next big thing in news consumption. We were going to take over the world!

We didn’t.

The startup never left my mind. At any given moment I was either architecting a cool piece of tech, pouring my misguided ideas into code, creating business strategies, thinking about what the others were doing, or learning to be a better entrepreneur.

It got so bad I was listening to entrepreneurship podcasts whenever I had more than 10 minutes of “free” time, just so I could squeeze that extra bit of productivity into the day. My standard was 14 to 15 hours.

Everyone spent at least eleven hours a day in that dark hackerspace basement. We occupied a sofa, two tables, and three whiteboards.

There was no time for deep thought. We wanted to work work work. One by one we crashed and burned.

The other programmer was the first to go. He simply stopped coming to the office. He didn’t answer any of my calls or emails. For a few weeks even his friends were asking me if I’d seen him.

I don’t know what happened, but he was a cool guy and I still feel bad for doing that to him. Last we met he was working for an established startup and finishing his studies. He didn’t seem to hold a grudge.

He was the first to give up on us, but I was the first to start burning out. I started taking long car rides to nothing. Just sit in the car and drive aimlessly around the city listening to bad music on the radio and looking at the stars.

I needed to be alone. At the office everyone expected something from me. Everyone expected me to be awesome, to inspire everyone to work hard, to woo investors, to keep my spirits up, to be perfect.

They actually didn’t, but it sure felt like it. In my eyes I was the startup. Without me there was nothing.

The car didn’t judge.

I became a husk. I spent whole days aimlessly clicking around the internet. “Work” had become writing two lines of code followed by an hour of lolcats. My nights were spent doing everything I could possibly think of that didn’t involve the startup.

In March 2011 our investors and the other cofounder kicked me out of the startup I had poured my life in for a year and five months. I was devastated, but I deserved it. I was a terrible boss, I drove my guys like slaves, I didn’t listen to just about anyone.

On my way out an advisor slash investor said: “Dude, I know this hurts. But you need to learn a lesson.”

“Screw you, no I don’t!”

But he was right. What I was doing was completely unreasonable, practically psychopathic. That is no way to treat programmers. The job I tried so hard to escape was nowhere half as bad.

Ever since I have been actively searching for the best way to be a programmer. The best way to treat programmers. The best environment to keep programmers happy, productive, and sane.

This book is about what I’ve learned.

Introduction - version 0.4

Hello, I am Book.

You already know the guy who created me from that foreword, you might think he’s silly, but he’s alright.

I am Book! You will like me.

It’s going to take about an hour, fifty-three minutes and nine seconds to read me through, but take it easy. Or fast. Either way, I suggest a nice cup of tea and a comfy chair.

I am here to tell you I love programmers. Even though they sometimes prefer to be called developers, or software engineers, or computer scientists. Whatever your favorite version likes to call themselves, go give them a hug. They’re awesome folk!

They might seem a bit strange at first, but I’m going to help you be the best person for programmers to be around. If you happen to be a programmer yourself, I’m going to tell you how to be the best programmer there is.

Keep in touch

Swizec is starting a newsletter about the things from Book. He’s going to share interesting things about productivity, programmers, office culture and stuff like that about twice a month.

Sign up at: http://swiz.ec/nightowls-list

You can also poke Swizec on Twitter as @swizec or send him an email at swizec@swizec.com. He loves hearing from people.

Whom Book is for

You should read me if you are a programmer or have to deal with them a lot. If you’ve ever waited until 11am for one of them to show up at work, or couldn’t get them in bed until 3am no matter how sexy you dressed. This book is for you!

If you’re a mum or a dad and have a pup programmer in the house, don’t worry. I’ll tell you all about why they stay up all night and sleep through school. It’s because they’re doing awesome things in their spare time ;)

If one of your parents is a programmer and they keep making corny jokes like “The two hard things in computer science are cache invalidation, naming things, and off-by-one errors. Ha ha.”. I’ll help you understand that too.

What Book contains

I have roughly four sections.

First I’m going to talk about whether programmers do in fact work at night or do they just like to think they do. For some reason they really like bragging about how little sleep they got last night. Swizec is just like that!

Then I’m going to tell you why they feel night-time is best time. Some things in the day-time just don’t gel well with those guys, understanding will help you keep them at a minimum.

Lastly, there’s going to be practical stuff. Both for people around programmers as for programmers themselves. The very last section might be called “Lifestyle tips for top productivity”.

Everything you read here has been tried by somebody. Either Swizec or some of his close friends. None of that writing things that sound good on paper, but nobody can do. Only things that work are allowed.

What is not in Book

I am not hard science. Take everything with a grain of salt, if something seems strange, tell Swizec. If something doesn’t work for you, tell Swizec. If something sounds downright dangerous, tell Swizec.

You should consider me a collection of anecdotes, personal experiences and interpretations of scientific literature on the topic.

How finished is Book

Swizec seems to have a life outside this book so it’s taking him a while to finish. You might still find some notes to himself, usually inside square brackets, or sections that clearly haven’t seen an editor yet. He’s very sorry about that and promises to get to it as soon as possible.

If you are reading via the Github repository, that’s wonderful! Make sure to tell Swizec what’s wrong! Github Issues exist for a reason.

If you’re reading via purchased pdf, that’s awesome! You are a gentleman and a scholar and a great person to boot. Swizec asked me to say thanks for supporting the project.

Right now I’m version 0.4.

The most interesting sections are About flow and Working with programmers. There’s some interesting science about creativity and sleeping habits in Why programmers work at night.

The section of tips for programmers was mostly written during long drives on a road trip around Europe. It’s all very interesting and is probably the most well researched part of the book. But Swizec still needs to mark up the references and clean up the writing.

If you’re into data, you should check out the preliminary analysis in Do programmers work at night?. Some 500,000 Github repositories were considered, but there’s still much more data hiding in there.


Book cover courtesy of @ponywithhiccups

Creative Commons Licence

Why programmers work at night by Swizec Teller is licensed under a Creative commons Attribution-NonCommercial-ShareAlike 3.0 Unported License

Do programmers work at night?

Before I can go on, we should first agree whether programmers do in fact work at night or is this just some myth perpetuated by male bravado and our romantic notions of a motivated person doing magic all night. Perhaps we just value exceptionally hard work and working all night is a way of proving you are exceptionally motivated and awesome.

To research this book I talked to some ten programmers and read hundreds of comments on the original essay, Twitter and various Reddit threads about the topic. Essentially, yes, programmers do work at night. They are the loud ones, the romantic young lads and lasses who feel night is the only place to work.

But a large portion of the programmer population is also completely baffled by this. Claiming that those working at night simply cannot schedule their lives, have no familial obligations or don’t understand how spectacular starting your day in the morning can be.

A large part of this divide, I think, is simply that it depends. The core reasons for why we work at night, or very early in the morning, or lucked out on a conductive day-time environment appear the same and mostly have to do with deep thought, flow and focus on one’s work.

Another venue worth exploring is whether our perceptions might not match reality at all. For instance, I was certain that 1am was when I reached peak productivity and could get the most done. But looking at timestamps of my Github commits on various projects shows that I am much less a night coder than I am a late afternoon and evening kind of guy.

Then again, most adults working day jobs would find it incredibly odd that I should get the majority of my work done from 10pm to midnight. My habit of “doing email” at midnight also confuses many.

It depends

Generally speaking, programmers do seem to work at night - just take a moment to look around the internet. Plenty of advice on stimulants, romanticizing late nights and infinite bravado about how little sleep everyone needs to function.

Talking to individual programmers reveals a different picture. Many will admit to working mostly during the day, at worst late in the afternoon. Infinite amounts of people admitting they hate working at night and mostly do it when they have to chase a deadline or two.

The one dividing factor between the two groups seems to be age. Not so much because age has anything to do with it (although it does dictate our sleep-wake cycle to an extent), but because age is a good indicator of what stage in life people are at. Their lifestyle if you will.

Somebody whose kid needs to show up at kindergarten every morning at 7am can’t well afford to sleep until noon. Just as a student is forced to code in the evening because school comes first.

The main lifestyle factors appear to be:

  • freelancer or staffer?
  • student of some sort?
  • have pet projects?
  • spouse and/or children?

Types of programmers

You can divide programmers into roughly two groups - freelancers, founders, indies who set their own schedules, and those whose schedule is dictated by the organization they’re in.

Those running a larger business fall into a grey area of sorts, because even though their schedule is their own to pick, they must still conform to the organization lest they hinder their employees’ work. A common pattern here is apparently to work on management during the day and code during the night.

Different work patterns show up in each group.

Staffers are more likely to work during the day, mostly brought on by the needs of collaboration with others. Even working from home, they have to be available for Skype calls and must be relatively prompt in answering email and comments on various issue trackers. Despite living in the 21st century, physical presence at a common place of work is often still required.

After all, it’s very difficult to collaborate when somebody is stuck on a bug at 11am and their colleague only answers email at 3am twice in a blue moon.

On the other hand, freelancers mostly dictate their own schedule. For many this is the reason they became freelancers in the first place.

It seems more likely for freelancers to work evenings and nights. Often this isn’t out of a preference for when they feel most productive, but out of guilt over how much they got done during the day. Perhaps there’s just an over-representation of workaholics in this population, but talk to any freelancer for long enough and they will likely complain about how little they get done.

They get just as much done during the day as their employed counterparts, but they personally feel all the time wasted on overhead. Mostly because they can’t (or won’t) charge for it.

Because much of their income is directly correlated with how much work they can get done, freelancers tend to push themselves into situations where the deadline or budget is just a smidge too tight. As soon as something goes wrong - and it always does - they are forced to chase deadlines, which usually involves a lot of late nights.

Age of programmers

Sleep researchers have discovered a link between circadian rhythms - our body’s internal clock - and age. In a BBC documentary The Secret Life of Your Body Clock they performed an experiment on teenagers that showed their brain activity is much better in the afternoon than it is in the morning. Yet society forces most of their learning to happen in the morning.

As it turns out, everybody starts life as a morning lark. Any number of parental anecdotes can prove that people habitually get woken up at 6am by their toddlers.

But as we age, our cycle starts shifting more and more towards the night, hitting its nocturnal peak around the age of 21. It is therefore not surprising at all that teenagers and college students are known for “being lazy bums who sleep in all day”.

At 21 our cycle starts shifting back into its “natural” state. By the time we reach our 65th birthday we once more find the same affinity to early mornings as toddlers. Our preferred wake up time is once more around 6am.

When was the last time your grandfather didn’t wake up with the sun?

Lifestyle of programmers

Even more important than circadian rhythms, age is a good indicator of the relative lifestyles of programmers.

Few people have a family of their own at 22, while many or even most do when they are 40. This has a big effect on when people can code because it means juggling different priorities and things that get in the way of solving hard problems.

A lot of younger programmers work predominantly at night because they simply can’t work during the day - there’s classes to attend, schoolwork to finish, if they’re very young simply doing the chores their parents give them is more important than any coding they might have going on. It’s more of a hobby after all.

So most of the coding happens at night - lovingly supported by their young person circadian rhythms.

Older programmers usually have a day job and are generally expected to put their programming on a higher priority. Since programming is suddenly the most important thing in their lives (usually after family and similar considerations), they devote more time to it.

Not only does a lot of folk wisdom talk about getting work done during the day, days being longer than nights gives a great statistical advantage to work happening during the day.

After all, it’s called a “day job” for a reason.

Pet projects

Which brings us to pet projects.

Programming is the sort of job you can only do if you really love it. It really is kind of addicting and most people I know can’t let it go even outside their work hours.

Yes, there are many programmers who love programming as a day job and want to have other hobbies they can do in their off time and don’t even want to look at code.

But even those have a pet project now and then. That little thing they do when nobody is looking, a tiny bunch of code that’s done just for them. For the love of their work.

For play, if you will.

Play is very important in creative professions. Feynman once said he’s become a bit disgusted with physics, too much was expected of him. So he started playing, completely without consequence. This led to work on the spin of electrons for which he won a Nobel prize.

Having no obligations brings better work, solves more interesting challenges and refreshes the brain.

Not everybody is a famous researcher at a university, or a googler with 20% time, so they have to play when nobody is looking. The only time nobody expects anything of them. At night. During weekends.

Fun projects happen around work work.

Pet projects are also something to show off, a cool hack that makes everyone’s ears perk up. As respect is gained in the community, so fuel is added to the myth of programmers who convert caffeine into code.

What about other creatives?

The title of this book is Do programmers work at night?. Your natural question might be “Do only programmers work at night?”

I don’t know the answer to that question, but it seems like a lot of them do. Writers come to mind, as do designers and artists. Michelangelo was known for painting in 40 hour stretches until he fainted of exhaustion.

If you are one of those people, you might well find yourself in this book as well, and I wouldn’t mind hearing from you.

But I can’t write a book about everyone, my experience is in the programming world. Programmers are the people I have an inside look at, I don’t know the first thing about artists and while I might know a thing or two about writers, I personally prefer mornings for writing and nights for coding.

All I know about other creatives is that many of them complained they are not explicitly included in this book.


[this needs to be expanded and pulled into a full blown section]

I created a small script that crawled Github search pages for about a week and collected a list of just over 500,000 Github repositories. Another small script then spent roughly fifteen hours going through this list and fetching each repository’s punchcard.

As you might imagine, a punchcard tells us what time of day commits were made to a specific repository.

For instance, here’s a punchcard for all the repositories that I own; you can get yours at http://nightowls.swizec.com.

Swizec's punchcard

Swizec’s punchcard

To find out when programmers actually work most, I collected all of this data into simple histogram - all 164,509,270 commits of it, or roughly 6 gigabytes. The results are interesting, although perhaps not surprising.

Commit histogram by hour

Commit histogram by hour

As you can see, most commits happen between 3pm and 5pm, just when a normal workday is concluding and people have to make sure all of their work is committed so they can go home for the day. This would imply that most programming still happens during normal working hours and that a lot of people use Github for work projects.

More interestingly, even though the volume of commits drops off dramatically - almost exponentially - after 3pm spike, it does not reach the very low volumes of early mornings. In fact, it remains at about 60% of peak volume for the remainder of the evening!

This is interesting on two fronts.

Firstly, it suggests that a lot of programming activity happens in the late afternoon and early night - for an industry that only works during working hours, commit volume at 9pm should be around the same as 5am. Practically zero that is.

Secondly, it’s interesting that the volume remains so level until midnight and then start dropping dramatically until reaching the 5am low point, before it again starts rising in a bell curve towards the peak.

Unfortunately, my data does not allow me to tell which projects are things people work on in their spare time at home and which are purely work projects. A lot of interesting things could be gleaned from the data if I could figure that out. Right now I would say that our histogram hides two bell curves.

One bell curve has a peak at 3pm and the other at about 9pm, combining them together would produce the data we are looking at, I think. This warrants further study.

Keep in mind, even though peak commit volume is at the end of a normal working day, more than 5,000,000 commits in my dataset were made between midnight and 1am. That’s a lot of programmers producing a lot of work.

Why programmers work at night

There’s magic in the night-time. The peace and quiet, the internal serenity … There’s just you, your work and an infinite abundance of time. You are alone.

As a society we know that smart, talented people work at night. Often in solitude, they solve problems mere mortals could only dream of. Look no further than your nearest book, movie or TV show about a lone genius …

He is a youngish man. A bit of a loner. Doesn’t get along with people terribly well. Likes to work at night or before dawn.

The stereotypical programmer is a friendlier version of that: likes staying up all night, lives off coffee and energy drinks, makes loud noises when disturbed, occasionally writes mean things on the internet.


There is a lot to be said about the effect of culture on when people work. Especially when your idea of hard work is sitting behind a computer all day and doing tiny repetitive motions with your fingers.

One of the greatest benefits of being a programmer is that you can work whenever your mind feels at its best and most productive. You might often have to adjust to other team members either for collaboration or with the explicit purpose of avoiding unwanted interruption, but generally speaking, when you work depends on your personal preference alone.

A lot of professions can’t afford this luxury - journalists have daily deadlines, sales people have to catch people in certain moods, farmers must feed animals at specific times and so on.

But it wasn’t always like that.

One of the programmers I spoke to while researching this book had the pleasure of working on old mainframe systems a few decades ago. Back then, computing power was a scarce resource and carefully managed. To run a program on a mainframe you needed access. That access was much easier to get at night when other parts of your organisation weren’t using the mainframe to do whatever.

So programmers preferred to stay up late rather than work during the day, IT was simply easier to get the computing resources they needed.

In the late 1980’s and early 1990’s computers became commoditised and everyone could have access right from their bedroom. But at the same time the internet came into wider use, amongst programmers especially.

I was lucky enough never to endure dial-up internet. Right around the time internet access was becoming ubiquitous so was ADSL; I managed to convince my parents “broadband” would be cheaper than internet phone bills. But I still remember a computer enthusiastic family friend explaining his internet strategy when I was about 7 years old.

You see, internet use is very limited during the day. Somebody might call your house and your line will be busy. Or your parents will want to use the phone or something. Then in the evening everybody suddenly wants to connect and the internet becomes clogged up, really slow.

So your best bet for the internet is after 10pm or 11pm, that’s when you can reach full speed. Another option is at 6am or 7am, but that’s really hard to get up for.

I was very impressed by all of this, didn’t understand a thing and stuck to windows3.1 games on his computer. Those were fun. The internet did not sound like an interesting place at all.

A combination of these factors may have greatly contributed to the idea that “computer people” work at night. That they live off coffee and are generally night dwellers who avoid light at all cost.

Of course programmers aren’t doing anything to fight this notion - habitual bragging about how resilient you are to sleep and how you managed to stay up all night to fix a bug is widespread.

Remember, programmers work at night. Would a young upstart really dare call themselves a real programmer if they didn’t enjoy working at night? Of course not. Plus there’s all those movies saying that smart people work at night … and you want to be smart, right?

The science of night owls

A growing body of research gives credence these ideas. People with higher general intelligence are likelier to prefer staying up late and people are more creative in the evening than in the morning.

A study published in 2006 studied USAF trainees in the sixth week of their training. The important part being that as a result of their training, all participants in the study lived the same lifestyle, ate the same food etc. Factors, which have been shown to affect circadian rhythms.

The study found that people who self-identified as preferring the evening also achieved higher scores in the different cognitive tests measuring things like memory and processing speed. Albeit the correlation was small, it was consistent.

Interestingly enough, individuals self-identifying as evening types, achieved higher scores in the morning as well. This is despite the USAF population being skewed towards morningness.

The study also mentions all other morningness-eveningness research would indicate a link between higher general intelligence and a preference for night owl behaviour. Arguing that the sample populations in those studies exhibited a skew towards eveningness and because they were done on university students, who generally have higher intelligence, this would indicate a positive link between the two.

The research I’ve found on this topic does not say much about whether being smarter means you will prefer evenings, or preferring evenings means you will be smarter.

Another relevant study from 2011 looked at the difference in solving insight and analytic problems based on morningness-eveningness preference and when you are actually solving the problem.

Their findings indicate that people perform better at insight-based tasks when they are not at their best time. So a night owl is more creative in the morning, while a lark is more creative in the evening. One of the given explanations supported by a related experiment was that being tired inhibits ones ability to focus, which in turn makes you more capable of thinking widely, beyond the scope of already retrieved knowledge.

As expected, solving analytical problems shows a positive correlation between time preference and when you’re actually solving a problem. Night owls perform better in the evening, larks in the morning. This is very likely due to the fact that peak activity time relates to when we are best able to focus.

All of this goes somewhat against two of the original hypotheses I proposed before writing this book - that of being more creative in the evening would only appear to be true for morning people, but it seems odd that programmers would habitually work in the evening if they were morning people. Especially since neutral people without a preference do not exhibit creativity gains depending on time of day.

The other hypothesis that finds itself on shaky ground is the idea that we better manage to focus when tired because a processing power limit is reached and we have no other choice but to focus lest no work get done at all. I will explore this further in the Sleep Science section of the book.


To do high, real good physics work you do need absolutely solid lengths of time, so that when you’re putting ideas together which are vague and hard to remember /../ it needs a lot of concentration

~ Richard Feynman, The Pleasure of Finding Things Out

Just like Feynman’s physics example, programming is a process requiring deep thought and a lot of concentration. It’s abstractions all the way down. The only way to do good programming is to become completely immersed, so focused you might forget to eat drink and sleep.

You need flow.

Flow is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energised focus, full involvement, and enjoyment in the process of the activity.

Flow was discovered in 1975 by Mihaly Csikszentmihalyi while he was observing artists who got so lost in their work they would forget to eat and drink and would even stop noticing the passage of time.

Flow is the natural state of the programmer.

Any programmer will tell you stories of the wonderful work they’ve done while in flow, in the zone, wired in or any of a number of euphemisms that all mean the same thing - the programmer had an interesting task, it was challenging, but not too much, and they were left alone to work.

A lot, if not most, of creative professions experience flow, but it’s especially important for programmers. The systems we work on have become so complex they are impossible for an individual to understand fully.

It’s like building a house of cards where every card is slightly bent and torn. You have to balance them carefully, keep all of them in mind when adding a new card and should a single card falter, everything will come tumbling down.

When a programmer works their brain is playing this delicate game of card house building. Unless fully immersed, the going will be tough, if not impossible.

More importantly, the work we do provides everything necessary to achieve flow:

  • challenging
  • offers immediate feedback
  • clear objectives
  • never really ends

It’s very easy to get sucked into a programming task. You build the framework in your mind, start working, constantly receive feedback from the computer, make tweaks, beat one small problem after another until suddenly it’s morning and birds are chirping outside the window. You’re feeling slightly tired, quite hungry, a bit thirsty and confused as to where all the time has vanished off to.

Right now, if you’ve ever experienced flow, you are nodding in understanding. If not, you think I’m crazy and am talking complete nonsense. How could you not notice when you get hungry or tired!? Silly person.

Surely you’ve played a video game before?

Video games are specifically designed to get players into a state of flow. To make them fully concentrated on the gaming experience and forget the world around them. The learning curve is always just steep enough to be interesting, the challenges are non-repetitive and you’re having fun.

This is why we hear unfortunate stories of people forgetting to feed their children or starving themselves to death while playing.

Now imagine your job looked like that. A never-ending string of challenges you can solve with the tiniest bits of focused thinking.

About flow

Ayrton Senna’s experience during a qualifying lap at Monaco’s 1988 Grand Prix illustrates the importance of flow perfectly.

I was already on pole, and I just kept going. Suddenly I was nearly two seconds faster than anybody else, including my team mate with the same car. And suddenly I realised that I was no longer driving the car consciously. I was driving it by a kind of instinct, only it was a different dimension. It was like I was in a tunnel.

That lap has been described as the greatest lap of Senna’s career.

Flow is a state of complete immersion in an activity, a state where the outside and inside world merge into one and the person is simply present. Mihaly Csikszentmihaly - the father of flow research in psychology - describes flow as

completely focused motivation. A single-minded immersion that represents perhaps the ultimate in harnessing the emotions in service of performing and learning.

In his essay Holding a program in one’s head Paul Graham explains that to be effective, programmers must be able to hold an entire program in their head while they work. It’s the only way the problem and its solution can have the plasticity needed to make sweeping changes and improvements.

Because programmers tend to work at the limits of their tolerance for complexity holding a program in one’s head is only possible in a state of flow.

But flow is a fragile balance between many opposing forces. The programmer must be willing and able to completely focus on the task at hand, they must have a clear goal to work towards, fresh challenges must be coming in just quickly enough and they must feel a sense of purpose, even joy, in what they’re doing.

The autotelic personality

In his work Csikszentmihalyi describes a type of personality that can experience episodes of flow more easily and more often than most people.

Researching flow in a lab is too difficult to get proper results, but evidence keeps wagging its eyebrows suggestively, hinting at the validity of something called an “autotelic personality”.

If there is such a thing, I think programmers generally apply:

  • curious
  • persistent
  • not self-centered
  • often performs activities for intrinsic reasons

It has been drawn in stick figures that when a normal person pushes a big button saying “Don’t press this” and gets electrocuted, they think to themselves “Heh, I shouldn’t have done that.” But when an engineer presses that same button they go “Huh, I wonder if that happens every time”

All programmers are engineers at heart, no matter what their formal qualifications might say.

Relentlessly hunting down bugs is a source of great pride for most programmers and many would sooner go without sleep than allow a bug to remain in production code. More experienced developers will often go to sleep once they realise they’ve started making silly mistakes, but they will never forget a bug that’s taunting them.

Even a casual perusal of Github repositories will show that a lot of programmers indulge in so called pet projects - little programs developed for the fun of it, to sharpen the saw if you will. Interestingly enough, flow is much easier to experience on pet projects than large for-money behemoths.

It could be argued that programmers are very selfless people - the existence of communities like StackOverflow, large numbers of conferences where speakers share their knowledge for free, numerous blogs and free tutorials, not to mention the large opensource community that’s given us something as powerful as the Linux operating system and the stack most of the internet runs on. All of those are done holistically … well, mostly. Everybody gains from having a good standing in the community.

As a group of people, programmers exhibit all the traits of an autotelic personality. This would suggest flow is much more prevalent amongst programmers than in other groups of people, which might also explain why we programmers are often perceived as night walkers.

Is achieving flow easier at night?

Yes, flow is indeed much easier to achieve in the evening. At least for those of us who manage to think clearly and who still feel relatively rested. For many, the structure of their life makes this impossible - some then approach the night from its other end, others learn to work during the day.

Decision fatigue

The biggest enemy to evening and night-time productivity is decision fatigue.

Most people experiencing decision fatigue don’t recognise it for what it is, but if you’ve ever felt well rested physically and still couldn’t think clearly, like your brain was tired, you’ve experienced decision fatigue.

Research has shown that humans can only accept a limited amount of decisions every day, after that we usually go with the default action, or are so incapable of making a decision we can’t perform the action at all.

Not only that, it’s been shown that even the tiniest decision factors into the quota - everything from deciding what to eat for breakfast, to which outfit to wear and what websites to read now or later. This is why the checkout aisle in your supermarket is filled with tiny things you otherwise wouldn’t have bought and why people instinctively want to “sleep on it” when making big decisions.

Depending on how a programmer’s day is structured, working in the evening can be a godsend or a spaghetti code mess producing mistake. The important thing is to be well rested regardless of the time when you start working.

An interesting side-effect of decision fatigue in its early stages is that you can often focus better because you are a bit tired. You know there’s no other choice but to power through the work, so you sit down, ignore everything else and just code.

Eventually decision fatigue catches up and you find yourself thinking long and hard about what variable name to choose.

Clear mind

Flow is marked by an intense, almost meditative, calm. No other thoughts can invade your brain than what pertains to the task at hand. Everything else ceases to exist.

But when things are hanging over your head, so to speak, achieving flow is nearly impossible for most people. The mental clarity and emotional calm just isn’t there.

Whether it’s an errand you still have to run, or an important email you mustn’t forget to send. Perhaps there’s just some worrying stuff going on and you aren’t Irish enough not to worry about it. Sometimes you simply have an IRC chatroom open in a hidden window.

If there’s something tugging at your brain, you might as well forget about flow.

Perhaps the biggest thing everyone’s got tugging on their brain is the anticipation of imminent distraction. You know something is going to happen in an hour or two. Sometimes it’s a big meeting, other times you have to be around to take a call - either way, it can be very distracting even if you do know when the distraction is going to happen.

Everyone knows those moments where it’s 2:35 and you expect something to happen at 3:00. You try to get work done, but you keep looking at the clock every two minutes. Then you might as well check a tweet or two … when 3:00 rolls around you basically haven’t done anything useful for almost half an hour.

Not knowing when, or even if, a distraction is going to happen only makes it worse. You’re paying half attention to your code and half attention to your environment at all times. When a colleague sitting across the room says something, you immediately listen in, process what you’ve heard, decide it wasn’t about you and get back to work.

You’d love to tune out completely, but sometimes it is for you and you have to respond. Random rewards are after all the strongest behaviour creator in existence.

Something wonderful happens at night, though. There are no more distractions, at least there is no more threat of imminent distraction. Since everyone is asleep you can be fairly certain nobody is going to give you a call, nobody will ask you a random question, nothing interesting is going to happen on the internet.

For at least ten hours nothing will be expected of you. Nothing. That’s a lot of freedom right there.


Have you ever had a habitual activity fall through? Say you go to the gym every Wednesday at six in the evening. Or you always watch a certain show on television at exactly 7PM every Thursday.

When something comes up and you can’t do what you’re used to it doesn’t feel like you’ve gained an extra hour or two. No, you feel lost, like you suddenly don’t know what to do with all this extra time you’ve been given. So you end up wasting it, clicking one more link on Reddit, or flicking through one more channel on the telly.

As they say, habit is an iron shirt.

Getting used to something takes a concerted effort of a few weeks, but once the habit is built it’s almost impossible to change. Just remember how odd it feels when you forget to brush your teeth in the morning!

It’s the same thing with flow - it’s simply easier at certain times in the day. This depends on a lot of things like how many other obligations you have, what the schedule of the people around you might be and even your internal cycles of activity, which tend to depend a lot on meal times.

But once you get used to working at a certain point in the day, suddenly your other habits start forming around these patterns instead of the other way around. It’s a bit of a self-reinforcing pattern you see.

Since most programmers start very young, let’s take a young programmer for example. Let’s say they’re still in high school.

This programmer needs to get up every morning at a predetermined time so they can get to class. They are stuck in class until, say, 3PM. They come home, their mum wants them to do a bunch of chores, there’s homework to tend to and before they know it it’s already 9PM or 10PM.

And now, finally, there’s nothing hanging over their heads anymore. They can get to programming.

In a few years this person has come to college, there’s much less external time constraints, but after many years of starting coding in the evening they associate the activity with night-time. They simply can’t get their mind to coding before 9PM anymore.

Thus, another night-time hacker is born. With years and piling pressure from the outside, their schedule will shift around, flow to and fro to meet other demands in their lives.

But when shit hits the fan and something needs to get done, I bet they will go back to their safe place and code all night.

Two types of flow and what keeps them going

Once a programmer gets into flow, it is paramount that they stay there for as long as possible. Not only will they get more work done simply because they’re spending more time working, flow is a self-fulfilling prophecy. The more time you spend in flow, the easier getting into flow becomes and the deeper the flow becomes.

But not all flow is created equal, sometimes it will leave you energised and awash with even better ideas, other times flow might leave you completely exhausted in the end having just squeezed every last ounce of awesome out of you.

The difference depends mostly on what kept the flow going.

Panic mode

Every one of us probably knows that feeling of sheer panic that only a hard deadline can bring. The moment you realise The Paper is due next morning, it’s already 10pm, you’ve just come home from an evening of beers and suddenly discovered you still haven’t picked up that book from the library. You know, the one with all the info you need to write this thing.

That’s when real productivity begins for most people. That’s when they can really tell what they’re made of.

The outside world melts away as you pound the keyboard in a furious panic. Internet stops existing, Skype going off every five minutes could just as well be a supernova going off in a distant galaxy. Nothing exists but you and your work.

Come morning, you are tired, cranky, effectively two days behind on sleep, but victorious. It might not turn out to be a perfect mark, but it’s better than a fail. You know you could have done better if only you had started earlier, but you didn’t.

What just happened was a panic induced flow.

You spent the entire night essentially in a fight or flight response, adrenaline coursing through your veins made you hyped up, focused. But it was also exhausting, your only reward a deadline not missed. The price, half arsed work and the subsequent day completely wasted because you will be too tired to think.

Deep fulfilment

The converse of panic flow, is the good kind. A drug-like trance that leaves you energised, ready to take on the world and were it not for annoying physical limitations you would happily spend all your days in such a state.

For me the typical situation is something like this.

I have spent the past few days thinking about an interesting problem, it’s just been rolling around my mind. Either it’s an interesting algorithm I want to try implementing, or a problem I feel could be solved for plenty of people. Sometimes it’s as simple as feeling a blogpost must be written to address a topic.

I let the feeling fester for a while. On purpose. Indulging immediately would ruin the flow because the mind must first have time to process the idea in as much detail as possible.

One evening I will sit down and begin.

The outside world melts away, time becomes a blur and before I know it morning comes. Surprising. Startling. When the hell did this happen? Wasn’t it just 8pm half an hour ago?

In reality, I have just spent twelve hours in complete rapture. Engrossed in the bigger picture I solved sub problem after sub problem, each just interesting enough to keep me going, each just difficult enough to keep me going.

At this point my body has had enough and I do need to get some sleep.

But the very next day I will jump out of bed - yes literally - and even brushing my teeth might feel like too much waiting to get back into the code.

That’s the good kind of flow. The one you want. Because this is sustainable, were it not for practical limitations one could live for months on end like this.

Panic flow … that one is only good for one or two consecutive days. Then it takes weeks before the brain is ready again.

Why is day-time particularly bad for flow?

Now we can all agree the night is particularly good for flow, it is important to remember this is not the only time when programmers can reach flow. Mornings, especially very early mornings, are a popular choice as well. Even though this is just approaching the night from a different end, the cultural baggage attached is different.

People who start work early in the morning, especially before dawn, are often seen as hard-working and commendable, while those who choose to work late into the night, often right until dawn, are often seen as lazy slobs who sleep the whole day away. Strange as it may seem.

Whether a programmer chooses late nights or early mornings, doesn’t really change the goal - to avoid working on high intensity flow activities during the day.

The answer I got when asking programmers why they don’t like working during the day sounds very asocial indeed - because other people are awake.

Cost of interruption

There is a ritual to getting in the flow.

Usually the first thing people will do when sitting down to code is check Facebook, Twitter and email. Not always in that order, not always all of them, sometimes other social networks completely - Reddit, Hacker News and Stack Overflow are popular options.

Warm caffeinated beverages go very well with this sort of activity. Making them wastes little time, but introduces an impetus to keep procrastinating until you’ve finished the cup.

We call this procrastination, but the term carries connotations that aren’t fully warranted. Don’t think of it as putting off work, it’s more like defragging one’s brain. Making sure there are no more lingering thoughts in there, no notifications left unclicked, no important questions left unanswered.

After anywhere from a few minutes to an hour work can finally begin.

First, a programmer needs to make sure they are working off the latest version of the project. Then they must check whatever issue tracking system they’re using. Having a clear goal is after all paramount to achieving flow and getting anything done.

Next up, the work environment.

Swing by a programmer’s computer some time and you will likely see a desktop littered with open windows, consoles, IDE’s, text editors, documentation. Everything.

Unlike many (most?) people who use even modern computers as a single application environment and often maximise whatever software they are using to fill the whole screen, programmers are a different beast all together.

There’s usually a text editor and a console or two, perhaps a debugger, a browser with some documentation is almost mandatory as well. Often all these tools will be unified in a single Integrated Development Environment (IDE), which is a mere euphemism for “A bunch of stuff, but in a single window”.

Loading up a work environment like that takes time, not because our computers are slow, but because to know which tools you need, requires understanding what you’re about to work on. Keeping things open helps so much that a session crash or a context switch to a different set of tools can be totally devastating to a programmer’s productivity.

Then, the programmer must prime their mind.

Programs are a conversation between programmer and computer. Computer and user. The programmer’s job is breaking down a problem into understandable bits and explaining the solution to the computer in such a way it can be executed perfectly every time. Or at least well enough.

Loading a program into your brain means learning its language. Functions are verbs, variables are nouns and there’s plenty of things in between. Notes can help. Keeping tools open also helps. But nothing will get you over just how much brain power it takes to understand a software project.

Every time you lose sight of the whole system you have to build it again like constructing a glass palace. Once you understand the language, you have to arrange it in your mind so the space can be freely traversed, you can close your eyes and see how different parts of the system affect each other.

Only after this stage has been reached is a programmer fully effective. Only then can they have any chance of reaching flow because they don’t have to stop every five minutes to figure out how their code fits in the larger picture and whether it’s even doing what it’s supposed to.

When you interrupt a programmer, this glass palace can come crashing down in a shower of shattered glass. They have to start the whole process all over again and it’s going to take a while before they’re back to full steam.


Not all distractions are created equal and not all will cause an interrupt

You will often see a programmer walking along the street, eyebrow furrowed, peering into the tips of their shoes, lips clenched. Do not try talking to them. This is a programmer who is deep in thought on a problem, struggling hard to prevent the glass palace from tumbling.

Ask them a question and it can all be gone in the blink of the eye. All that hard work and deep concentration, just gone. Simply because they have to think about something else.

It almost doesn’t matter how simple a question you’re asking, anything requiring a proper answer will cause a lot of trouble. Most programmers tend to resort to communicating with grunts and various sounds. Or simply saying “Yeah yeah sure” to everything.

The danger is not knowing they weren’t really listening to you and just said something so you’d go away and stop bothering them. Flailing hands and raised voices can also happen.

Almost more important than whether the programmer had to do some thinking in response to a distraction is whether they chose to be distracted or it was something outside their control.

Most people working with computers will often distract themselves. After being focused for a while they will start wasting time on the internet. Nobody told them to do this, often there isn’t even a notification saying something new happened, it just feels like “Hey, I haven’t done that in a while! I should check if there’s anything new!” … there usually isn’t. Not much anyway.

I’m lying, there’s always something new. But it usually isn’t interesting or something that feels worth the distraction.

However, random rewards keep us hooked and we can’t help ourselves but to check, pressing the button like a lab rat desperately trying to get the next nugget of food from the magical big button.

If a programmer can prevent themselves from straying off into the wild internet and getting lost for an hour, this sort of distraction won’t cause much of a problem. In just a few minutes they will be back to coding at full blast. These sort of distractions are usually just our brain saying we should take a break anyway.

Conversely even the shortest external distraction can be devastating.

Most distractions come from coworkers who are just trying to get their work done, but need your involvement - the gordian knot of working in a team of programmers is having two programmers who depend on one another. Both are in a state of flow. One of them has a problem. Do they destroy their productivity by waiting on the other person to naturally come out of flow, or destroy the other person’s productivity by interrupting them?

Hopefully they can work on something else, but this requires a context switch to a different problem as well.

Programmers also run on a different schedule than most people, which can cause plenty of problems. When the cost of getting started is as high as it is for programmers, it doesn’t make sense to work in stretches shorter than a few hours. Everyone else divides their time by hours or even half hours. I’ve heard lawyers charge in increments of fifteen minutes.

Even the prototypical calendar app divides the day into hours and half hours …

If there’s one thing you should know about dealing with programmers is do not distract them. Wait for them to come to you. Just put your request in the queue.

Never expect a programmer to do something immediately.

A primer on sleep science

Here will be some stuff about sleep science.

Especially how it relates to productivity and creativity, outline to be created when I’ve found&read more studies.

[a lot of this section has been sneaked into how-for-programmers, perhaps it fits better there, or those bits should be pulled from there to here]

Shifting sleep schedules

Of course you could code before 3pm, a lot of people do. You likely wouldn’t lose a bet saying most employed programmers spend a lot of time at work before 3pm.

But without an external schedule coding at night just feels more natural. It’s when the fun stuff happens.

You still need to sleep, though. What happens when you go to bed at two in the morning? You wake up at ten in the morning, perhaps nine. If you’re really hardcore even at eight.

Come evening, you don’t feel sleepy until midnight. You’re just working on something interesting, so you keep working until 1am. Or slightly later.

Eventually your sleep cycle shifts into a different timezone because you keep going to bed later and later, because you’ve woken up much later and so on ad infinitum until your alarm clock and society pressure put you in an equilibrium of sorts.

For a lot of people that equilibrium seems to be waking up at 11am and going to bed at 3am. I don’t know why.

Bright screens

One of the biggest factors in human sleep-wake cycle is natural light. Scientists have shown that without external stimuli we would all be living on a roughly 26 hour cycle, but there are systems in our bodies that help us sync with the sun.

This is very important because days aren’t equally long and before artificial lighting it wouldn’t be very useful to stay awake for the same time in winter days as in summer days. Doesn’t make sense and you need to conserve energy when it’s cold anyway.

Modern lighting plays foul with those principles. Computer screens especially.

This is because the light coming off our screens is very white, aimed right at our eyes and usually insanely bright because monitors are set to stupid brightness levels by default and most people forget to change those.

All of this just plays back into the not-becoming-sleepy problem and keeps us up longer. Because we aren’t sleepy, we might as well work huh?

For people around programmers

Having programmers in your life can be challenging. They’re a strange bunch, keeping odd hours, telling jokes you don’t understand, speaking what often seems a foreign language full of words that sound English, maybe.

Their jargon is full of githubs and lusers and version control and 10 kinds of people and emacs and vim and console and hash tables and mongos and in-memory cloud services and … it gets pretty bad pretty quick. Even this book is full of such jargon because as a programmer I often forget I’m speaking jargon at all.

As such, the programmer community can seem impenetrable to the uninitiated. The fact it’s dominated by human males with stellar egos and often terrible people skills doesn’t make the situation any better. I don’t know if other male dominated cultures are the same, but it’s very common for a programmer to exclaim “Oh my god, what idiot would code this!?” when looking through somebody else’s work.

Only to realise a moment later it’s their own code from a year ago. Oops.

We even have a website aimed specifically at making fun of people doing stupid things. The Daily WTF is a bit like our very own fail dot com.

But don’t let this confuse you. Programmers are actually one of the most accepting bunch of people I have ever met. Where else could somebody tell an almost complete stranger that they’re gay and the other person barely shrugging their shoulders?

San Francisco maybe.

Show a little interest in their craft and programmers will accept you as their own. Nobody will even notice you’re a purple sea monster, they will just shower you with enthusiasm and try to teach you everything.

Very quickly. Very powerfully. Very overwhelmingly.

But it’s a good kind of overwhelmed I hope. Programmers love to teach; just look at the plethora of personal blogs aimed at nothing more than having nerdgasms over a new hack somebody’s discovered.

If there is but one thing you take away from this book, it should be that programmers are enthusiasts.

Living with programmers

[currently conducting interviews about living with programmers, section incomplete]

I have a little confession to make - I don’t know the first thing about living with programmers. Other than once having spent two months in a four bedroom house filled with six programmers my only experience has been that of other people having to live with me.

And in their words, it isn’t easy.

One woman reports living with a programmer takes a lot of sacrifice. Since he works from home and is so difficult to drag away from the computer they mostly talk via IRC because it means they don’t have to get up from their respective computers and actually talk face to face. They don’t eat together either, much easier to quickly grab a bite at the computer than make the extra effort of being away from your work.

For both of them actually.

Yet another man, a programmer himself, says living with his programming wife is like winning a lottery. She understands when he has to work late, can even use it to work late at her own work when he manages to call in ahead of time, and when they’re both home they help each other with logical problems. Talking about work at home and having the other person really understand what you’re talking about, is a godsend, he says.

Maybe all it takes is a bit of understanding from both sides, and yet it seems like this understanding is difficult to achieve if you are not yourself a programmer or some other type of creative.


Working with programmers

The greatest challenge of working with programmers is having two people working closely together on a single project. Probably sitting close by they are the best source of interruption for each other.

Imagine you are one of the two. Getting up to grab some coffee, do you ask the other person if they want some as well? When hitting a snag, do you ask them a question immediately or wait until a good moment? Noticing a magnificently hilarious cat picture, do you tell them? Share it immediately or send an email, or keep it to yourself?

The answer to these questions will define how great you are to work with.

How interruptions spread

There is a team of programmers working together in an office. Deep in thought, code effortlessly flowing from their fingertips, one of them suddenly hits a snag. It happens because a related piece of code designed by another programmer is behaving in unexpected ways.

Unable to resolve the issue themselves they are violently thrown out of flow. Snapped back into reality our programmer looks around the office in dazed confusion. Will somebody notice their plight? Will somebody volunteer a helping “What’s the problem? Can I help?”, or is everyone too deep in their own mess to notice?

One of two things is going to happen next.

  1. Nothing else to work on, no desire for some creative procrastination, the developer musters the courage to ask a question now. They walk up to the person they reckon could help and ask them a question. Now both developers are out of flow.
  2. The other likely possibility isn’t much better. The developer first arses about on the internet for a while, hoping this will jog their brain and produce a bit of inspiration. It doesn’t work. They get up for a walk - somewhere deep in the recesses of their mind a small voice is saying they need to stretch their legs. Another developer notices activity out of the corner of their eye and decides it’s time for a break. Now both developers are out of flow.

There are infinite variations on these two courses of events, but they all result in the same thing. Two interrupted developers who will take half an hour at least to get back in flow.

But now the interruption is gaining momentum. It will spread person to person until everyone in the office is out of flow. As the group becomes louder and more chaotic so its interruptive potential grows. Each new member also adds another connective point for interrupting somebody else.

Of course there is also a dampening effect so the smaller and more personally connected the team, the likelier it is all of it will be affected by an interruption.

These events are inevitable, what’s important is how far they are allowed to spread and whether they are productive in solving the problem that started them. A certain number of productive interruptions is healthy, even necessary, too many can kill everyone’s productivity.


For most software projects communication is vital. I’d say all software projects, but hanging out with theoretical computer scientists has made me wary of infinity.

Different communication styles fit different parts of the project. While face-to-face meetings might work best to eke requirements out of clients, instant messaging often works best for software teams to avoid interrupting one another.

Having just the right amount of communication so things run smoothly and developers still have enough time to work is an art that takes most people a few years to develop. Some never get there and the internet is full of programmers complaining about co-workers and pointy-haired bosses.

Programmers hate meetings and with good reason.


Meetings are the best example of a culture clash between people on the maker’s schedule and those on the manager’s schedule. For a manager, the meeting takes an hour and after a quick break they’ll be ready for the next item on their agenda. In terms of time the meeting is free, not only that, it’s exactly what they are paid to do and likely represents the best use of company assets.

At least a productive meeting does.

For a programmer the story is different. A single poorly timed meeting can kill an afternoon, sometimes even a day. It takes a while to get back to work and the effort might not be worth it, if there aren’t going to be a few hours of empty time before day’s end or the next meeting. Another half hour is easily killed before the meeting even begins if the developer reaches a natural stopping point and an imminent meeting means there’s no sense in continuing with the next task.

Sure, it’s important for programmers to pass know-how between one another and they should definitely be kept in the loop about project objectives, but a meeting is almost never the most productive use of a programmer’s time. Especially considering a one hour meeting can easily take three hours of a developer’s time.

At $50 an hour a one hour meeting between two programmers is worth $300 in time. Keep that in mind the next time you want to call a meeting, especially if a simple email would do.

Even deciding that a meeting is in fact worth everybody’s time, there are other issues making meetings less than ideal.

When people can’t go to meetings in person due to geographical constraints, we resort to Skype or similar technology - I hear a lot of people still use telephones, even if mostly for one-on-one conversations.

But participation in a dynamic meeting when you aren’t really there is difficult at best.

Your field of view is narrow, sounds escape the mic, crappy internet connections can make your words choppy or keep you a few seconds behind everybody else. What’s worse, even modern means of real-time communication can’t solve scheduling conflicts.

And yet, it’s important for everybody to know what happened in the meeting. Add the fact that human memory is fallible and you have a situation where even the people who were there will soon forget what went on.

Meeting minutes will solve the problem for everyone to an extent. Those not present will get to know the main takeaways of the meeting and even after a while everyone will still know the decisions that were made. But the minutes don’t capture everything that happens in meetings.

Conversations race ahead of the person taking notes, they diverge in many directions and often run in circles. Even if the minutes were perfect, they would be boring and difficult to follow. Small teams in particular tend to just write down some notes instead of detailed minutes.

Asynchronous communication

Communicating primarily through email or issue tracking systems can solve these problems completely. What you lose in throwing away nonverbal cues, you gain in the perfect logging of conversations and decision making processes.

More importantly, a well written email or issue ticket is much better at conveying information than the muddled real-time thought flow we see in verbal communication. People think before writing.

Perhaps this is a cultural thing, but I have rarely seen people take some time to think through what they are about to say. There is an impetus to avoid pauses lest you seem “slow”. To think out loud instead of providing complete answers. This is often a good thing, it lets everyone in on your thoughts, avoids any chance to pad out the painful truth with niceties.

Thinking out loud can also cause problems when a stream of half thoughts makes it difficult to pick out a good solution. Conversations become difficult to follow, especially in notes, and having quick loud thinkers mix with those wanting to think before they speak, can easily ensure the latter never get any air time at all.

As engineers usually have a low tolerance for bullshit and half-baked answers the most valuable input will often not be heard. Not only that, listening to other’s half baked ideas will make many an engineer feel like their time is being wasted.

Another thing emails solve well is group yak shaving.

This happens when somebody raises a tangential point that piques everybody’s interest. Before you know it an architecture design meeting devolves into discussing an implementation detail of a soon to be discarded feature.

It feels productive, everyone is learning, but it gets in the way of solving the issue at hand.

When this happens while writing an email I will often cut it out after developing my thought and realising it adds nothing to the overall message. That would be 10 minutes of a meeting wasted.

Sometimes I decide I don’t even have to send the email anymore. Just thinking through a problem enough to explain to somebody can solve it for me.

Also, don’t underestimate the benefits of reading and rereading a complex bit of technical info until understanding is reached. Talking in person means the other person needs to repeat what they’ve said multiple times.

This depends of course on the teaching skills of the other person, sometimes they can munge their explanation so everyone understands.

Taking advantage of interruptions

No matter how much you try to avoid it, sometimes a combination of email, instant messaging and issue tracking systems just will not do. You have to speak to somebody in person.

However, the general motto still stands, unless people are dying - and they rarely are - you should respect a person’s time. Being interrupted while working can create a big mess, so just don’t. You wouldn’t want somebody interrupting you in the middle of, say, a phone call, would you?

So what are you to do?

Take advantage of naturally occurring interruptions. They also happen to be the easiest to deal with in terms of keeping mental context intact.

Let’s say you work in a team that does daily standup meetings to keep tabs on who is doing what and whether anyone has hit a problem and needs some help. This is a ten minute meeting that you can schedule, making it into a half hour distraction or more.

A better approach is to avoid scheduling anything shorter than half an hour at all. When the last person on the team comes into the office they will interrupt everyone by greeting them. Since it’s a positive interruption and such a minor one at that nobody will mind. Many won’t even break stride in their work!

Now is a great time to have that quick ten minute meeting.

“Daily standup” is a horrible buzz word anyway. It used to be called “Having a cup of coffee with my coworkers every morning”. You wouldn’t do bad to keep that in mind and treat it as such.

Batch processing

Another good habit to build when working with programmers and other creatives is batch processing. When you have something to ask, an idea to clear, or anything really, don’t giddily rush off and interrupt somebody.

Collect your questions and ideas. Write them down on a post-it note, in a notebook or in an email. When you feel there’s enough, wait for a good moment and ask the person for an extended moment of their time.

Programming is fraught with natural stopping points.

When you finish a function. When you write some tests. When you run a full test suite. When you press compile. When you finish a feature. When you pinpoint the code where a bug is hiding. When you …

This is programming’s curse. This is why programmers often get sucked into the vortex of online discussion wasting more time than they would like. But it’s also a blessing because it gives their colleagues many opportunities to interrupt without actually interrupting.

When a programmer has reached a natural stopping point in their work they are naturally inclined to take a little break. Not only do they need to think for a bit before moving on to the next granular task on their list, but the feeling of having just finished something, no matter how small, makes a person want to sit back and bask in the glory.

Now is the time to step in and go through the batch of problems you need help with. It’s also very likely that any email you may have sent will be answered at such an occasion.

The problem, then, is spotting a programmer who is between steps.

The simplest way is to leave the decision up to them, send an email, wait for them to answer when the time is right. However, this is fraught with worry whether they noticed the email, how diligent they are with responding to everyone and a bunch of other little problems that mostly have to do with trust.

By the way, do try to clean out your inbox at least once a day. As a courtesy to everyone who respects your time enough to avoid bothering you directly.

Another great approach is to look for signs of procrastination and general time wasting. Is the focus on a twitter client? Are they looking at a browser and it isn’t documentation? Playing office warfare or spinning in their chair? Perhaps just getting up for a cup of tea?

That’s your cue. Pounce.

One thing to keep in mind is fitting everything inside this natural stopping point zone. I find anything that will take longer than five minutes needs to be scheduled off into the far distance. Usually at the end of the work day or in that half hour after lunch when I’m putting off getting back to work.

Don’t try to fit anything “hard” in those five minutes either. Where hard is defined as anything that requires thinking deeply about something other than whatever the programmer was doing before. Simple things are okay, helping you with a bug is not.

It will take just five minutes

Coworkers often don’t understand how long it takes to code something. Non-technical people especially, but programmers are just as guilty.

Just the other day I was talking with a mate on Skype who complained that his boss will often egg him on to add just one little thing. “Come on, it’s only going to take five minutes, you can add it.”

Despite trying his best to resist these small tweaks, he usually breaks down and adds it anyway. This happens partly because programmers in general are less skilled negotiators than managers whose job is mostly negotiation. There’s also a power dynamic at play - it’s usually difficult to deny a boss’s request.

But more importantly, it’s very difficult to make a logical case that X is not a five minute job. Of course you can add a small button to a webpage in five minutes. Ten minutes tops. It’s no more than a line of code. How could such a small piece of the puzzle possibly take more than five minutes?

Exactly because it’s a piece of the puzzle.

When systems grow the complexity no longer lies in individual pieces but in the system as a whole. For a programmer to add a small five minute feature they have to first consider the whole system.

Does the system support adding that one feature? Will I have to bolt this on as an ugly hack to make it work? How many things need to be redesigned to make this feasible?

When all of that is considered, it takes at least five minutes to spin up the development environment. You have to open a text editor, something to test your code and so on. As a web developer I usually have at least one Emacs and one Chrome windows open.

Then you have to find the right file to implement the feature in. Because your system has grown so much you can rarely implement a tiny button using a single file. The button goes in one file, its styling in another, then there’s a file for making the button actionable and often a fourth file for the text.

Each of those files will be several hundred lines long and you have to find the right place for new code in each file, consider what other code you can reuse and whether any existing code needs to change to accommodate the new feature. Even the best mental map of the files and search technique will not save you from reading a few dozens lines of code.

Scanning through some 1500 words (counting important code symbols as words and assuming an average of 20 per line) takes time. You can read about 300 words per minute on average, which means you are going to spend five minutes reading code before you even get to implementing your five minute feature.

Now that the programmer has spent at least ten minutes implementing that quick fix it’s time to test. Which means a round of writing tests or clicking around the interface. Usually both.

After twenty or so minutes have passed that quick five minute job is done.

Now they have to keep supporting it for the rest of the product’s life cycle. This means keeping it in mind next time a small feature is implemented, making sure it works when surrounding code changes and keeping the user experience consistent.

That five minute quick feature will take hours of developer time over the next few months or years.

Tips for programmers

You can’t work all the time. I used to think that you could and nearly flunked out of high school as a result.

“I have found a cure for sleep! Green tea with crap loads of sugar!” I proudly exclaimed on a forum board shortly after my first dose of caffeine.

I was 15 or 16 and I had just declared war on sleep. There just wasn’t enough time in the day for everything I cared about and all that stupid school stuff. Of course I thought school was stupid, I was a teenager and I knew best.

I spent my afternoons and nights programming in PHP - the most popular web programming language at the time. I squeezed in 10 minutes wherever I could and quickly rose to relative prominence in the phpBB community - a popular forum software of the time - as a plugin developer. Mine was the most popular plugin for topic descriptions with over 10,000 downloads.

Pretty good for a 17 year old huh?

On top of all that coding I was writing and drawing webcomics, getting my feet wet in making money as a web developer and starting novels that I never finished. I was on fire!

A native English teacher once started a group discussion with “What do you think is the perfect amount of sleep?”.

We used these discussions to practice speaking in English. Talking to a native was a special treat because he could only join us once in a while.

“FOUR HOURS! Four hours is perfect.” I proclaimed feeling smug.

Everyone thought I was posturing. The teacher shrugged it off as me trying to be the class clown.

But I did go through most of my high school years sleeping about four hours a night. It was a dumb move and all that energy had to come from somewhere - school.

Every morning I was at least five minutes late. Every day I slogged through school like a zombie and barely registered what was going on around me. I had enough energy to avoid falling asleep, but my long-term memory was shot and I don’t even want to try remembering what my comprehension levels were.

My grades hovered around D’s, or 2’s. Famously I once didn’t get a single positive grade in Chemistry all year.

And then, in the evening, as if by magic I woke up and worked non-stop until 3 or 4am. Nothing could stop me. My biological rhythm was completely out of whack with what society expected.

My natural rhythm still isn’t what many would consider normal, but I’ve found many ways of making it work and staying alert at all times.

Mental energy

Intuitively we all know what it means when somebody says “I’m full of energy today.”

Energy is that thing you have more of when you’re rested and less of when you’re tired. When you’re full of energy you’re buzzing around and can barely contain yourself, while somebody who’s low on energy just sits there staring straight ahead with an empty expression.

Everybody also knows their energy fluctuates through the day depending on their natural cycle, how long they’ve been awake, what they eat and so on.

For instance, many say they feel a spike of energy when it’s not quite morning anymore, but not quite lunch time yet. Then they feel slow after lunch and have another peak in the afternoon before winding down for dinner and then some people have another spike later in the evening while others fall right asleep and never pick up until next morning’s work.

But what are we talking about anyway? What is energy?

It’s not exactly physical energy - that’s measured in joules and relates to physical work. It’s something more subtle than that. It’s got almost as much, if not more, to do with how we feel rather than how much we can lift, or move, or how far and fast we can run.

Feeling low on energy doesn’t mean our physical energy is any lower. Sure, it’s related, but you can be mentally tired and physically strong as ever. Or physically tired and your mind is racing.

What being full of energy means, is that our mental energy is high and we feel motivated and capable of doing work. Even excited.

Since the early 2000’s scientists have been researching the concept of mental energy using a combination of cognitive performance measurements, self-evaluation questionnaires and tests of physical ability.

They’ve discovered our feelings of mental energy directly correlate to cognitive performance in terms of short term memory and ability to take decisions quickly. It didn’t seem to have much effect on other cognitive performance factors, other than general motivation. Having high mental energy tends to mean you’re more motivated to solve complex tasks, which makes you slightly better at them.

You’re also able to hold focus better when you’re rested, which does correlate with mental energy, and thus indirectly factors into your performance on cognitive tasks.

Interestingly enough, the same correlation holds for physical performance - higher mental energy means more focus, means a greater ability to overcome stressors, means better physical performance. Mostly in terms of endurance and maximum strength.

As such, there are two parts to the mental energy equation.

On one hand it’s a mood - how much energy you feel like you have. This affects your performance through motivation.

On the other hand is the more interesting actual mental energy, which measurably affects your cognitive performance in short term memory and decision tasks. It’s more interesting because it’s more measurable and its effect is more pronounced.

More importantly, you can have high mental energy, without actually feeling like you are high in energy. This will

[have to dig up studies again and add more specific quotes]

In short, your mental energy is a measure of how energetic you feel and how well you perform on certain mental tasks, but doesn’t affect your physical performance or even most cognitive tasks.

Maintaining mental energy levels that are useful for quality programming is therefore mandatory.

[this justification is muddy at best, have to better present what tasks are affected and why they’re important to programming]

The rest of Tips for programmers is about lifestyle choices that affect mental energy.

Long hours

In July 2013 I visited the US to help bootstrap new startup team bootstrap. The main advice I had to give was focusing on working normal hours because that leads to better productivity.

This is obvious to everyone from Europe or who isn’t used to working with startups. They adopt a US type of work culture even in Europe. Always being strapped for time and cash and having infinite competitors breathing down your neck makes young people want to work insane hours to make up for whatever they think is missing.

But in this startup we executed just fine working 11am to about 7pm. Eight to nine hours of office time, but including lunch and the morning wind up we were averaging about six hours of hard productivity per day.

A lot more than the maybe four hours of work moments, as Jason Fried calls them, your average worker stacks up in an eight hour day.

We wanted to have a working minimum viable product ready in a month. And by ready I mean we wanted to let people loose without having to ask them not to click on things or apologizing about every other thing they try not working.

Zero lines of code to a finished product in a month is a tall order. Naturally, you want to start as soon as you wake up and work until you fall asleep on your keyboard.

This is the wrong impulse.

There are no long distance sprinters. A month is a lot more time than you think. At five days a week and six hours of uninterrupted productivity per day, a month gives you 120 hours.

A good engineer can do a lot with 120 hours of focused productivity. At competitions products are frequently launched in no more than two days. After a month we did end up with a presentable MVP.

It was great, but towards the end we panicked. That last week was the perfect example of why programmers shouldn’t work long hours.

Friday was the day of the big investor meeting. What was supposed to be just a friendly “Hey what are you up to?” over lunch, turned into a proper meeting at the investor’s office.

On Monday we panicked.

The product was well on its way, but you know how software projects are. Until it’s done, it looks like it will never be done. Worse still, the last polishing touches take the longest.

There was no way we were going to let the founder go into that meeting with a product he doesn’t feel comfortable letting the VC play with on their own. Time to do whatever it takes.

That Monday we took a very short lunch and worked until nine o’clock. To reward ourselves for getting lot done the engineering team went out for dinner, tentatively planning to work more afterwards.

We just had to get away from the computers for a bit, you see. Oh no we weren’t tired at all. Who gets tired after a longish day of coding? Pfft, definitely not us!

Dinner lasted until eleven o’clock and we didn’t do any more work that day.

Next day people came in to work before 11am. By eleven, everyone had finished eating breakfast and was coding furiously. There was a deadline to catch and nor hell nor high water would make us miss.

Lunch was a quick twenty minute break and we continued working furiously. After six or seven in the evening the dynamic started changing. There was more and more office chatter. First a conversation between two people wandering off into play land here and there, then more and more people migrating to the kitchen to stand around and chat.

By eight o’clock nobody was working.

They thought they were working. After all, they were at the office, they were talking about work, but nothing was getting done.

After a take-out dinner everyone got back to work around 10pm. At midnight, after some thirteen hours at the office, my brain reached a point where naming a new variable was a struggle, so I stopped.

Everyone else continued until 2am. I don’t know how much they got done in those two extra hours, but the vibe was nothing at all like the vibe of a bustling place with everyone working at peak performance. It felt more like a town in the middle of a siesta full of tumbleweeds and old geezers lazily observing you from street-facing chairs.

Wednesday at 11am, the office was empty. Half the people staying at the startup house were barely waking up, the rest of us were eating breakfast. The commuters were nowhere to be seen.

Lunch was ordered in once more to save time. Everyone took care to pick a food within five minutes so there wouldn’t be any delays. We were on fire!

Normally people would have to be dragged away from their work at lunchtime, but that Wednesday they jumped from their computers the moment delivery rang the bell. Then we sat outside in the shade, talked and ate. Despite the looming deadline nobody quite felt like getting up and going back to work.

We finished eating in ten minutes, but lunch took an hour.

We just sat there and talked. Some of it was about the work, some about the team, all of it unproductive. There was a lot of patting on the back over how productive we’ve been this week and how long hours we’ve worked. People need that. They say it as much to reassure themselves as to give kudos to the others.

That afternoon didn’t feel as rushed and full of energy as Monday or Tuesday did. People got up to get something from the fridge more often. When somebody went to the kitchen many more eyes followed and a lot more people decided they needed a snack than they usually would.

By the time I returned from my evening run nobody was working anymore. They were hanging out in the kitchen making dinner. We decided to eat in to save time.

Dinner took until 10pm - two to three hours. Despite our best efforts to save time.

Last person to type something into the text editor gave up at 3am. Everyone else had started shifting from work mode to play mode around midnight. Think I gave up at a quarter to 1m when I reached some milestone I’d set for myself. The last two hours were spent on a tiny little thing I could have done in twenty minutes the next morning.

But such is life with deadlines. Doing something in two hours that you could do tomorrow in 20 minutes.

On Thursday we started even later. I doubt anyone at the office typed anything into a text editor before 12:30. The vibe in the office was that of a train station without shade when it’s 38C out.

Sluggish mechanical movements. No brain. Only muscle memory.

Better had we all stayed home instead of come to the office and pretended we’re being useful. But there was a deadline to catch don’t you know? The product was coming together, but there were bugs to iron out.

There will always be bugs to iron out.

That afternoon the founder announced the meeting had been postponed for one scheduling conflict or another. A weight fell from the room and within an instant there was no more typing. No more deadly silence. Everyone stood up. Stretched. And started chatting.

At 7pm we stopped working. If anyone was even working at more than 20% …

On Friday we were back to normal. No deadline. No pressure to work super late. We got it done. That evening the product worked.

The new meeting was on Monday morning. Sunday afternoon was bug fixing day - first time in the company’s history that people were expected to work on a weekend.

Dangerous precedent for a month old company to set, but they’ll learn. Long hours are debt you repay on the third day.


But there are ways to work long hours without burning out in less than a week. Through experiments I’ve stumbled on a routine that’s helped me work consistently long hours at full blast with barely a problem.

After my burn out two years ago I had to figure out a way to get a lot done without getting too tired. The schedule of jumping out of bed at 9am still full of caffeine from the guarana pills I had taken before bed and then working until 4am through a haze of black tea and energy drinks with one or two long breaks just wasn’t sustainable anymore.

My biggest discovery was routine.

All my life I had prided myself on being a free spirit who doesn’t plan anything too far in advance. I never kept a ready schedule, woke up when I felt like it, ate when I was hungry, slept when I couldn’t work anymore.

That isn’t very productive. You spend most of your time figuring out what you’re going to do next. In the morning you have to think about what you’re going to do before lunch, which deadlines are most imminent and what do you want to accomplish. Or just what you feel inspired to work on.

Not a very good way to catch deadlines, and not a great way to get anything done. Too much overhead and uncertainty.

A steady routine works much better. Wake up at roughly the same time every day, always us the same process to gear up for work, have lunch in roughly the same time window every day, stop working and get to bed at similar times every day. Even use a similar sequence of events to fall asleep.

It might not be the most exciting life in the world and the strange feeling of “Holy crap, when did I become so organised? Is this even me?” might never completely go away, but you always know how much work time you have in a day and exactly how much you can get done.

The consistency makes conversations with your boss or client much easier. Yes you’re only doing 6 billable hours per day, but you’re banging out six solid hours of peak productivity day after day after day.

Most people can’t ensure that even four days in a row.


The routine that works best for me is based around the pomodoro schedule.

Pomodoro is a time management technique discovered by Francesco Cirillo when he was studying for a lot of exams in college and had to find a way to work for hours on end without becoming tired. It worked and soon become popular all over the world, known as the pomodoro technique because he used a pasta cooking timer in the shape of a tomato. Pomodoro in Italian.

The idea is that when you sit down to work you turn on a 25 minute timer. While the timer is running your full attention should go to the task at hand. No internet, no tweeting and email and facebook, no conversations with coworkers. Just you and your task.

Then you take a 5 minute break.

During the break you can do whatever you want. Prowl around the internet, talk to the people around you, answer emails. Whatever you want.

After going through four pomodoros it’s been two hours and you’ve done an hour and forty minutes of focused productivity. That’s a lot more than it sounds. People can go weeks in an office environment without ever doing a solid hour and forty minutes of distraction-less work.

Now it’s time for a longer break. I usually do a 30 minute break that is extended to 45 minutes if it’s time to eat something, or shortened to 15 minutes if I’m full of energy and staying away from work feels like a struggle.

After two two hour sessions I take a longer break. At least two hours, sometimes three. This lets me deal away with the bigger meals of the day, boxing practice, chores around the house and so on. I try to use this time productively, but doing something other than work so my mind has a chance to relax and think through problems subconsciously.

The breaks are paramount to good coding without getting too tired. They can be very hard to take when you’re feeling frustrated or things aren’t working and you try to power through. But with some practice it’s easy to achieve enough discipline that this doesn’t happen very often.

When I do start ignoring my pomodoro timer it’s often a sign that I am already completely wasted, banging my head against a brick wall and I should probably just get up and go for a walk because I am not solving this problem tonight.

But while discipline matters, it’s also important not to go overboard with following the rules.

When I started out using pomodoro I was strict to the point of nonsense. When the timer rang that the break is over I stopped reading the article and only continued after 25 minutes. I stopped writing tweets mid-word and so on.

In the beginning that’s important, but it leaves a lot of unresolved tiny tasks behind that drag at your mind when you’re working and keep pulling you out of the zone. You have to keep in mind where to get back to reading the article, you have to know what you wanted to say in that tweet and so on.

These days I use a more statistical than deterministic approach to the pomodoro technique. My breaks are 4 minutes on average with about a 2 minute variability. Sometimes I drag out the work time so I can finish writing a line of code and I start my break after 26 minutes of work. Sometimes a break drags on to become 6 minutes and I will often take my break a minute or so early if I’m already feeling tired.

Pomodoro is there to give your day structure, not to be just another thing to stress about.


My old startup advisor once said “When I go for a swim in the morning, nothing that happens for the rest of the day will make me feel like the day has been wasted.”

After years of experimentation I agree. My morning poison isn’t exactly going for a swim, but I’ve also discovered that a good morning routine well followed will make you feel invincible for the rest of the day.

No matter what happens, you will always be in high spirits because you’ve already achieved something before your day even started. The morning doesn’t have to be a mad dash to drown yourself in coffee and drive to work. That’s not a morning, that’s torture.

Now I’m no morning person by a long shot, but it still makes me sad when I talk to people who say that all they want to do in the morning is sleep for as long as possible and then grumpily climb out of bed, sit behind a computer and vegetate for the rest of the day. That’s no way to lead a life!

Even worse are the people who grouch off to bed at 10pm so they can climb out of bed by 6am, drag themselves to work by 7 or 8am, then stare at the computer screen with bloodshot eyes for an hour while sipping on a large cuppa.

Just because their boss is a butt-in-seat-time kind of guy who doesn’t care whether people are working, only that they’re there.

I started working on my morning routine when I noticed that I don’t get anything done before lunch. There isn’t enough time between waking up and having to start cooking to get into flow and get anything done. More often than not I ended up lazily eating breakfast, watching television and hopping around the internet.

Over time I developed a morning routine that lets me get a lot done without actually doing any work work yet.

My current routine starts around 9am with brushing my teeth and checking if anything interesting happened on the internet while I was asleep. Then I exercise for about an hour - leg days take 50 minutes, arm days take 70 minutes. The PumpUp fitness app has a personal trainer mode that makes sure I keep on time and don’t drag my breaks.

While working out I usually hang out on the internet during the breaks because staring at a wall for two minutes gets boring.

After working out I start boiling eggs for breakfast and take a shower while they cook. It takes about 9 minutes from eggs in cold water, to perfectly boiled eggs. 8 minutes during summer, 10 during winter. Yes I measured; I like having a perfect breakfast every time.

During breakfast I sometimes watch a half hour TV show if there’s something new to watch that day, or I just have a quick breakfast and stare out the window. The problem with shows is that they slow down the morning routine, but it’s the cleanest way to fit keeping up with my stories into the day.

After breakfast I do my daily 750words and take five minutes to clean up the kitchen - unload the dishwasher, clean up after breakfast and so on.

When I’m done I have an hour or two left before lunch so I can write. More often than not I have to start cooking while writing because the current morning routine is too long and I have to work on shortening it. But I might have less of a problem now that I’ve finished catching up on Dr. Who, which has hour long episodes that I don’t have the discipline to stop watching as soon as I finish breakfast.

After lunch I’ve had a super productive morning, finished most of my chores, done my writing for the day and can focus completely on my coding work for the rest of the day. Nothing can stop me.

The exact routine you choose doesn’t matter, find one that works best for you and fits into the timeframe you have. I can get away with a very long morning routine because I work from home as a freelancer so there is no commuting to factor in, no external work schedule to keep and my clients don’t care when I do billable work. Just that I do the amount we’ve agreed on and that I spend the time well.

What matters most is that your routine is set in stone. There should be no guessing what comes next, no figuring out what to have for breakfast and you should generally minimize the amount of decisions you have to make before you even get started on working because there’s only so many decisions you can make in a day. Most of the things you do should just be the default.

For instance, I can pick from only one of two breakfasts, an app decides how I exercise and the sequence of events is always the same.

The factors you’re optimizing for are:

  • be fully awake (exercising)
  • clear away small nagging tasks (dishes etc.)
  • clear away all concerns and worries (750words)
  • reflect on what your day will look like (750words)

Experiment. Have fun.

[this part needs to be turned around so it starts with the optimization parameters and then extrapolates my routine from those]


Another important part of the day is your evening routine. It helps you wind down from the day, sleep better and wake up in great shape next morning.

To be honest I haven’t paid as much attention to perfecting my evening routine as I have the mornings. In part because it doesn’t feel as important, in part because evenings often get messed up by the crud that accumulates through the day, various social engagements and because I don’t tend to have a lot of evening left after I’m done working.

My evenings are usually split in two parts. Evening proper when everyone else is having their evening as well and late night evening when I wind down from work to get some sleep.

The first part of my evening comes when I have to leave for boxing practice. Ideally after two pomodoro sessions - 4 hours of work - but can fall on a session and a half if I take too much time for lunch. On the days I don’t have boxing practice I usually go for a run or do some other physical activity.

This gives me an hour and a half of strenuous activity to get a break from work and give me enough time to think through the problems I’ve encountered that day. It’s also just a generally good way to vent any pent up frustrations. Nothing like punching it out on a punching bag or running it off when you’ve been stuck on a tiny problem all day.

After coming back from boxing I always make the same dinner - rice with veggies and chicken. You can buy all the ingredients en bulk so it runs pretty cheap per meal and it’s also very filling, healthy and tasty enough that you never get bored of it. Or at least I don’t.

I also haven’t been able to find any other dinner that wouldn’t leave me starving after a heavy boxing practice.

Always having the same dinner again plays into my theory of minimizing the amount of choices you have to make per day and because rice takes about 15 minutes to cook, putting it on the stove while you take a shower works out perfectly.

After dinner and hanging out with whomever’s home at the time I can get back to work for another few hours. Usually a pomodoro session or two depending on how much work I’ve got left since the afternoon and how many problems I figured out while exercising.

My second evening falls between midnight and 1am. This one is devoted to winding down, clearing out my inbox and generally taking it easy. This is the only time in the day devoted to email because email is the least important thing I have to do.

If I still have energy left after dealing with all the email I will often do another hour of writing and go to sleep. Otherwise I watch a TV show of some sort and fall asleep while watching it.

Although I try to minimize how often I do that because I’ve discovered a correlation between falling asleep with a show on and oversleeping in the morning. Seems like I wake up much better when I just lay down, put on some white noise, and sleep.

Even when I fall asleep in roughly the same time. I don’t know what’s going on, but perhaps my sleep is lighter for as long as the show lasts because I keep trying to watch it despite dozing off.

Almost everybody I talked to while researching for this book spoke of a similar bipartite evening situation. After they’re done working for the day they will go home to have dinner and spend time with their families. Afterwards some of them get back to work for a few hours - usually the half-manager types who find this to be the only quality coding time they can find - others do side projects or work on a hobby.

Afterwards everyone does something to wind down and go to bed, whether it’s a glass of whiskey or a good book doesn’t really matter. As long as you can relax enough to stop thinking about work and have a clear divide between sleeping time and working time.

Those who just work until they drop don’t report good results in their or their work’s wellbeing.

Off days

A strict routine where every day follows the same pattern is great for predictability, minimizing the amount of decisions you have to make about mundane things, but it also starts grating on the nerves after a while. As days blend into one and you start feeling more and more like a terrible person wasting their adventurous spirit, it’s time to do something drastic.

Like put on different socks!

No, we’re not that boring around here. But you do need days that don’t follow a strict routine and let you be adventurous with your time. Same as diets really.

Staying in your pajamas all day watching television and eating chocolate is not an off day. It’s being a lazy bastard. An off day is a productive day taken at a slower pace and with less routine.

My off days come on weekends. I like to take both days easy by sleeping in and having a much shorter exercise regime in the ten minute range instead of an hour. Usually I will skip rope for ten minutes and call it quits. Weekends are also my reading time so I either read while waiting for lunch after working out in the morning or focus on reading for an hour or two after lunch. The rest of the day is spent either longboarding, working on writing or playing with a pet project.

It doesn’t matter what you end up doing, the important thing is that it’s something you deem productive yet relaxing and that it’s something you don’t usually have time for during the week. Reading and longboarding are perfect activities for me because they are both productive and I rarely have time for them during the week when my focus are freelancing projects.

Reading helps my writing style so it’s productive and it amounts to laying in bed while enjoying a good story so it’s relaxing as well. Similarly longboarding is a good exercise while also being pure fun.

In the end it doesn’t matter what activities you pick for your off days as long as you consider them a good use of your time and they break the routine.

And remember, needing lazy days is a sign of burnout. Follow the advice from this book and you shouldn’t need them unless you’ve been drinking or surfing too much the previous day.


There is no One Weird Trick. The internet has lied to you. But I’m not here to lie, I’m here to tell you that the only way to achieve peak productivity and coding bliss is to be healthy.

Your health depends on nothing but yourself. You have to watch what you eat, you have to get enough rest, you have to exercise. You.


There isn’t much I can tell you about food because I’m not a nutritionist, but I can tell you that what you eat matters a lot. Food has a large impact on your productivity in the short term and the health benefits of a good diet will affect your productivity in the long term.

The important thing about food is that common sense matters most. You don’t have to go for modern fad diets and fancy nutrition tricks to be healthy and have uniform energy levels throughout the day. Listen to your mother and your grandmother and you’ll be fine.

If your grandmother is anything like mine she tries to put you in a food coma every time you visit. That’s because she loves you, look at how she’s eating otherwise - a lot of small meals throughout the day with a few large meals to give everything structure.

Maybe it’s a living on a small farm thing, or just their age, but my grandparents wake up at 6am and begin their day with a small breakfast. Coffee and a bite of something with carbs. I don’t think the coffee is necessary, but carbs provide an oomph of quickly digestible energy to wake you up.

After they tend to the animals and do other small things around the house it’s time for a proper breakfast. Around the time normal humans wake up - 9am. This breakfast is a larger meal that includes protein as well. It’s meant to replenish the energy you lost doing physical work and provide a solid base for the rest of the day.

This is the only breakfast I eat. It fits perfectly after my morning exercise and according to my calorie tracker leaves me at net zero calories even though it’s substantial. Protein and fat digest much slower than carbs, which ensures I don’t get a boost of hyperactivity that would tire me out right after breakfast while also making sure there’s plenty of energy to wait for lunch without starving.

For my grandparents the midday lunch is something quick and small, but substantial. Substantial enough to be cooked and often eaten warm while sitting down, but should work as something you eat on the go. Sometimes it’s prepared in advance so you can eat it in the field when you’re working, because making the trip back home just for lunch doesn’t make sense time-wise.

As a lazy person with a modern job that doesn’t require me to run around the fields, I take lunch at home while watching television. But it’s always something I can throw together in a few minutes and the whole lunch thing shouldn’t take more than half an hour or so.

The rest of the day depends on the type of work you’re doing. If you’re out plowing the fields and chasing the light, or like taking your afternoons in uninterrupted blocks like I do, then you need another small snack about halfway through the afternoon.

I don’t know what my grandparents do for this, but I like to make a smoothie. It’s a quick pick-me-up for the afternoon that I can make in ten minutes and then drink while working. The carbs in fruit burn fast to give me an energy boost and the fats in milk burn slowly to keep me going for a while.

Smoothies are also a tasty way of ensuring you get your vitamins.

But you can easily switch this afternoon snack with a proper dinner - the third large meal of the day. Dinner should contain all three macro-nutrients and provides a solid base for the rest of the evening. You can think of it as the breakfast of the night.

A lot of people advise that you shouldn’t eat after 6pm and I think that’s bullshit. Sure, don’t eat more than two or three hours before sleep, that does help, but if your bedtime is 2am the 6pm thing is not relevant.

If you take dinner early then I suggest having another light snack halfway through the evening.

In short, my grandparents eat five times a day. Three large meals. Two small meals. Roughly every three hours.

Same as them, I eat five times a day, except I move the 6am breakfast to a midnight snack. The snack ensures I can work until 2am and don’t wake up starving.

Eating every three hours might sound like a lot of work, but becomes easy once you get used to it. You’ll never feel hungry, will always have a steady supply of energy and most importantly you will never go into foraging mode where you start eating bites of random snacks you can find.

Those are unhealthy and will never make you feel full. That’s how you get fat.

Other than a schedule of eating many small meals throughout the day, food is about nutrition. There’s no need to go overboard worrying about this. Eat your fruits, eat your veggies, make sure you get enough fat, protein and carbs and avoid sugar.

Yes, rapping on sugar is modern right now, but for me it’s a simple matter of fast burning vs. slow burning foods. Eating slow burning foods - meat, whole wheats, fat etc. - provides a steady source of energy for a few hours. Eating fast burning foods like processed wheat (white bread, white pasta, …) or sugar will give you an energy spike that leaves you hungry and tired after half an hour.

Sugar and simple carbs in general have been linked to feelings of fatigue and decreased mental performance after a short period of time. I haven’t discovered a study that shows a direct link, but read several that found a correlation.

In short, don’t sweat your diet too much. Once you cut obviously unhealthy things you will find you can eat anything your body tells you to. It takes a month or two for sugar to become a thing of the past and then you won’t even crave it anymore. Most sugary things will just taste too strong to be tasty.

A few years ago I found a cake with 10+ spoons of sugar in the dough to be too bland. Nowadays anything more than a single spoon burns my tongue.

Oh and don’t fall in the trap of various modern pop diets that say you shouldn’t eat grains or whatever other nonsense because our ancestors ate differently and that’s supposedly more healthy for us. It’s not.

We are not our ancestors and anyone who tells you that our digestive system hasn’t changed for the last 100,000 years is an idiot. We evolved at least the ability to digest lactose less than 5,000 years ago. Who knows what else is different.

Enjoy being a modern human, eat well.

[add things about breakfast composition maybe]


Reading the warning labels on a new mouse or keyboard always makes me laugh. “Warning, using this product may cause permanent injury. Consult your physician before prolonged use.”

“Pha, it’s a keyboard! Injury schminjury.”, I’d think before plomping my arse down and typing for twelve hours straight.

But the warnings are right.

If you aren’t careful, computing is a dangerous sport. You weren’t made to sit around all day moving nothing but your fingers. When was the last time you saw a five year old sit around all day staring at a screen? And if you have, please wind their mother’s ears.

As my old gym teacher would say before sending me into a dodgeball game as cannon fodder: “Exercise is the cornerstone of a healthy life.”

Exercise is a funny thing, everyone knows they should do it, but few of us do do it. If you want to be a lazy fuck there’s nothing I can do about that. But everyone who’s sucked it up and started exercising regularly has said it’s made their lives better.

You don’t have to average two to three hours of exercise per day as I do. If you just want to be healthy and have more energy, a few minutes a day is plenty. Anything more than that is a hobby.

I have a friend who is a stereotypical geek. He doesn’t really work out, but has a good enough metabolism that he can eat almost anything without getting fat. His poison during the summer is longboarding to the office and back.

When winter hit he couldn’t do that anymore. His mood started going down and at one point his day was waking up groggy, walking to the office in a daze, working for a few hours, coming home and crashing because he was so tired.

He couldn’t figure out why he was so tired until one day it hit him: No more longboarding. No more taking half an hour instead of ten minutes to get home in a round about way.

One day he bought a room cycle and started cycling for ten or twenty minutes every day. Almost instantly he was back to his old self. His sleep improved, he wasn’t as tired at work and when he got back home there was plenty of energy left to do the things he loves.

That’s all it takes. A few minutes a day.


Laying in bed every night for hours on end might feel like a waste of time, but it’s the most important thing you do as a human being. We don’t know exactly what happens during sleep, but we do know what happens if you don’t get enough.

Sleep deprivation is one of the most effective torture methods used in interrogations because it breaks the human spirit completely. Strangely enough, if you’re a modern office worker there is a near hundred percent chance you are regularly depriving yourself of sleep without even realizing it.

Prolonged sleep deprivation affects your ability to consolidate memories, which makes it appear like you have a bad memory. A foggy recollection of events, yesterday feeling like it was a week or two away, difficulty placing events in the correct sequence, things like that. [sauce]

It appears that the brain does some sort of defrag operation during sleep that ensures all our memories are catalogued and reasonably accessible. This is also why sleep is an important factor in making learning more efficient. [sauce]

A more instant effect of sleep deprivation is every hour of sleep deprivation drops your cognitive ability by about 25%. Essentially, every hour of sleep you missed last night has made you a quarter worse at programming.

No wonder I feel so dumb after a long night. I remember times when I pulled an all nighted working on something and while I wasn’t exactly sleepy the next day I was just not quite there. Following a conversation was difficult, my eyes were barely kept open by energy drinks and work looked more like deranged scrolling up and down a file trying to think of a name for the variable I’d just created.

The coolest effect of sleep deprivation, if you’re into that sort of thing, is that after a while it starts having hallucinogenic effects. You probably don’t want those while coding a mission critical system though.

However, the amount of sleep you should get to avoid sleep deprivation depends on how much sleep you need naturally. Your mother has probably told you that you should get at least eight hours of sleep every night, but research has shown that 7.5 is the optimal average for adults. [sauce]

Through experiments I’ve found my own sweet spot at six hours give or take 30 minutes. It depends on how tired I am and how much mental effort I’d gone through, but five hours leaves me a bit foggy and anything much more than seven makes me either too hyperactive to work or wasted all day.

Experiment to find your own sweet spot.

You might be surprised by how little sleep you actually need once it’s effective. As natural as sleep is, a lot of people are just plain terrible at it. Either they lay in bed waiting to fall asleep for far too long or wake up tired and groggy.

For refreshing sleep you are optimizing your sleep for the REM - rapid eye movement - stage of sleep. Occuring roughly every 90 minutes this is the dreaming sleep stage. During REM your brain is as active as while you are awake, but your body is completely paralysed to prevent acting out your dreams.

REM is usually followed by a period of very light sleep that is the perfect opportunity for waking up fresh as a flower. Missing this window of opportunity will leave you feeling worse than if you hadn’t slept at all.

A simple way to make sure you’re waking up at the right moment is making sure the amount of sleep you get is an increment of 90 minutes. Experiment a bit to find the exact timing for yourself as the cycle length can vary between individuals and usually shortens towards the end of the night - we dream more and more often towards the morning.

Another great tool are sleep apps for your phone. They monitor your sleep with the phone’s accelerometers (yes, you have to sleep with your phone) and sound the alarm at the best moment in a thirty minute time window. My favorite is SleepTime by Azumio because it shows fancy graphs of my sleep and plays white noise that helps me relax before sleep.

The best way of describing the difference between a normal alarm and one synced to your sleep cycle is that a normal alarm wakes you up and a modern alarm reminds you to wake up.

After fixing your wakeup, it’s also important to fix the timing.

Sleep is only effective when it’s synced properly to your natural circadian rhythm. This is why sleeping all day never seems to quite cut it and why jet lag feels so terrible. Ideally you should be asleep 6 hours before your body temperature reaches its lowest levels.

This one might be difficult to figure out, but I personally seem to be freezing at around 8am no matter the situation. Therefore I should be going to bed at around 2am, which is exactly what my normal routine looks like.

When all those factors line up something magnificent happens: you’re always rested, you never feel sleepy during the day, and you fall asleep almost as soon as your head touches the pillow. No matter how much stuff might be rushing through your head.


In high school most of my friends worried about getting the girls and finding the best parties, but I worried about being the next Turing or Carmack. My already limited coding time felt wasted on sleep so I started looking for a cure.

The first cure I found for late night drowsiness was green tea with plenty of sugar. Caffeine.

Caffeine is probably the safest and most effective stimulant you can easily get your hands on. Pretty much everything that says it’s got stimulative effects and you can find in a normal store contains caffeine. Coffee, tea, chocolate, energy drinks, cold medicine. Everything.

Reading research on caffeine really makes it sound like a wonder drug and I will never understand why some people avoid it so much.

Several long-term observational studies have shown that chronic consumption of caffeine (three or more cups of coffee per day) significantly decreases your chance of death from any factor. If you consume caffeine you are simply less likely to die. Period.

The biggest effect however was on cardiovascular disease and mental deterioration linked to aging. Drinking large amounts of caffeine - more than 300mg - every day will significantly lower your chances of dementia and Parkinson’s disease, while any dose whatsoever will help against some cardiovascular disease

Better still, it seems that long-term habitual use of caffeine is either inversely proportional to chances of certain diseases, or has no effect whatsoever. It doesn’t cause high blood pressure, doesn’t affect diabetes etc.

But you do get used to caffeine. The more you drink the more you’re going to have to drink. While some studies report the effect of caffeine increases with habitual use, a lot of people suggest for most of us caffeine does nothing but restore normality because we are so used to it.

One thing to keep in mind is that caffeine as a mental stimulant only works when you are sleep deprived. A well rested individual might well not drink any.

This is because caffeine is an adenosine inhibitor. Adenosine is a chemical that inhibits the activity in our central nervous system whose concentrations correlate to how long we’ve been awake - makes you sleepy after you’ve been up for long enough.

Caffeine binds to adenosine receptors giving adenosine nowhere to go, which makes you feel more awake. This has its limits but works well enough for caffeine to increase your cognitive capacities on all measures. You’re better able to concentrate, make good decisions, your short-term memory improves, solving difficult problems is easier, you think faster and so on. Even your mood improves!

Inhibiting adenosine is not the only thing caffeine does to your brain. Part of its effect goes to increasing blood flow to your brain and increasing your metabolism. This means the brain has more oxygen and more energy to work with.

All of that happens if you are sleep deprived. If you just woke up caffeine will do next to nothing. It might elevate your mood a bit because you’re used to it and it will increase blood flow to your brain to some extent, but mostly you’re just fooling yourself that morning coffee is doing anything.

And placebo has been shown to work less well than caffeine. Sorry.

But caffeine is great as a physical stimulant as well. In all parts of the day. I haven’t found an article explaining why or how, but caffeine increases your muscular coordination, improves your endurance, your reflexes and just generally improves all parts of your physical performance.

No wonder working out after a can of red bull feels so great.

Just remember drinking caffeine and going right into a boxing match does not work well. You have to give it 20 to 30 minutes before caffeine starts working its magic. I learned that the hard way …

On that note, make sure you replenish your caffeine supply after a while. Most of the effects last for about four hours then start tapering off. The more tired you are, the harder the crash is going to be so be prepared. If you want to keep riding the caffeine high drink a new dose every three to four hours.

Luckily you don’t have to worry about overdosing on caffeine. If you’re a healthy adult, you can safely take up to 1000mg per day for the rest of your life. That’s equivalent to 13 shots of espresso or six cans of Monster.

Please don’t drink six cans of Monster per day, there’s probably a good reason the can says you shouldn’t have more than one.

Caffeine is therefore a perfect drug. You can use as much as you want all of your life and you will be an all round better human. If you’re okay dealing with severe dependence and withdrawal symptoms when you don’t get your fix.

Your choice.

Other stimulants

Caffeine is by far not the only stimulant people use. Just the most common.

Ginseng is another phytonutrient I apparently drink a lot of with my energy drinks. It is said to have stimulative properties and make your brain work better, but a study I found comparing the effects of common stimulants concluded it does exactly bupkis.

Doesn’t increase your cognitive or physical performance any more than a placebo would. But I doubt that will stop energy drink manufacturers from using it. Maybe it has an effect when combined with the other things? I don’t know.

Ephedrine is another popular option. I haven’t used it, but according to the same article rapping on ginseng, ephedrine is even more effective than caffeine in some cognitive tests. [which?]

Unlike caffeine ephedrine is a melatonin inhibitor. Your body produces melatonin depending on how much light hits your retinae, which makes you sleepy in the evening. This is why it’s easier to stay awake when you leave the lights on and look at bright computer screens all evening.

Interestingly, ephedrine produces a bigger effect in many tests than caffeine does and because it acts primarily on melatonin you can combine the two for a greater effect than either ephedrine or caffeine on their own.

I have yet to experiment with ephedrine, but am going to as soon as I figure out where I can get some.

The only stimulant other than caffeine that I’ve tried was methylone and I don’t recommend that as a performance enhancer. It is structurally similar to MDMA so it’s more of a party drug anyway.

When I tried methylone I specifically wanted to test how well it worked for improving cognitive performance. At first it seemed to work very well - I improved my time my record in a Colin McRae game by almost a minute on a 4 minute track. It felt like I could see into the future and was so at one with the car and keyboard that my reflexes were far too fast to follow with my conscious mind.

But the stimulating effect became too much after about twenty minutes and I could no longer focus enough to follow the game. My muscle response became too rigid as well and I lacked the fine motor control required to type with any finese.

Not a very productive stimulant therefore, but I did talk like the wind all night, unable to stop, my mind kept racing and I couldn’t sit still until about 8am when I was physically exhausted but had a hard time falling asleep.

The hangover was very physical. Like I had been doing hard physical labor all day.

I suspect a lot if not all street stimulants will have a similar effect of making you too hyperactive to be of any use behind a computer. Maybe you can circumvent that with very precise dosing, but I wouldn’t bet on it.

However there is great potential in pharmaceuticals.

I’ve heard adderall is a popular option in the United States. The diagnosis of attention deficit disorder is so popular there, you can get adderall as easily as marijuana on most campuses. That’s what I’ve heard anyway.

The effects on healthy individuals seem to be very beneficial. It doesn’t really speed you up like caffeine would, but makes it very easy to focus.

Another viable option for long nights is modafinil. Prescribed for narcolepsy its mode of action remains unclear, but it removes your need for sleep. You just will not feel tired, there is apparently no hangover, and from what I could find there are no side-effects if you are otherwise healthy.

You might develop normal sleep deprivation side-effects like poor long-term memory and eventually hallucinations if you stay awake for too long.

Plan to get some sleep every night!

I haven’t tried most of this stuff, just read about it. I’m not condoning the use of these chemicals, but they are out there and some people are using them.

Dealing with distractions