Effective Time Management

One of our core commitments is productivity. It's easy to look busy. It's hard to truly be productive. Being productive is not necessarily about working harder. It's a combination of making sure you are doing the right thing and having laser-like focus to minimize wasted effort.

A big part of my desire to be productive is that there is so much more to life than work. I love what I do, but I still want to spend time with family, working out, climbing, biking, playing the guitar, etc. By being as productive as I can during the time I have set aside for work, I can do all those other things and not have to worry about work, because I know the most important things are getting done.

Makers versus Managers Schedule

The way we schedule our time can have a huge impact on our productivity. I was reminded of this recently while listening to Security Now. The host Steve pointed out an article by Paul Graham: Makers versus Manager Schedule. I say that I was reminded of this idea because I've had this discussion with Fab in the past.

The article (which you should go read. I'm not going to be able to do it justice here) points out that there are 2 types of schedules. Managers are constantly in meetings and schedule things on the hour and that works for them. However, creatives (and coders are creatives) operate differently. They like big chunks of time, as in half or even full day chunks.

Managers and Creatives can both work well on their own schedules. That's great. The problem comes when they collide. Meetings in the middle of the day that interrupt creatives while they are in their flow state can easily waste half a day or more. Even a short interruption like a phone call can easily waste 30 minutes or more of context-switching time for a creative. In this dynamic, the cost is very high for the creative and low for the manager. Add to that the power dynamic wherein the manager has all the power and it often doesn't work out well for the creatives.

One Possible Solution

Obviously, the first step is to recognize there is a problem. From the manager's point of view, they can try to avoid scheduling meetings in the middle of the day.  Scheduling meetings at the beginning or end of the day allows creatives to treat the rest of the day as a big chunk. That certainly helps.

The conversation I was having with Fabiola was that how as creatives we need to take charge of our own schedule. We need to make sure we have large chunks of time blocked off. Obviously, if you are an employee that can be hard to do, but since she and I are both consultants, we have a little more leverage over our schedules.

Based on my own experience and my conversation with Fab, I have been using this strategy for quite a while. Mondays and Wednesdays are my meeting days, where I work the manager's schedule. I set aside time for client meetings on those days. Tuesdays and Thursdays are my creative days. I try not to schedule any meetings on those days. When I do I schedule them early or late or occasionally over lunch. I try to keep Fridays clear as a day I can take off to do something fun. Sometimes I do something fun, sometimes I work, but I always try to give myself that choice. That schedule seems to work well for me.

There Are Other Ways

Time blocking certainly works and I still continue to use that technique. Over the years I've discovered there are some other solutions.

Test Driven Development (TDD)

During a discussion about the benefits of TDD with Fab, I had a realization. One of the problems with working on the creative's schedule is that interruptions are costly. Context switching can be painful. It can take quite a while to remember where you were. When writing code using TDD that problem seems to go away or at least be more manageable.

In TDD you write the test first. Think of it as an example of what you want the final piece of code to do. Then you start to write the actual production code. If you get interrupted, when you come back, the example is still sitting right there in the test. It acts as a little reminder of exactly where you were. It's easy to find because that test should be the only failing test. So you sit back down and run the tests and see the one that fails and that is your reminder of exactly where you left off. I've noticed that since I have started using TDD that context switching after interruptions has become less of a problem.

Many More Much Smaller Steps - GeePaw Hill

Another revelation came when I first heard GeePaw Hill talk about his Many More Much Smaller Steps. He has a Pawcast where he lays out all the benefits, but the one that stuck with me was that he no longer needed to use block scheduling. He points out that block scheduling is generally a sign that you are taking too large of steps. He's right. As I started taking smaller and smaller steps, I noticed that I could actually make meaningful progress in much smaller blocks of time. I still need occasional blocks of time for really deep thinking, but now if I have an hour between meetings, I can totally knock something out.

Mikado Method - Nicolas Carlo Book

The last major technique I've adopted is the Mikado Method. I learned about it from Nicolas Carlo's Legacy Code First Aid Kit. It's a formal method for breaking a task down into smaller tasks. Buy Nicolas' book to learn more. The basic idea is you write down a task and work on it for 10 minutes. At the end of 10 minutes, if you aren't done, you revert the code and you write down the sub-tasks that need finished first. Then you pick one of those and repeat. It's a way of breaking your work into smaller steps, so you get the benefits of Many More Much Smaller Steps, and like TDD it gives a nice reminder of where you were if you get interrupted.

Recap

As coders we are creatives and we have this tendency to want to work in large chunks of time. We also have to deal with this problem of context switching when we get interrupted. The classic solution is block scheduling. That certainly works, but there are other ways to deal with the problem. Particularly if your work environment doesn't allow you to do block scheduling, you should certainly try to take Many More Much Smaller Steps and try out techniques like TDD and the Mikado method. By using these methods I have found that I don't need as many big blocks of time as I used to.