Working around interruptions

I wasn't sure whether to write this entry in my work blog or my personal one, and in the end decided it fits here. I saw a link on John Gruber's Daring Fireball to Maker's Schedule, Manager's Schedule by Paul Graham, a programmer and programming language designer. He's part of Y Combinator, an investment group which specializes in the early stages of startup companies doing software and web services. His theory is people operate on two kinds of schedules: manager's schedules are broken into hour-long segments, while maker's (programmer's) schedules need half- or full-day chunks.

The different kinds of schedules is an interesting concept. In general, since a manager's day is built around chunks of an hour (or multiple hours), scheduling is a matter of finding a slot and booking it. A manager always has something coming up, and the day is built around shifting gears.

Makers like to have large chunks of time to work on projects, and breaking those chunks up with meetings means the programmer has to get back into the right mental frame at the beginning of each chunk (the common term for changing between different tasks is context switching). If the meeting is in the afternoon, the programmer is less likely to start something ambitious in the morning, knowing there's an interruption coming up.

The last piece of his theory is that the people in control run on the manager's schedule, so those on the maker's schedule need to adapt. However, good managers realize this and try to make sure programmers have large chunks of time for getting things done. I've been fortunate and have had several managers like this.

Graham explains that  in the '90s he used to program from after dinner until about 3am, then sleep until 11am. This had the effect of giving him a chunk of uninterrupted time to work, and then the normal afternoon would be reserved to do other things in the office. He likens it to having a chunk being on a maker's schedule, and another being on a manager's schedule. I've found it's a rather common schedule for programmers, since once you get going it's prefereable to continue without stopping.

Come to think of it, teenagers have a similar schedule, and they stay up for similar reasons - it seems hard for them to stop what's occupying them at the time (watching TV, talking on the phone, etc.) to get to sleep.

Sysadmin's schedule

One schedule Graham doesn't address is what I'll call a sysadmin's schedule (only because that's how I know it; help desk people would probably be similar). It's one where you try to migrate towards a maker's schedule but because of the nature of needing to fix problems and answer questions, you do a lot of context switching and end up on the manager's schedule on steroids - your chunks vary in duration and can often be closer to 10 minutes than an hour. In addition, many times you know neither what's coming up, nor when things will happen (as opposed to having your day's schedule on your calendar).

If that sounds like an inefficient schedule, it is. It's hard to get large projects done unless you can convince others to pick up the problems and questions that come in. Programming done by sysadmins not only has a "how long it will take" component, but a "when it will be done" one which is often much longer (something that would take half a day might be alloted a week to finish). Since resolving problems normally has a relatively high priority, the programming gets perpetually pushed aside. It's not unusual to finally get one's head back into the project only to be interrupted again; if there are few interruptions, things get done early, but they slip if there are many interruptions.

How do sysadmins get anything done? Unsurprisingly, it's a different answer for different people. I know sysadmins who will drop everything when an emergency comes in and concentrate only on that. They're great people to have in such cases, but the danger is long-term projects don't get as much attention and it's easy to drop small details when finishing things up.

Other sysadmins concentrate on triaging things and do quick fixes right away. Longer fixes will get delayed until they can get to a good breaking point on what they're otherwise doing (which could be minutes, could be longer). Quick response can suffer for this kind of sysadmin, but the deliberate context switching can make it easier to get back into the right frame of mind, since it's easier to know where one has left off.

There are other types of sysadmins, but these seem to be the most common, and good organizations will have some representing each extreme.

Many sysadmins also do micro-context switching all the time - when working on one project, they'll still have another somewhere on their screen. When they glance over, they'll think about that other project for a few seconds. Flashes of brilliance can come during those times, but often it's just another distraction.

Again, this seems to reflect teen behavior, having lots of things all around (portable music player, computer, phone, etc.) and splitting one's attention among them all. I'm not saying that my sons are like that (and I'm not saying they're not like that), but I do remember when I felt capable of doing multiple things at once. I then got to a point (and it's not a matter of getting old, it's more a matter of…becoming more aware of such things - yes, that's it) that I noticed it was harder to remember where I was when going back to something. Or, I'd be listening to music while programming, and later look at the playlist only to not remember hearing a series of songs which had played a while ago.

I adjust by trying to do things in larger chunks, and I'm less shy about turning down larger projects I don't feel I'm well-equipped to finish in a timely manner. I also try to plan things more in advance, at least as much as one can plan around problems reported by customers. I'm sure I'll do more adjusting as I (ahem) become more aware of how I switch between projects.