Afterwood

While on a recent trip to an alternate recycling centre with my daughter, she noticed they had a bunch of smaller specialist bins separate from the huge containers used for the main bulk of waste. There were a couple for CDs but, more interestingly, there was one filled with books. She started to have a rummage and then called over to me as she noticed a programming book in amongst the James Pattersons. As expected, it was one of those ‘Learn to Program in 24 Minutes’ style books from the ’90s. However, as I dug deeper, I noticed a whole bunch of far more useful programming books, and all in pristine condition. Although slightly incensed that someone decided to bin them rather than take them directly to a charity shop, I was grateful they hadn’t disposed of them in the generic waste containers to be tossed on the landfill or incinerated. (Hopefully, the recycling centre will ensure they eventually find another bookshelf to live out their days.)

Anyway, one of the eleven books I liberated was Andy Hunt’s 2008 classic Pragmatic Thinking & Learning – Refactor Your Wetware, which had been on my ever-growing wish-list for years. Being excited about yet another non-technical book probably adds further weight to J.B. Rainsberger’s observation about a programmer’s bookshelf largely consisting of books on applied psychology once they reach a certain level of proficiency.

The book uses the model of the brain from Dr Betty Edwards which introduced the terms L-mode and R-mode as an alternative to the older, more simplistic left-brain/right-brain version. R-mode is the background asynchronous mode which chews over problems while you’re doing more mundane tasks like going for a walk, doing the dishes, or having a shower. This is the basis for the age-old advice about stepping away from the keyboard when you have a problem for which there is no immediate solution. In fact, just this very morning I awoke to discover that I’d worked out in the night while fast asleep that I could replace 13 lines of code in my colleague’s PR with just 2. (Something didn’t feel right when reviewing it yesterday, but I couldn’t put my finger on it.)

Being a contractor it’s not uncommon to be forced to take the two weeks off at Christmas to save the company money, and because I suspect we can’t be trusted for some reason. (Maybe they read my previous Afterwood, where I admitted to Santa that I might have played a bit too much Doom during Christmas of ’93.) This practice hasn’t bothered me personally as I’m happy to take the time off and spend it with my own family, along with taking a welcome break entirely from programming. That’s not entirely true of course because it just gives my brain’s R-mode a chance to start chewing over the backlog of less immediate issues instead. Even when we’re supposedly ‘off the clock’ our brain still manages to find some background computation to amuse itself.

Consequently, two years ago I found myself thinking about thinking, which led to my 2024 opening piece ‘Thought Experiments’. Clearly I hadn’t spent enough time thinking about it because I realised this Christmas that I forgot to cover the ‘when’, which was no doubt asynchronously triggered by a conversation about the 1987 book Peopleware by Tom DeMarco & Tim Lister. (The latter of whom I got to chat to in the bar at the ACCU 2012 conference.)

That book is legendary, and contains one of my favourite stories:

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?”

This story immediately resonated with me as I read it not long after having a conversation with my project manager where he was describing how ridiculous it was that someone he knew was paid for his ‘thinking time’. While not as explicit, this opinion was undoubtedly shared by other project managers I had worked with in the past and who probably felt that typing was the only true measure of productivity and value.

In the intervening couple of decades, more and more teams I’ve worked in have adopted an agile way of working where there is a drive to try and distil every bit of work into tiny units, meaning that any ‘hammock time’ you might want to think things over is timeboxed and scheduled on the Scrum board. If Wendl was in a corporate agile team today the Scrum Master would likely be interrogating him every morning to ask him to estimate how much longer his thinking was going to take and when he was going to get back to ‘product work’.

With the focus so firmly on solving ever smaller problems and hoping that the right design will eventually emerge there is no time to simply stand back and take in the bigger picture. There is time in the diary for a retrospective on how the team delivers, but where is the time for reflection on the architecture and design? Who is watching the evolution of the codebase and thinking about the direction it’s heading, and whether that really fits in with the intended direction of travel? Changes shouldn’t be held to ransom by pure speculation but as plans solidify so does the opportunity to make smaller course corrections instead of taking sharp turns.

I’ll freely admit that I resent the attitude of that project manager who scolded Wendl, and those who have propagated the same opinion. With L-mode constantly engaged during the time in the office, R-mode only gets a look-in at home – code by day, design by night. Fortunately, with the rise of remote working in the last 5 years my R-mode is finally getting the opportunity to see more daylight.

Wandering over to the sink in the office to wash up the cups would likely be met with awkward questions, but at home my actions are less suspicious and R-mode can safely engage itself. The danger then is picking the wrong mundane task – packing the dishwasher might seem trivial but is effectively a game of Tetris, and pairing socks is akin to Candy Crush. Maybe it’s best to play it safe and just put my feet up, I wouldn’t want to overthink it.

Chris Oldwood is a freelance programmer who started out as a bedroom coder in the 80s writing assembler on 8-bit micros. These days it’s enterprise grade technology from plush corporate offices the comfort of his breakfast bar. He has resumed commentating on the Godmanchester duck race but continues to be easily distracted by emails and DMs.