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.