Coding in the Age of Distraction

I must have seen a hundred blog posts suggesting that the best way to become more productive is to minimise distractions: Switch off IM, disconnect the phone, block out quiet time, get a private office and so on. While I’m sure that these would be of benefit, sometimes distraction is inevitable. I could switch off IM, email and my phone but I happen to work at the desk next to my boss. Convenient as it may be, my boss does not come with an off switch. Also, priorities happen. I may believe that my ‘in the zone’ coding time is golden and must not be interrupted on pain of code diva tantrum. However, if the production server goes down then scheduling a fix next week is just not good enough. Finally, I do on occasion like to stop work for the day and go home. A good night’s sleep is definitely a distraction from work but also I think quite important.

It’s certainly worthwhile arranging your environment and schedule so as to minimise distractions. But it is also important to accept that distraction will happen and to plan for it.

Test Driven Development

I’ve started adopting Test Driven Development (TDD) practices over the last year or so and discovered an unexpected benefit: failing tests are a great placeholder for your thoughts when you get distracted. Here’s the process:

1. Stub a new test. A single line test method is fine here:

   @Test
   public void testFail() {
       fail("TODO: Create test for feature xyz");
   }

2. Implement the test. According to TDD practices, we expect the test to fail as we’ve not implemented the feature yet.
3. Implement the feature
4. All tests pass so check in to the SCM repo (your own sandbox or the trunk / mainline – depending on your team practices). Go to step 1.

Wait, where was I?

Calamity! Some critical event has interrupted you! The production database has become corrupted! Or your development machine has started spewing blue smoke! Or your boss decides to hold an impromptu team meeting RIGHT NOW!

After dealing with the emergency, how long does it take to recover and resume work? In the past it would take me up to half an hour. If I was lucky I would have left the code in a ‘broken’ state where a half implemented solution did not compile. Then I’d simply start from the lines of code that the compiler objected to. However if the code compiled but is just doing the wrong thing it would take a little investigation. I’d have to remember what task I was working on, then open up the source files relevant to that task, then follow the code till I found something that looked familiar.

Following a TDD approach though, I discovered that I could always recover quickly because there’s always a failing test and the failing test refers to a small unit of work. Depending on where you are in the TDD cycle, here’s how to recover:

1. A new test exists that has not been completed. No problem. The test tells you it’s failing because it’s incomplete so you know to resume work on the test.
2. A completed test exists but the feature is not started. No problem. Start work on the feature.
3. A completed test exists but the feature is not complete. Still no problem. The test still tells you why it fails. Go to the feature implementation and fix it to pass the test.
4. All tests pass and your code is in sync with SCM. Lovely though that is, this is actually hardest to recover from. Still, you’re not in the middle of anything so  you can start work on any new task you like. Also your last comment in SCM should at least jog your memory.

Leave a rough edge

Cory Doctorow gave some counter-intuitive advice on (prose) writing in his excellent piece Writing in the Age of Distraction (also available in Context: Further Selected Essays…). He suggests:

When you hit your daily word-goal, stop. Stop even if you’re in the middle of a sentence. Especially if you’re in the middle of a sentence. That way, when you sit down at the keyboard the next day, your first five or ten words are already ordained, so that you get a little push before you begin your work. Knitters leave a bit of yarn sticking out of the day’s knitting so they know where to pick up the next day — they call it the “hint.” Potters leave a rough edge on the wet clay before they wrap it in plastic for the night — it’s hard to build on a smooth edge.

I’d suggest that this works well when writing software too. Assuming you have a good, well tested code base, your ‘rough edge’ is the one bit of the whole code base that does not pass tests or causes a compilation fail. Working from the rough edge is easy: fix a single compilation error or a single test fail. Once you’ve done that and your code builds and your tests are green, you at least have your editor open at the right place. I reckon more importantly though, you have your brain at the right place too.