Monday, October 22, 2012

Maker's Schedule vs Manager's Schedule

A while back, I wrote a post in response to one of Paul Graham's essays regarding how it's important/necessary for programmers (or in fact, anyone doing some form of creative activity) to hold a mental picture of all of the relevant parts of a project at hand (i.e. all of it in many cases) to do a good job very productively. As I've been slowly plowing through the writings of many other productive people, similar trends emerge time and time again: being able to hold a mental picture of an entire project when working on it appears to be a contributing factor to how we can achieve "flow" (i.e. that magical state where you're able to absolutely massacre your todo-lists, steamrolling through item after item with barely any effort, while growing manically happy at getting things done in this way).



We can regard this as being like the low-level mechanism for understanding how we can be productive when doing such work. However, there is a caveat to being able to do this: getting all that stuff into your mind, unpacking it, and preparing it into a form that can propel you through a work session takes time... a lot of time. A good estimate is about 1 hour. Which means, time slots less than that are useless for any productive work. In fact, even time slots only marginally longer by 1 hour before another upcoming commitment are also pretty useless, and can only really be used for "filler" activities which require zero-processing power (i.e. manual labour type chores). Furthermore, if 'significant' travel (aka more than a quick walk around the building/campus, such as even a short drive/long walk) is required to attend to the "distraction", we can further reduce the amount of productive time left that day, as now that has just scrambled your mental state even more. Depending on when that distraction occurs, this combination of factors can be sufficient to effectively wipe out all all productive time for anywhere from half a day to the entire day (the evening following may still be available if the pattern isn't repeated the very next day).

It turns out that Paul Graham has a followup essay discussing this very thing. He even gives it a name: "maker's schedule". If the first part was about the low-level mechanism/how, this gives us the "why" on a meta-level.

As Paul says in his essay:
One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I'll call the manager's schedule and the maker's schedule. The manager's schedule is for bosses. It's embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you're doing every hour.

When you use time that way, it's merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you're done.

Most powerful people are on the manager's schedule. It's the schedule of command. But there's another way of using time that's common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.

When you're operating on the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That's no problem for someone on the manager's schedule. There's always something coming on the next hour; the only question is what. But when someone on the maker's schedule has a meeting, they have to think about it.

For someone on the maker's schedule, having a meeting is like throwing an exception. It doesn't merely cause you to switch from one task to another; it changes the mode in which you work.
(directly quoted as I don't think I can put it much clearer)

Now it all finally makes sense, and is quite consistent with my own experiences recently of stressful a disruptive "MBA-designed" timetable (with one "event" a day, starting right in the middle of lunchtime) combined with looming deadlines can be, especially when compared to the relative sanity of having a few weeks to just focus on a single project (yay! dedicated research time!) or even slightly physically draining but still very productive "all-meetings-on-one-day-from-9" routine (yay! several uninterrupted days of work... works best on Wednesday, as it gives you a bit of a mid-week routine kicker/break). 

No comments:

Post a Comment