With 2016 wrapping up, I have my traditional end-of-year review planned for next week. In that post, I’ll go over all of the articles from this year. This week, I’m reviewing a more specific topic.
If you have been following along for the last couple of years, you know that I write a lot about competitive programming, but that I also explore topics related to productivity and learning techniques.
Mastering a subject requires learning some domain-specific topics. For competitive programming, these topics include language advice and editorials on specific programming puzzles. But that knowledge isn’t very useful if you just read about it. You also need a plan to use it.
When you’re learning a technical subject like an algorithm, you can’t just read about it once and remember it. You have to try it out, often many times. If you don’t keep using it, it’s easy to forget it, which often means you have to re-learn it later. Similarly, learning about a productivity or learning technique doesn’t help much unless you try it out repeatedly in real working or learning situations. And if you stop using it, it may take some time to get back into it later.
With that in mind, I have collected a set of reminders that I find useful when working on difficult projects. I’m planning to keep this list handy in 2017 as a checklist to make sure I don’t forget to use these techniques for my programming and learning projects.
Here’s the checklist:
- Work on important problems, or on problems that will lead to important problems.
- Use time goals to make sure you’re showing up.
- Schedule blocks of time so you don’t have to decide when to work.
- Track focused time to make sure you’re using your work time efficiently.
What are the Important Problems of Your Field?
It’s easy to get caught up in day-to-day work. If you apply the ideas in this checklist to that type of work, you can improve your productivity. But you might also find yourself wondering what the point of the work is. That’s why it’s important to have a big idea that you’re working towards. Your daily work can then be a way to advance that big idea, rather than just an end in itself.
There are various ways to come up with your big idea. A simple but profound one comes from Richard Hamming, who liked to ask his colleagues a set of questions beginning with, “What are the important problems of your field?“
I’m not a research scientist, so I don’t interpret the Hamming questions exactly the way their original audience did. But I like them because they’re a reminder to evaluate your work against challenging standards. In software development, the demand for programmers is high compared to the supply. As a result, it’s easy for a programmer to get stuck doing tedious work just because they’re rewarded for doing so. While it’s hard to avoid tedious work entirely, having a bigger goal in mind can help you direct your efforts towards a more significant result. If you don’t do that, you could find yourself working on commodity work forever (or until robots start doing it for you).
For software developers (as opposed to computer scientists), one class of important problems involves re-use of code. If you write your code in a way that other developers can find and re-use it for their own work, you can have a bigger influence than someone who just solves their own problems. With open source software becoming more widely accepted, your code could end up being used in places you didn’t expect. So one way for software developers to answer the Hamming questions is to look for opportunities to use software to solve a problem that many developers are having, and then convince them to use that solution.
Use a System
Although a big idea can provide long-term motivation and direction, it’s not as much help in organizing day-to-day work. For that, you need a system. After your big idea, your system is the the most important part of this checklist. Without a system, it’s too easy to just dream about your goals without doing the daily work required to reach them.
Your system has to be personal. Someone else’s system won’t work as well for you as one that you have built for yourself. But that doesn’t mean you have to invent a system from scratch. You can use the good ideas from other people’s systems adjusted and combined into something that works best for you. Here are the elements that I’m currently using in my system.
Time tracking
The foundation of my system is time tracking. When I’m working, either at my job or on my personal projects (like this blog), I have a Grindstone timer running. If I get distracted or called away to some non-work activity, I stop the timer, or adjust the time retroactively. (Since almost all of my work happens on a computer, it helps that Grindstone detects when I’m not actively using the keyboard or mouse).
Even with time tracking, it’s possible to spend time ineffectively. Not every hour is equally productive. (I’ll get to that shortly). But time tracking provides a minimum bar that lets you know how many hours per day and week you’re showing up to do your work.
Time goals
With a time tracking habit in place, you can get reliable data about how much time you’re spending on work. The next step is to decide how much time you want to be spending on work, and then adjust your system to help you reach that goal.
In my experience, the most useful time goals are daily goals. Simple daily goals are especially good for your main work activity, such as a job where you show up at a work location on a regular basis. The daily time goal says that you will spend at least $n$ hours per workday on actual work, as recorded by diligent use of your time tracker. You just keep working until you reach that number. If it’s a reasonable number, then that’s not an onerous requirement. It just ensures that you’re putting in your baseline work time, regardless of interruptions on any particular day.
For your primary work, a fixed, non-negotiable daily goal makes sense. You should pick a number that you can squeeze in regardless of how crazy your day gets. If a day is so crazy that you can’t reach your minimum daily time goal, then it’s basically a day off. There’s nothing wrong with that. Programmers with corporate jobs all get personal days. And if you’re working for yourself, you can give yourself the day off.
For a side project, a daily goal could also work. If you consistently have spare time after your regular work, you could pick a (smaller) daily number of hours, and hold yourself to that. If you have a one-time commitment during your regular side project time, you can track that as a “vacation day” from your side project.
For a bit more flexibility, I have a spreadsheet-based system I call Time Bank. The basis of the system is still a daily time goal, but it also allows depositing and withdrawing hours for days when you have more or less time available. The spreadsheet takes care of all the calculations. The idea is to still hold yourself to an overall time commitment, but allow more daily flexibility.
I created the Time Bank system for tracking side project time, but it could also work for job work time if you wanted to set your daily hours higher with the understanding that you wouldn’t be able to hit the goal every day.
Scheduling every minute
To make time goals even better, I recommend planning not just how many hours you want to work, but which specific hours of the day you will be working. Planning work time in advance removes some of the effort involved in getting work done. Rather than having to decide during the day when to do things, you just have to follow a schedule. If you build a habit of following a schedule that you create the day before, it’s a lot easier to reach your daily hour goal.
Cal Newport describes a system for “planning every minute of your work day.” It’s simple and paper-based, and it requires that you block out specific times during the day for specific activities. I find it too granular to use as-is, so I adjusted it to create my own version.
Rather than create blocks for specific tasks, I just plan the times that I’ll be working. In that sense my system is similar to Cal’s fixed-schedule productivity system, except that it accounts for breaks during the day and work time in the evening.
I also prefer electronic over paper recording, because that makes it easier to track a target for planned vs. actual work blocks used. For example, I might target using at least 75% of my planned time blocks. Note that this is different from planning to work 75% of my total planned hours for the day, since it requires working during planned blocks of time, not just finding the hours somewhere (or working late to make up for missed work time during the day).
I’ll write a post next year with more details on this part of the system, and the spreadsheet I use to track my planned and actual hours.
Deep Work
If the amount of work you accomplish is based on how many hours you spend working and how focused you are during your work time, then we have so far only considered half of the productivity formula. It also happens to be the half that has an upper limit. Eventually you can run out of available hours in the day.
So the last aspect of productivity to consider is focused work, which Cal Newport now calls deep work. Deep work has two benefits:
- If you work in a highly focused way, you can produce results that are more valuable.
- As you make a habit of working in a focused state, your brain gets used to this state, which makes it easier to focus in the future.
Just as most people don’t strictly schedule their work time, working in a focused manner doesn’t happen automatically. But just as you can get productivity benefits from time tracking, you can use focus tracking to get better at that skill. One easy way to get started with focus tracking is using the Pomodoro Technique. Since this technique is popular, it’s easy to find tools for your computer and mobile devices. Pomodoro gives you 25-minute blocks of focused time, which is a reasonable starting point.
To get the full benefits of deep work, you need more than just 25-minute blocks. I’ll be writing more next year on combining focus tracking with time tracking.
(Image credit: Kat)