Choosing Priorities

During the summer I started a difficult but important journey to reorganize my life. The first step was organizing my daily tasks. I was successful, butbecoming productive again hascreated new issues.

When you change from trying to do everything to doing what’s most important, you need to decide what important means. Figuring this out for myself has proven difficult. I still don’t have all the answers, but I am constantly making progress.

Deciding what isn’t important has been easier. I am abandoning Themis, my attempt at an open source project. I no longer have a need for it, and it will take a lot more effort to get it finished than I originally expected. I would be delighted if someone wanted to take it on, but there isn’t enough there for it to be likely.

Writing in this blog has also been pushed down the priority list. I intend to keep going, but instead of forcing out a steady pace of content, I’ll wait until I haveideas that I have a strong desire to share.

Managing Priorities Outside of Work

I’ve been fortunate to take some serious down time during the summer. After working pretty much non-stop for ten years, things have piled up. I took some time to rest, then got to work on some personal projects that have been neglected far too long.

What I’ve learned, however, is that it takes more than time to get things done. After about a month, pretty much all I’d achieved was completing a couple video games, and putting all the things I wanted to do into one very long list.

My first thought was that I wasn’t focusing, so after listening to a podcast by Scott Hanselman about organization, I decided to try the Pomodoro Technique. This is a fairly simple system where you try to focus completely on a task for 25 minutes at a time, shutting out all distractions.

After a bit of Internet searching with no results, I started making my own pomodoro timer application. I had something working in a couple hours, barely holding myself back from adding sounds and animations. It would have been a lot faster, but I wasn’t completely focused on the task.

Armed with my timer, ready to experience my first burst of productivity, my wife came home from work. I told her excitedly how I’d built this magical thing, and how I’m going to start getting so much done. Then she asks me one simple question, “Why didn’t you use the timer from the kitchen?” This is when I realized that my problem was focus on a whole other level. I was doing work, but I wasn’t doing the right work.

This is a common problem in the software world: getting overwhelmed by a giant list of tasks, doing a little bit of everything, and completing nothing. I’ve experienced this first hand, and have been using effective tools for dealing with it for years, but I had never considered applying them to my personal life.

I tried a few things next, but the best help came from the book Getting Results the Agile Way, which was also mentioned in the podcast. It combines agile philosophy with some ideas about balancing life priorities and energy levels. I’m not committed to the entire process, but the parts I am trying have already made a big difference. By focusing on three goals a day, I’m now managing to plow through even dauntingly large tasks. Though I’m not doing everything on my list, I’m getting the most important things done, and because I feel that I’m making progress again it’s motivating me to work harder.

Taking the time off has been really good for me. Beyond organizing my personal priorities, I’ve also been organizing my main workspaces: my office, and my kitchen. You could say the experience is like rebooting a computer; it took a bit of time, but now I feel fresh and full of life, ready to tackle something new.

The Critical Path

For the last ten years, if you had asked, I would have told you with some conviction that a “critical path” is a kind of test script that tests the essential functionality of a system. If the app passes it’s critical path test, I would have said, it may not delight users, but it’s unlikely that they’ll storm your basement with torches and pitchforks.

It came up at work during a discussion about interview questions. My colleague was both proud and surprised to have been the only person interviewed for his position that had known what it really means.

A critical path is a project management term that refers to the chain of dependant tasks that will take the longest amount of time in a project plan. For example, if I were to make a project plan for my breakfast on Sunday morning, it would look like this:

The plan for my sunday morning breakfast.

In this plan, making pancakes is the critical path. With an unlimited amount of people, and an unlimited amount of kitchen space, and all the resources and tools we would need, the fastest that we could produce my Sunday morning breakfast is the time it takes to make pancakes.

I can steam milk, flip pancakes, and toss a couple eggs in the pan all at the same time, but grinding coffee beans and mixing the pancake batter has to be done one at a time. This breakfast takes me just a few minutes longer than the critical path, so it’s not worth hiring a sous chef.

The time of a software projects is usually shaped more by the number of developers. We usually have a lot of features to deliver, and most of them are not directly dependant on each other. What you can see is a part at the beginning and end of a project where it’s hard to keep multiple people working, but that’s a whole other thing.

A generic project plan showing a chain of blocking tasks at the beginning and end of a project.

When a critical path is defining the time line for your project, it’s important to identify it; any step that gets delayed affects the entire chain. You should start these tasks as soon as possible, and do what you can to stop them from getting blocked.