In the last lesson we covered steps 1 and 2, the gathering of input and converting them to tasks. Next we want to organise those tasks into a sensible sequence and see the bigger picture. Onto that next.
Step 3: Organising Your Input
So now everything is defined and entered as tasks in your trusted system. Yay, etc. In less than 10 mins. Remember how I spoke earlier about batching flows? Now we can focus entirely on arranging the items within your system. We want to avoid the context switching mentioned in the first lesson wherever we can.
Of course, I want to get to the important business of designing software and writing code. But one big part of making the transition from junior to senior dev is learning how to plan your workload and prioritise your time. Our productivity system lets us do that, but without keeping all the planning in your head.
Looking at Your Landscape
Again being an audio course this is hard to describe, but with OmniFocus in front of me, I can tell you that I have around 100 projects there. Since everything that takes more than one step to complete is a project, that’s a lot of commitments. But I don’t feel overwhelmed at all. This is for 3 reasons:
- I can use folders to group projects, collapsing them when needed.
- I can use perspectives to filter projects, so I can view my use case. I might want to look at the next 2 week sprint, or by projects that improve me in the long run.
- Most importantly though, everything is in one place, so I know I can search for what I need in that one place.
What I want to do right now, is view my 2 week projects. I want to see how the new items I identified in my emails relate to what I have at the moment. My 2 week perspective has 8 projects at the moment:
- A project for the pickups uplifts into docker.
- A project for the labels uplifts into docker.
- A project for production release of assets.
- A project specifically designated for keeping up with updates from a team I’m only involved with sporadically.
- A project that acts as a miscellaneous list of things I need to do during the next 2 weeks.
- There are a handful of projects that have spilled over from the last sprint too...The lot of a developer unfortunately.
You might remember there was appraisal info from my boss, ticket offers from an engineering lead etc in the emails mentioned earlier. These are in Omnifocus but not in this 2 week perspective. I want to stay focused on the 2 week deadlines I have.
Planning Your Projects
I take a look at my label uplift project, and at the bottom of course is a task saying ‘discuss port mappings for debugging with Josh’. This is fairly important, so I reorder this task to near the top. There are a couple of tasks that logically belong before it, so Josh doesn’t get to the top of my pile here. Also, I have completed some tasks that I previously identified, so I can cross those off. Some tasks have become irrelevant, so I can delete those. At this point the label project is back in sync with my understanding of the world, so I feel liberated (slightly). Next I move to the pickups project.
Looking at this project, there’s a task called ‘discuss layer 7 changes with Nick’. This isn’t vital, but he’s going to need to keep moving, so again I move it near the top. I can see a couple of my tasks on my list have a due date of the next 2 days, so I’m going to look after myself first... Sorry Nick! I’m shifting those to the top, and then you’re next, I promise! The rest of the list doesn't need much sorting. I just rearranged a couple of things that have a logical sequence.
BTW, it’s not even 10:20 yet. I started reading my email at 10:03.
I look at the project called ‘Production Releases’ next. Simon's email is there near the bottom with a tag of ‘waiting’. If he doesn’t reply in the next few hours I might have to chase him up, but he’s normally pretty good. So I’ll move near the top but the tag of ‘Waiting’ will remind me there’s nothing for me to do yet. I’ll assign a due time of 13:30 so I can chase him if he doesn't reply by the afternoon.
All the other tasks are just as before, mark certain tasks as completed and delete anything that we’ve changed direction on. If the tasks remain the same but the priorities have changed for some reason, just reorder.
I follow the same pattern for my other projects. I’m done by 10:21. Time for a coffee, and whatever tasks I feel I can fit in before 10:55. I like to unwind for 5 before a meeting and mentally prepare you to see.
Reviewing Your Commitments
So, how often do I need to maintain these lists? I’ll quote David Allen again: ”As often as you need to feel current”. That’s not as vague as it sounds. As you go through your day, you’ll know when you are getting out of sync.
Taking an example from writing code – let’s say I hard code some data so I can keep moving. I don’t want to forget to fix this later. It’s quick for me to use OmniFocus to capture that I need to fix this, and get back to the job at hand. When I complete the job at hand I have 2 choices. If the next step is obvious or natural I’ll move to that. I want to keep flowing.
If there is any doubt, I simply scan my project list in OmniFocus. Maybe now is the time to fix that hard-coding. Maybe some tasks have changed priority since I last checked. Maybe I completed 3 tasks in one go with my inspired solution today. The point is, I choose when I review and when I code, there doesn't need to be any formality about it. I know where to go when I want to check what’s left and maintaining it is straightforward.
Conclusion
Whilst that whole process sounds complicated, it can quickly become second nature. But what I’ve described in 10 mins is your entire flow for keeping on top of your project planning. By batching up collection and organisation of tasks, you can code away in comfort.
Whenever you need to ‘check your bearings’ and re-orientate yourself, you can just go back to your project lists. And you know if it’s on your list, you haven't missed something important.
That’s pretty much it for GTD – you’ve got a system for planning your work and it’s separate from doing your work. We don’t code in GTD, after all. Next we’ll move onto how to build good supporting materials to improve your project implementations. We’ll discuss why Mind Maps are the developers ‘secret sauce’.
