It seems to be a number of uncanny order in life, nature, project development… Perhaps my 3-step process in tackling tasks is an obvious idea, but you never know who may need to (re-)discover it. Admittedly, my time management skills are not the best — which is a particular source of self-imposed frustration when living the freelance life. So just trying to intentionally approach my work this way has had a tremendous positive impact on my ability to get things done.
When it comes to your work, no matter whether it’s websites, writings or widgets, doing your best at it means you need to pay attention to three rules or stages of a development cycle. Since it is what I know (and what I do) I’ll describe it from the website design and development point of view. Whatever your task though, it can (and probably should) be broken down into these three steps:
What’s really amazing is that this concept scales from the largest project to the smallest of tasks. For example, when approaching any task, you should generally be spending a third of your time planning it, a third of your time doing the work and a third of your time reviewing what you’ve done. In general, your work day, with it’s barrage of to-dos, could easily be broken into smaller segments of planning, producing and reviewing. Done properly, of course, you’d find you’re spending roughly a third of your day in planning tasks, working on them and going over your work.
In website development, you generally start in a discovery or strategy period where you plan out what you’re going to be doing. You assemble all the resources you have at your disposal and lay out a game plan of how you’re going to accomplish your goal(s). This is really where the most critical thinking happens. Lately, my critical thinking has been at it’s peak when I’m not sitting at my desk or staring at my computer screen. I get more planning done more quickly while pacing around my office, throwing a frisbee with my dog or taking a quick coffee break. Whatever allows you to do it, make intentional effort to plan your work ahead of time.
The nitty-gritty does have to happen. Once you’ve planned your task enough that you’ve answered most or all (if you’re lucky) of the ambiguity you’re ready to start production. The work progresses much faster when you’ve identified and planned how to handle the unknowns. As a result, what might have taken 4-5 hours to stumble through in a work day could be cut back to around an hour and twenty minutes.
For a lot of “good” developers, this may seem too obvious and in some cases is done in an automatic way anyways — checking your code piece-by-piece, for example. At some point though, there needs to be some sort of separate overall review for your work. In building a website for example, you might check your mark-up in a single browser, but you’re still going to have to look at all of it across multiple browsers and platforms to be sure it’s ready for prime-time. Or in writing some body copy… You might be rewording as you type, but to really be sure you’re going to sound good it really takes a careful re-reading of the entire work to catch the little things – bad grammar, wordiness, spelling mistakes and so forth. A quick aside here, my father always taught me to read my writing backwards, word-for-word to catch those hard to see spelling mistakes. It makes you focus more on the detail of the words instead of thinking about the concepts of the sentences. Anyways, going back over what you’ve done may be time consuming but it’s elementary to getting the job done (and by getting the job done, I’m implying getting it done “right”).
I think for most of us we just can’t get over how much time it’s actually going to take working in the planning, and reviews into our work schedule. Some tasks seem too menial to employ so much overhead. For that, you have to take at least enough time to determine how important getting a quality job done is compared to how “much” (quantity) you need to get done.
You might even find that planning before you produce will help you sail through the production work and probably discover less mistakes in the review that you have to go back to fix. In the end you spend less time overall by planning, doing the work and reviewing than if you just brute force “git ‘er done”. How many times do you rush into working on something only to come to a stumbling block that you didn’t anticipate?
If nothing else, I find that following this approach helps my productivity stay consistent both in what I can get done in a set amount of time and the quality with which I turn it out. At that it’s not a hard rule I live by, but when I get the feeling I’m starting to lose my focus, this process is always the right tool to get me back on track. Hopefully it can help someone else too.