On pains and brains

A while back, I wrote a post on why software should feel pain. Since then, I’ve had that lesson reinforced in my mind, and I’ve also understood some nuances that weren’t obvious to me before, so I’m revisiting the topic.

The Reinforcer

What brought this topic back to my mind was a root cause analysis I did to diagnose a recent system failure. I’ll spare you the gory details, but here’s what happened in a nutshell: a daemon got bad data files and began behaving strangely as a result. The replication process for its data files had been impaired because the app producing the data files finished much later than normal. That app in turn was impacted by anomalous network brownouts which began with a partly damaged network cable.

The Obvious but Naive Lesson

The final step in my root cause analysis was to make recommendations, and I was quick to offer some: the daemon should double-check the integrity of its data file; the originating app should monitor its timing and complain about anomalies.

The more I thought about it, however, the more unhappy I became. Surely, such monitoring is a good idea. So why did I not believe my recommendations would really make things better?


The pain pathway is more than nerves in the toes; it runs all the way back to the brain. From René Descartes’s Treatise of Man. (Wikimedia Commons)

Continue reading

Interrupting my interruptions

Tonight I was just settling down for a ponder on some personal stuff when I noticed an email from my brilliant brother-in-law (hi, Stephen!), recommending an article about the cost of interrupting programmers. Half an hour later, I’m blogging about it. Yes, I see the irony in the read, the blog, and the shout-out, but I just can’t help it.

I’ve heard lots of estimates of the cost of interrupting, but the research in this article seems particularly clear. I think the article oversimplifies by assuming that the problem and solution derive purely from memory, but there’s enough insight and clever thinking in the article to make it worth a read…

We’ve all known that interruption = bad. We’ve nodded our heads at this wisdom for years. Occasionally we give lip service to it. We try to clump meetings in one portion of the day, leaving blocks of time for serious thinking and work. We advise our teams to use “lighter” interruptions (“ask your question by chat/email instead of in person; it’s less disruptive…”). We decline non-essential meetings and urge others to keep their invite lists small. We buy “cones of silence” and “Do Not Disturb” signs and set them up outside the cube of the guy who’s trying to finish urgent work for an impending release.

And then we fall off the bandwagon.

At least, I do.

Hi. My name is Daniel, and I’m addicted to interruptions. :-)


Image Credit: xkcd


You would see my addiction if you walked past my desk and looked at the tabs in my browser: two for email (work, personal), two or three for calendaring, some chat sessions, a task list, several programming topics, a man page, a python reference, an interesting blog post or two, three wikipedia pages, a ticket I looked up before I ran to my last meeting, a wiki page I’m in the middle of editing, a competitor’s product portfolio, a LinkedIn discussion forum on cloud computing, a Google spreadsheet, the PDF of a resume I’m supposed have read before I do an interview in an hour, half a dozen random sites that I visit during the day as I check gossip on a competitor or read the Dilbert cartoon someone emailed me…

How am I supposed to think Deep Thoughts when I’ve got that much noise?

Continue reading