The interruptible programmer

Let's drop back into reality for a minute. Just 15 minutes ago I was tracing sql data converted to xml by a rails application which was processed by a perl frontend. Yay legacy code.

It would really be nice for things to be simple but the reality is I'm dealing with multiple erp systems that output mostly similar xml thanks to the people that where here before me. It is not possible to not end up in super brain mode with some of the problems I deal with.

Now my latest project was rather complicated. I took a report that only showed current inventories and converted it to display inventories at any specific day. It was all fine and simple until I encountered a little off by one bug which caused most of the dates to be off by one. Tracing that error through all the layers required a number of hours. I am thankful I was not interrupted with an emergency fix to some production report so it only took hours to fix instead days.

It would be nice if things were simple but not everyone gets to work with clean environments and applications.

I'll argue that it is possible, just not necessarily preferable. You could rewrite the whole thing. You could also focus on building a number of small functions which brings the whole interface up to a human-digestible level.

The reality of the matter is not the realm of possibility, but instead that you often just want to get it working by whatever super-herculean effort it takes. People are often very interruptible while fighting hydras or stealing golden fleece.

So it's twofold. Ensure that as often as possible you've got the programmatic infrastructure to only consider human-digestible chunks of complexity at any given time and try not to be interrupted whenever that's not possible.

Much of the problem with interruptions is that of losing context. When you’re in that Zone, you’re juggling a whole bunch of context in your head, adjusting it on the fly, and maintaining and tweaking connections between issues constantly.

I find that there's an all-too common hair-shirted developer mentality that glories in the stunt of keeping track of umpteen different entities and variables at once. Mental/conceptual organization is an area where work smarter should definitely trump work harder. I think a part of the problem has to do with the tendency for dramatic fire-fighting to be rewarded in organizations. What results is like an emergency responder TV show. It's exciting to watch the responders rappelling or doing something exciting and unusual every week, but in reality a well run city would strive to make such events as rare as possible and be boring as possible.

Think of it this way, if you ran a trucking company, would you want employees who had a different hair-raising tale to tell on just about every trip? Do you know developers who are full of such tales?

Let me ask this: after you've written such code, how is it for other people to read it? What is it like for people to debug it?

I think a lot of the problem comes down to us using the brain for stuff it's not great at.

I think good programming design tries to maximize the stuff your brain is good at and minimize the use of stuff your brain isn't good at.

This recent HN item is relevant: http://calnewport.com/blog/2007/10/08/monday-master-class-ho...