There is this wonderful anecdote in the book Peopleware by Tim Lister and Tom De Marco:-
One day, while Wendl was staring into space pondering problems of extreme complexity with his feet propped up on the desk. Their boss came in and asked, "Wendl! What are you doing?" Wendl said, "I'm thinking." And the boss said, "Can't you do that at home?"
When I read it, it reminded me of another remark made by a project manager I once had. I can’t remember the ins and outs but essentially he remarked about how funny it was that someone he knew (of) was paid for his “thinking time”. Naturally, being just a mere “resource” I followed suit and indicated my surprise too. But not because I couldn’t imagine such a practice, but because at that point I began to realise how I’d been partitioning my own day to avoid such a confrontation.
At the time I hadn’t read Peopleware and so when I got home I asked my wife, who is a producer that spends a fair bit of time dealing with “creative” people, whether the people she worked with got paid “thinking time” too. I seem to remember her reaction was one of slight bewilderment due to the notion that people who do creative work can somehow perform it without doing any “thinking”.
There is a long standing debate[1] around whether (or how much of) programming is Science, Maths, Engineering, Art, etc. For me personally, given the type of work I do, I’d probably be in the “mostly engineering” camp, but am aware that “creativity” also plays a significant role at times. And that is probably why, when I read that anecdote in Peopleware, I smiled because I can see the same reaction from some of the people I’ve worked with. To them, what we do is pure Engineering. We just follow the various best practices and established Design Patterns (along with cut and pasting solutions from StackOverflow) and turn the handle on the meat grinder to churn out another system that solves the customer’s problem. In the supposedly uber-safe corporate environment you don’t take risks, and therefore there is obviously very little reason to ever “get creative”.
For me perhaps that perception is one of my own making. After all, during the hours of 9 and 5 I spend the day “writing code”, answering questions and generally getting stuff[2] done. I can’t imagine sitting at my desk gazing into outer space whilst I contemplate how I’m going to solve some tricky problem - it’s just not the done thing. Techniques like TDD are great at helping you triangulate to a solution, but only once you have some vague idea where you’re heading. And that’s a large part of the battle - having some idea how you’re going to tackle a particular problem. Often it involves drawing on your Google Fu to find the answer, a spark that leads you in a new direction, or recognising the similarity elsewhere in the code that brings the problem into focus.
Sometimes though you just don’t have an obvious direction, and at those times I’ve found that rather than get blocked (and therefore appear to be doing nothing) I’d prefer to find some tangential work to do instead. Then I can use a forthcoming break, either for coffee, lunch, or going home as the distraction I need to take myself away from “being busy” to allowing my conscious and subconscious to get to work on the gnarly problem I’ve been procrastinating over.
Working this way draws on the popular concept of The Lazy Programmer. This term is not meant to be a derogatory one to describe those within the profession that clearly cut corners to get their work done, but more an attitude that tries to suggest how we need to work smarter - not harder. The alternative is to “go dark” and plug away relentlessly at keyboard, somewhat akin to The Infinite Array of Monkeys, until “the solution” eventually drops out the end. That’s really not my style - I prefer inspiration to perspiration.
If you’re driving a car and you get lost, assuming you’re not “a stereotypical man”, you get the map out or flag down a passerby to help orientate yourself or get new directions. So it’s natural therefore to talk to your teammates and discuss problems with them, no? And yet that’s something I’ve found myself do much less of, not because I don’t want to, but because in the corporate environment there is the (perceived) expectation of autonomy[3] that almost forces you to solve everything by yourself. After all, if you didn’t, what on Earth are they paying you for? Or maybe, and perhaps this is a very British thing, we do not always feel comfortable interrupting our colleagues?
Over the years I’ve learnt to break my workload down into such small tasks that I find any interruption easy to cope with. If an email pops up or a message via IRC or someone swings by the desk I can usually deal with it there and then. The notion of Flow, another concept that Peopleware discusses in detail, is something I just do without during the day. The way I’ve come to see it is that is someone else is blocked and I can help then out, then its the team that wins. Okay, so I get less work done personally, and that has been hard to justify a couple of times in the past, but I just achieve the necessary state of consciousness at another time - whilst cleaning the kitchen or making the tea.
Ultimately it now feels inefficient to use the time sat at my desk to “think about ‘heavy’ stuff” when I could multi-task and do it later. Sadly I’ve not yet learnt to multi-task to the extent that I can do thinking, washing up and hold a (meaningful) conversation with my wife. I suspect it’s also a downside of your job being your hobby too - when exactly do you “switch off”?
[1] I’ve lost count of the number of times this has shown up on the ACCU’s main mailing list - accu-general. But I do remember it being a more interesting debate last time as people got right down into the nitty-gritty of what they do and how they work.
[2] Yes, by “stuff” I mostly mean doing support. I might be answering the same question for the umpteenth time, or doing some sysadmin style cleanup. Alternatively it might be a dash of analysis, either of a “new” problem or the results from a recent change. Or writing some documentation, looking at a broken build, etc. Sometimes when things are really quiet I’m known to write some actual code too...
[3] This, I suspect is the reason why pair programming struggles to find ground within The Enterprise. The sheer thought of two people doing one job, despite old adages like “two heads are better than one”, is just incomprehensible to some. After all, isn’t Pair Programming really just a synonym for Job Sharing?
