views:

576

answers:

12

I usually take hours to get into the zone. But I kept getting knocked out of the zone (usually by coworkers asking for help) and switching between programming tasks is tiring.

How do you get back into the zone after losing it?

+1  A: 

Most of the times music does the trick for me.

Peter
+2  A: 

If it really takes hours, you should seriously try to avoid getting interrupted in the first place. Separate room, "do not disturb" sign, or whatever might work for you. Losing hours because of interrupting coworkers translates to real productivity lost (== $$$).

JesperE
Upvoted. Too bad it can't work in my work environment. I'm the most experienced programmer (most of my coworkers just got out of college), so I volunteer to help them. Also, the place is a little bit crowded. I always half-jokingly say that the comfort room is my office to prevent interruptions. :)
MrValdez
+2  A: 

Usually I don't have big problems with getting back after being disturbed. But tasks that really need undisturbed focus will just have to wait until I can have some undisturbed time. For example after everybody else has left the office, during my once-a-week work-from-home-day, working from home in the weekend...

If it really really must be done RIGHT NOW, I get a colleague to cover me. He'll answer my phone and talk to visitors. Email and IM is ignored.

myplacedk
+16  A: 

I've found using a log book to be useful. The idea originates from research laboratories, where researchers/scientists will log every step they take so that their process is reproducable and they can verify what was done, what remains to be done. Often these logbooks form legal documentation when disputes around originality of research be come courtbound.

The way I use it is to have a smallish (A5 sized, spiral bound) notebook open on the desk next to my mouse. Whenever I reach a conclusion, or have a specific question, I write it on the next line - nothing detailed, just a few words. Each line tends to capture a few minutes of context. Often, I write the time (just minutes after the hour) at the start of the line.

When I lose flow, I can regain it by rereading the last half our or so of notes - this serves to remind me of my context and helps me regain flow in much less time.

I also find this useful when getting into complex debugging - helps me remember the questions and ideas that I've had already, and wether they were helpful or not.

Update 29/10: As others have noted, this approach takes a fair amount of self discipline. It's really easy to get interrupted and then realise your last progress note was two hours ago. There are times when I use this technique religiously - and times when I just can't be bothered.

Bevan
That's a great idea - I'll give that a try myself. Thanks!
robsoft
That's interesting, I'm doing pretty much the same thing. I don't keep track of minutes, but I do use an A5 spiral bound notebook :)
Stefan
+2  A: 

Try to leave some sort of simple hook for yourself that you can engage with when you come back - something that leads into the main problem but doesn't require you to wrap your brain around the whole thing immediately.

Ideally this would be a red light on a test: but I find that

  • a text file open on my desktop that says 'FOO SHOULD NOT BE PUBLIC'

or even

  • an open session with a Yellow Page of Death error that indicates the last problem

can be enough.

With luck you can grapple with the simple problem for 5-10 mins and then find you've spun back up again.

EDIT: this is a cheap version of Bevan's approach in this thread - I think his approach is better in principle but not everyone has the self-discipline for it (not sure I would :) )

alexis.kennedy
+6  A: 

This is what I do:

  • Ask my interrupter to wait a minute while I get the code to pass compilation (not necessarily passing the unit test)
  • Once it passes, add some deliberate compiler errors
  • When I return, I can usually pick up on my train of thoughts by studying the compiler errors.
MrValdez
+1  A: 

It happens to me a lot. When I'm running up against a deadline I normally make sure I have all the source code, servers, tools installed and running on my notebook; then get myself to a coffee shop for the whole day. This gets me in the zone every time. If for some reason that's not possible I work through the night when no one is in the office, with my music playing on the speakers and no one around to complain. If that isn't an option, I will go out for a walk or bicycle ride to clear my mind and come back refreshed.

The above remedies require a flexible and progressive employer obviously.

Failing all else, putting a sign on my desk/cubicle saying I am busy, please don't interrupt is a last resort.

The key is not to get out of the zone since, as you imply, getting back into it can be frustratingly difficult.

rwired
A: 

I always keep the music on when working on a task that requires my full attention.

The music works in two ways.

  1. I don't hear any distracting noises as I have my headset on.
  2. If and when I'm forced to focus on something else I hit pause. When I start working on the task again the music will quickly remind me where I left of.

Also we use primarily skype for communicating so I always turn it off. If something really needs my attention immediately they will call my mobile (luckily it's quite rare)

Gene
+1  A: 

Separate answer for prevention rather than cure.

  • invest in a pair of good noise-deadening headphones.
  • it's now harder for people to attract your attention. Encourage them to IM you instead of tapping on your shoulder for non-urgent issues. That screen-corner flash will still distract you, but it's asynchronous. At worst it can wait ninety secs while you mentally save your progress. At best you can leave it half an hour and come back to this:

Junior Dev 1 [14:55]: Help! Build is broken!

Junior Dev 2 [14:58] What was that URL you sent me this morning again?

Junior Dev 1 [15:02]: Don't worry I fixed it :)

Junior Dev 3 [15:10]: I don't understand this warning, what does it mean?

That way you can address a bunch of problems at once rather than get interrupted three times; they may fix their own probs in the meantime; and if it's all the same channel they may start fixing each others' problems. There are dozens of reasons why this specific approach might not work in your environment, but I imagine you can see what I'm getting at.

alexis.kennedy
+5  A: 

Trying not to lose the focus in the first place.

If you work in your own office, close the door.

Turn off your email client's message notification.

Ask people to email you their problems in the first instance:

  1. You can deal with them in your own time
  2. You can partially prepare your answer, thus be more efficient with your time
  3. Writing a question often partially answers it, so your input might actually be less required

But @Bevan's suggestions are tremendous - if you can't not be disturbed train yourself to re-focus more efficiently.

Unsliced
+2  A: 

There is no substitute for time (and productivity) loss when being knocked out of the zone. There can be many ways to mitigate the effect, but it nowhere comes close to making up for it. You (and management) have got to try to provide an uninterrupted working environment. This question is at best "damage-control" category - it's like an organization evaluating plans on what to do if it gets bankrupt rather than solving the problems that can lead to bankruptcy.

One the best articles I have read on this is by Joel ..

http://www.joelonsoftware.com/articles/fog0000000068.html

Ather
+1  A: 

TDD practitioners can stop on a failing unit test, as an alternative to MrValdez proposal to introduce compilation errors in the code.

This is not easy when the phone rings, a little more when someone drives by your office ; but I find it really it efficient over night. When time has come to leave the office, write a last test, make sure it fails and leave. On the next morning, run your unit tests again, see the red bar, the failing test and you should have your brain restoring your mind context.

philippe