The stopping point fallacy

This Geek Hero comic by Salvatore Iovene reminded me of a recommendation I made about programming a few years back. Even with the best documentation and planning, effective programmers must keep a lot of state and context in their heads. That's why it's so difficult to get back into the flow the next day, why even a 10-minute interruption can cost hours, and why – above all else – we can't call it a day until we reach ‘a good stopping point’.

The trouble is, most people are terrible at predicting how long it will take to get to that stopping point. That gut feeling that we're “really close to fixing this bug” (or finalizing that class, or finishing this refactoring) can last for 4 or 5 hours – until either we do finish it, or we determine for certain that it's an order of magnitude more work than we thought. In grad school, my office-mate's girlfriend once asked me what was going on when her beau said he'd be home in an hour, but three hours later she'd phone and he'd still be there. I'm sure many hacker widow(er)s are familiar with this scenario.

I don't claim to have a solution to the problem of restoring context after an interruption; however, I have come to believe that insisting on a good stopping point is counterproductive.  Let's say you get there: bugs fixed, test suites passed, clean code committed, and you go home happy.  I claim that the context problem will be even worse the next day.  You sit down, type ‘make’, and it builds cleanly.  You type ‘make test’ and it succeeds spectacularly.  You type ‘svn status’ and your working copy is clean.  Now what?  Meh.  Fire up the feed reader and ease into your day.

Imagine this alternative.  You're implementing a new function you'll need to fix a bug, but it's getting late.  You hit the build button, ready to try it out, but instead you get 21 compiler errors.  Perfect – go home now. WHAT!?  I know, it pains the hacker's brain even to imagine it.  That's not a stopping point!  But think about tomorrow.  You sit down, build it, and suddenly you are pulled right back into the code, fixing the errors.  Sure, it will take you a bit longer without the immediate familiarity you had last night, but you're already engaged in a simple, low-level activity that will help you restore context quickly.

©20022015 Christopher League