Distractions, and how to get back in the zone more quickly

Rob Greyling
Rob Greyling
23 Jun 2017
blog post featured image

Here’s a little productivity tip for all you programmers out there that I’ve been using for so long now, it’s second nature to me, but it’s only just occurred to me that I’ve never shared it with anyone. You ready? Here it is:

Do not, under any circumstances, leave yourself with working software at the end of any given coding session.

Yep, that’s it! Simple! But why, you may ask? Actually, you’re probably starting with “WHAT?! How does this improve my productivity?” Well…take a breath and I’ll tell you. It’s like this:

You’re in the zone, coding away, minding your own business and out of nowhere … BAM! No, it’s not a head-on collision in the street outside, or your copy of C++ for Dummies crashing to the floor again, or even a door slamming in the distance. It’s something just as effective at breaking your concentration though, and pulling you right out of the moment you were having with your IDE. Yes, it’s an unsolicited interruption induced by a well-meaning colleague who has no idea about the havoc they’ve just wreaked.

And it doesn’t have to be in person. It could be that you left your email open, or one of numerous notifications that steal your attention during the day. We all know that it takes (what feels like) absolute ages to get back into the zone once you’ve been distracted. But what if there was a way to bring that refocusing time down, a way to make that inevitable distraction less destructive to your productivity?

When it comes to coding, this is how I do it — by leaving my software thoroughly broken… locally, before I stand up or switch contexts. What you’re trying to create here is a pointer to something simple enough that you can solve fairly easily without wider context, but not so easy that you’re done in a couple of minutes forcing you to then think about the next problem.

Here’s one I baked earlier

Take a look at some code I was working on this week as an example:

Broken Code Snippit As you can see, I’ve left it in a state that cannot possibly parse or compile, and I’ve also left myself with an instruction of what to do next. It’s not so trivial that I can solve it quickly, but neither is it so difficult that I need to recall things about the entire code base in order to solve it. I just trust that I gave it enough thought last time, and that this is a good place to start. But that’s not the magic part…

The magic that happens when you do what I’m describing above, is that your brain disengages from the distractions you were thinking about a few minutes before, faster than it normally does. The magic is, that you don’t end up spending the normal amount of time “getting back in the zone”

It’s an interesting phenomenon to try and explain, but here’s the side-effect I have found that happens to me: while I’m solving this broken code above for maybe the next 10 to 15 minutes, my brain is on a background thread, re-synchronizing itself with this particular set of problems, this code base, this project, because I’ve given it the prompt it needs to do so.

You don’t need to do anything more than start working on that problem you previously set yourself. Your subconscious brain takes care of the rest. There are two things that take practice and discipline before this trick can start working for you:

  1. You need to consciously recognize that you’re context switching or have just been distracted so that you can activate step 2 below.
  2. You need to get good at setting yourself meaningful tasks at the point in code you’re at that won’t be as simple as deleting it when you sit back down. 

For the best results with step 2 above, it needs to be something that will take you at least 10 to 15 minutes to complete. As is the case in my code example above, there was a core of logic I was following just before stopping work, I recognized a context switch coming, and set myself the task of fetching the data from the database which would complete that piece of logic.

Another option that I regularly use is to write myself a failing unit test, something that will take sufficient time to fix. Or if I don’t have time to write the failing test, I simply take a minute to describe the tests in pseudo code that won’t compile, but give me enough to be getting on with the next time I sit down.

If your distraction is something that forces you to stand up immediately without any time for the strategies above, the fallback I use is to simply mash the keyboard where I am. This tells me two things:

  1. It tells me exactly where I stopped coding just in case I was busy solving a logic problem so I know where to pick up again;
  2. And it tells me I didn’t have time to give myself a proper task to complete, so I was likely not in a position to complete anything of substance at that point, which means it will take me longer to get back in the zone, but it’s better than wondering where to start. 

And no — code comments with TODO don’t work nearly as well. Firstly, they don’t break the compiler, so now you need to go hunting, and secondly, you probably already have a hundred of them littering the code base as reminders of things you need to come back to at some point in future. Just break the code — it’s not that hard to do ;)

Before considering the mashing-the-keyboard option though, the code example above shows just how quickly you can write yourself a meaningful message before standing up — probably 10 to 15 seconds, if that — so if you can, try to employ good discipline, and you’ll reap excellent benefits!

Not just for interruptions

This way of working doesn’t only work when distracted. Sometimes you get to the natural end of a piece of work and decide to take a break, or the end of the working day.

The worst thing you can do, is tie a nice, neat little bow around your work, and give yourself a satisfied nod as you take a step back from your day.

You won’t have a clue where to start tomorrow, or Friday, or in the next two weeks! It will be such a nicely bundled up package that you won’t want to spoil it by ripping it open again to add more functionality. You need to leave a rip in it, some kind of tear that will urge you to fix when you come back. 

And I can guarantee that even if you come back in two or six months without seeing the code in between, if you’ve left yourself a nice little puzzle to solve, you’ll be back in the game much quicker than if you had to poke and prod for a place to start.

It used to be the case that my OCD tendencies wouldn’t allow me to leave the code in this kind of state for long periods of time, and by that I mean more than 30 minutes. Well that didn’t last long when I realized that my OCD couldn’t compete with my need to break down inefficiencies and get momentum back more quickly, and that overcoming my need for neatness was the key!

Safety first

“But what if I accidentally commit that change in a blind rush and break something for my team?”. Well the short answer is — Don’t do that. But if you’re really worried about that in the beginning while you’re getting used to this way of working, then set yourself a puzzle, and stash the change. I used to stash mine under a name like start-here and apply the stash to get going again. 

Another strategy I’ve used is to push those stashes up on other branches with clear instructions in the code for juniors or developers new to the project and then told them to go fill in the blanks at the points where it doesn’t compile in an effort to get them going on the project faster. This works very well when you don’t have the time to explain the whole code base, but have a small focused problem for them to solve and gain them some familiarity at the same time.

In the end

The obvious winning strategy is not to get distracted in the first place, if that is something you can control, but in the (numerous) situations where you can’t, at least you can use this little trick to get back into the zone that bit faster. Try it, let me know if it works as well for you as it does for me!

Close chatbot
Open chatbot
Open chatbot