Recently I was working on a tricky problem. It was one of those problems that only occurs on a test server but not on a development box. Since the test server was hosted on Azure (the same as our live server), this made it really tricky to debug. Doing a manual deployment to the test server takes about 40 minutes. So my write-test-debug cycle was about an hour! To make things worse, it was an intermittent problem, so I could never be 100% sure when it was going to occur. And to make things even worse, I discovered that the only way to reliably get the problem to occur was to do another deployment. Simply stopping and restarting the server, which would have been much quicker, didn’t have the same effect. Yet another complicating factor was that the error that occurred wasn’t in our own code, but instead it seemed to be in some other code that was executing when a page was loaded, before our code ran. So the call stack in the exception was a load of functions in the .NET framework that I couldn’t get at.

All of this meant that I had to treat this like a science experiment: Get as much info out of the system as possible, with some hacked in debug logging, to try and find out where the problem was occurring. And try various things to see if I could get the problem to occur consistently and (eventually) to make the problem go away consistently. This involved a lot of deploying of slightly different versions of the code!

So I spent a lot of time watching a progress bar creep across the screen. Then it would finish, I would try the code, hopefully learn something, have an idea for what to try next, make another change and then kick off another deployment to try it.

In theory I could have done something else while these deployments were happening. I had some code from another developer that I needed to review, and there were some other tasks I could have got into. But I’ve always felt it’s counter-productive to try and fit these in while other stuff is happening, despite the obvious low productivity of waiting for a deployment to happen.

My primary task, while not going very quickly, still requires me to maintain the state of the work in my head, so that when the deployment is done I can quickly do the next test and come up with an appropriate next step. Working on something else while deploying has several negative effects on the primary task:

• I may get so absorbed in the secondary task that I fail to notice that the primary task is now ready for me. This causes the primary task to go even slower!

• To work effectively on the secondary task I need to lose the mental state that I’m holding about the primary task (what test I’m about to do next, what I plan to do in the case of a positive or negative result etc). This means that I spend time figuring out what I was about to do next. This can also cause mistakes such as accidentally doing the same test twice, or running a test that turns out to be useless, which is obviously really wasteful.

It also makes it difficult to be productive on the secondary task:

• I have to keep checking whether the primary task is ready for me yet, and so I get nothing done on the secondary task.

• I may also find that I can’t get into the secondary task because it needs an hour or two of uninterrupted time and I know that’s not going to happen.

So I’ve come to the conclusion that when this type of thing is going on, it’s better to just focus on the primary task. There may be one or two things you can do that don’t distract you too much, like reading up on the technology you’re using on the web in case the answer jumps out at you. But basically, sometimes you just have to suck it up and accept that what you’re doing at the moment needs to be your primary focus, even if it feels like you’re wasting a lot of time.