Launch the Editor

By Deane Barker on July 20, 2004

Joel on Software – Fire And Motion: I just found this two-and-a-half year old essay by Joel Spolsky, and I’m frankly aghast at how aptly it describes how I code.

For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There’s something incredible heavy in my brain that is extremely hard to get up to speed, but once it’s rolling at full speed, it takes no effort to keep it going.

It’s true — there’s a stunning amount of inertia in programming. Coding is often such a thought-intensive operation, that it takes a while to get into a groove.

It’s not like cleaning the house, where you can just start picking stuff up and seeing an improvement right away. With coding there’s a ramp-up time after you “launch the editor,” as Spolsky puts it. You have to look through your code, figure out where you where at, ask yourself “why don’t I just do it this way” then get 15 minutes into that before you realize that’s what you were doing when you quit the last time and there’s a very good reason why it won’t work, etc.

It can be discouraging sometimes, especially when you don’t get prolonged coding time. If you get interrupted, you lose at least three times the actual length of the interuption, because there’s an inertia period on either side that you have to deal with.

DevX had a great article last year that was so true. They talked about how programmers get into a “flow”:

Flow takes time to achieve, and it is fragile. If a programmer’s flow is interrupted it can take a large amount of time for her to regain the state, sometimes up to an hour. That’s an hour of lost productivity to your team. If a programmer is interrupted many times during the day she may never reach this state. Without this state, creativity is crippled.

Interuptions are the bane of programmer. Spolsky said this about his new offices:

I probably pay more attention to my physical surroundings than the average software developer. I might take it too seriously. But there are three reasons I take it so seriously: (1) There’s a lot of evidence that the right kind of office space can improve programmer productivity, especially private offices….

(How did Spolsky become so concerned about this people? He swears by this book.)

Anyway, back to Spolsky’s original essay — he concludes with this:

[…] you have to move forward every day. Sooner or later you will win. All I managed to do yesterday is improve the color scheme in FogBUGZ just a little bit. That’s OK. It’s getting better all the time. Every day our software is better and better and we have more and more customers and that’s all that matters. Until we’re a company the size of Oracle, we don’t have to think about grand strategies. We just have to come in every morning and somehow, launch the editor.

Yep — set modest daily goals, if that’s what you have to do. Five small goals achieved on five separate days add up to one moderate goal at the end of the week.

I’m working on an uber-system right now, but amid everything else I have to do in the average day, I can spare maybe one hour. So I write down one small thing that I want to implement by the end of the day. One small thing, each day, equals progress at the end of the week.



  1. This is exactly how I program too (it probably applies to most programmers and, indeed, other creative types). Try explaining your lack of productivity or missed deadline to the PHBs ( though!

    The scary thing is just how long I can stay out of the “zone”. I used to think of this as a failing on my part, that I am lazy, or unmotivated, or easily distracted. But I know that that’s not the case. As Joel says, just “launch the editor”.

  2. Its Funny. One of my distractions the keeps me out of the ‘Zone’, is Gadgetopia. Damn you!! It’s worth it though.

    I wonder if you could sue a ‘source’ of distraction for X amount of creative hours lost?

    On a different matter (I swear), can you give me the details of your lawyers?


  3. I work on a project where the teams are organized into 12-person high-performance pods. These pods are square and broken into 4 quadrants. There are 3 people in each quadrant and each faces into a corner of the quadrant with the 4th quandrant open and leading to the middle of each main square. The people are organized by job function, hierarchically clockwise around the square. The analysts are first on the left when you walk in. Then the developers, lead developers, architects and team leads. So, in theory, work flows around the pod in order.

    All this is good in theory. However, reality is quite a bit different. All the cubes are half-cubes. And the pod walls are all half-size. And there are 6 of these pods in this one giant area. So, not only do you have the distractions on your own team when someone is on the phone or in a conversation with someone else, you get to pick up on all the conversations on all the other teams in the area.

    In some ways the open communication is nice (you can jump in conversations that you overheard to correct someone and there are numerous times we’ve found out about issues just by listening in on other teams). However, as a developer, it is almost impossible to get in the zone to do work. Nothing but constant interuptions all day long. Headphones help to some degree but not much.

Comments are closed. If you have something you really want to say, tweet @gadgetopia.