Staying focused: it’s not just your environment
To be a productive programmer you need to stayed focused. Deep-diving into TV Tropes, chatting with your friends, or reading up on that fancy new web framework might be fun, often even educational, but they won’t get that feature you’re working on out the door.
And there are harder to spot distractions, digressions masquerading as necessary work: a fun bug that is less important than the one you’re working on, a technical detail that doesn’t really matter, a task that can be put off until later. In a world full of distractions, how can you stay focused?
One obvious influence on your ability to focus is your environment. Is it noisy or quiet, are you constantly interrupted or do you get time to yourself? But whatever environment is best for you, even working in your ideal environment may not suffice: you can still suffer from distraction and lack of focus.
If you want to stay focused you will need, beyond a good environment:
- The motivation to do your work, which requires you to understand both yourself and your task.
- Coping techniques to help you deal with the fact that focus is a finite resource.
Motivation: why are you doing this?
If you don’t care about your task, then you’ll have a hard time focusing. But once you do understand why you’re doing what you do, you’ll have an easier time staying on task, and you’ll have an easier time distinguishing between necessary subtasks and distracting digressions.
Why are you doing what you’re doing at work? In part, there are general motivations that apply to all your work on the job. For example:
- Money: Getting paid so you can buy food and shelter.
- Social pressure: You want your coworkers and boss to think well of you.
The problem with these motivations are that they are extrinsic: they come from the outside. Intrinsic motivations tend to work better. For example:
- A sense of obligation: You want to help your customers or users.
- Building and playing: Solving a hard problem is fun.
- Curiosity: Learning is fun too.
These general motivations will not suffice, however, if you don’t understand why you’re doing a particular task. Why does this data need to be collected? Why do you need to debug this seemingly impossible edge case; does it really matter?
Applying motivation: will this further your goal?
So how do you use motivation to stayed focused?
- Figure out the motivations for your task.
- Strengthen your motivation.
- Judge each part of your work based on your motivations.
1. Discovering your motivations
Start with the big picture: why are you working this job? Probably for the money, hopefully because you believe in the organization’s goal, and perhaps for other reasons as well.
Then focus down on your particular task: why is it necessary? It may be that to answer this question you’ll need do more research, talking to the product owner who requested a feature, or the user who reported a bug. This research will, as an added bonus, also help you solve the problem more effectively.
Combine all of these and you will get a list of motivations that applies to your particular task. For example, let’s say you’re working on a bug in a flight search engine. Your motivations might be:
- Money: I work to make money.
- Organizational goal: I work here because I think helping people find cheap, convenient flights is worth doing.
- Task goal: This bug should be fixed because it prevents users from finding the most convenient flight on certain popular routes.
- Fun: This bug involves a challenging C++ problem I enjoy debugging.
2. Strengthening your motivations
Keeping your motivations in mind will help you avoid distractions, and the stronger your motivations the better you’ll do. If your motivations are weak then you can try different solutions:
- If you work for a company whose goals don’t mean much to you, then you’ll have a harder time focusing: consider finding a new job where you’re doing something you care more about.
- If after enough research you’ve decided your task is pointless, you can either try to push back (mark the bug as WONTFIX, go talk to the product manager), try to add an additional motivation (is this a good opportunity to learn something new?), or just live with the fact that it’ll take you longer to implement.
3. Judging your work
As you go about solving your task you can use your motivations to judge whether a new potential subtask is worth doing. That is, your motivations can help prevent digressions, seemingly useful tasks that shouldn’t actually be worked on.
Going back to the example above, imagine you encounter some interesting C++ language feature while working on it can be tempting to dive in. But judged by the four motivations it will only serve the fourth motivation, having fun, and likely won’t further your other goals. So if the bug is urgent then you should probably wait until it’s fixed to play around.
On the other hand, if you’re working on a pointless feature, your sole motivation might be “keep my manager happy so I can keep getting paid.” If you have two days to do the task, and it’ll only take two hours to implement it, spending some time getting “distracted” learning a technical skill might help with a different motivation: switching to a more interesting position or job.
Coping with lack of focus
Even if you have an ideal environment and plenty of motivation, you will eventually run out of focus. This happens in two different dimensions:
- Time: Many programming tasks will take days or weeks to complete, and won’t fit in the limited window you can stay focused at a time.
- Space: There’s only so much code you can keep in your head at once, and most software projects will quickly exceed your limits. That means you can only focus on part of the code at a time.
You can only work around these limitations using a variety of coping techniques:
- Breaking up larger tasks into smaller tasks: Smaller tasks limit what you need to keep in your head, and can be finished more quickly.
- Abstractions: Good abstraction boundaries reduce how much you need to keep in your head at a time, and allow you to finish your task more quickly.
Another coping technique I don’t see used quite as often is writing everything down.
Write everything down
You’re working on a hard bug: you’re not sure what’s going on or why the problem occurs, and when you do figure it out it’s going to take a few days to implement. Along the way you will be interrupted by scheduled meetings, coworkers asking questions, your bladder, email, going home for the evening, a weekend vacation, two quick bugs, and a few hundred other distractions. Write everything down and distractions and interruptions will matter far less.
You start by trying out different hypotheses: maybe the bug is in this function, perhaps it’s in the environment, maybe it’s a difference in library versions… Write down all your hypotheses. That way when you get interrupted you won’t forget about them.
You try one hypothesis, and it turns out to be wrong. Write that down so you don’t forget and test it again. Eventually you figure out the real problem: write that down too. That way when you come in the next day you’ll remember what you learned.
Discover another bug along the way? Write that down by filing a ticket, and move on. Have an idea for a feature? Write that down too.
Next you come up with a list of subtasks to actually implement the fix, and then write them down, marking them off as you implement them. You’ll be grateful to your past self when you come back from the weekend and try to remember where you were.
In short: write everything down.
How to stay focused
To stay focused you need to:
- Work in the best environment you can manage: minimal distractions, appropriate levels of noise, and so on.
- Understand your motivations, both in general and as applied to this task.
- Try to strengthen your motivations, by choosing meaningful or interesting work.
- Judge your work based on how it helps achieve your motivations.
- Cope with lack of focus by breaking up tasks, using and building abstractions, and writing everything down.
PS: Want to learn more software engineering skills and techniques? I write a weekly email covering one of my mistakes and what you can learn from it.