Sometimes, that’s all it really takes, when you’re hacking code. You know how I know? I tried it last week without even intending to.

In my case, I commute from San Jose to Mountain View every day. On the CalTrain, that takes twenty minutes. I also commute back on the CalTrain – another twenty minutes. That’s enough time to pick up where I left off, fix a little bug in my code, rerun the test, try to fix another little bug, and power down the laptop. I’m just fixing bugs at the lowest level of complexity – one component, one interface, one test case. For a twenty-minute session, that’s about all I need to think about debugging.

Now, of course, I spend a lot more than twenty minutes a day working on projects for the office. I’m also (I hope!) more efficient with my time at work – I can juggle a lot more files in my head at the same time when I have more time. For the really small stuff, you can achieve a lot in twenty minutes a day.

One other benefit, and I believe I’ve said this before: When you’re working with test cases, those test cases later become examples you can reuse in your actual production code. More importantly, they should produce code you can cut-and-paste into your real program, with only variable name changes. That greatly increases the chances your code will work as you intend it to – if you test code one way and it passes, use that way to implement your real work. (Or, just write your test to emulate how you’d really use your component.)