I find that doing TDD makes it much easier to get in the zone; more importantly, it helps to get back into the zone if I get off track. I typically stub out a

I find that doing TDD makes it much easier to get in the zone; more importantly, it helps to get back into the zone if I get off track. I typically stub out a bunch of tests (just empty methods named based on what I plan to test), then go one by one and fill in the tests and write the implementations. In the codebase I work in, we use a lot of mocks / fakes, so I typically write my tests "in reverse" - first the verification of results, then the mock / fake expectations for what methods should have been called. Then I'll write the actual implementation, and then fill in the mock inputs. This way, if I get interrupted, it's very easy to transition back into what I was working on, as I make sure to always leave a breadcrumb trail for the next piece (when I run my test, the failure will give me a hint as to the next step to take). And since I have a bunch of stubbed out test methods, once one bit is finished, I can move onto the next one and repeat the process.