It’s probably a bad sign that the words “Hi Mike” at the top of an email cause me stress. The thing about being the maintenance guy is that you are in the mix all the time. Whatever task takes someone’s fancy today could be added to your ever-growing pile of attention sucks tomorrow. Or today, if it’s fancy enough.
Don’t get me wrong – having work is way better than not having it. But when I talked about flow in the Time Sucks post, this is what I meant – you can’t build towards flow when someone is talking in your ear every thirty seconds. In a software development company, you can, assuming the organization is reasonably well-built, more-or-less organize this problem out of existence. In a maintenance role, not so much.
I find myself going one of two ways at times like this:
- I go off-task, transferring my attention to the new task long enough to satisfy my curiosity and/or cover my ass, as appropriate.
- I close the conversation and take a moment to “reset” my attention by going off-task on the internet.
The first method can be a rabbit hole that leads to a lot more time spent on the new task than I intended. Sometimes that’s appropriate, because the new thing is more important or because there’s an upcoming meeting to deal with. Most times it’s just time better spent elsewhere.
The second method, on the other hand, can become habit-forming. It’s really easy to blow an hour a day on Slashdot and Ars and wherever else you get your interweb fix, not to mention “research” on the new problem and interesting technologies and their friends and family and wiki articles (oh my!).
The risks are different, but both methods mean that your momentum disappears. To some extent both are part of the job. You will have fallow periods as a maintenance guy, begging for work; it’s the flip side of the 3AM application support call culture that dominates enterprise development in general and IT development in particular. In those fallow periods, you will from time to time do “research” that leads into “wasting everyone’s time”.
Over the last decade or so I have glommed onto the Test Driven Development design mode as a way of isolating units as much as possible. In particular, I think that one-assertion-per-test is very useful when you want to make sure that you always have something easy to “cache” that you can work on at pretty much any time. If you need to go off task constantly, you need to lower the barrier to entry for any given unit of work as much as possible. One-assertion style TDD achieves this AND it makes your system much more fine-grained in its behavioural definition.
It takes a little while to get used to this mode, and it annoys the hell out of some folks. But it has its benefits. It’s a balance-of-values thing, not a one-sided argument. In the case of a full-time maintenance role, I think that the balance is weighted towards doing the extra typing.