Over at Chris Parnin's website there's an article that explains why you should never interrupt your programmer, but the real issue is encapsulated in Jason Heeris's famous cartoon, and if you're not going to bother clicking over there, the gist is this: it shows a developer looking at a single 'if' statement, from which she imagines, slowly, piece by piece, an enormously complex mental idea of what the code is supposed to do, of pieces of the code interacting in one correct way, all the modules communicating with set flows in a pattern that produces an outcome. In the penultimate panel, someone interrupts her with a trivial matter, and in the last she's back at the 'if' statement, starting over, the scaffold gone.

Every part of that cartoon, and the associated article, is a mistake. It's not a lie: everything that article talks about is completely and utterly true; in modern development environments, knowing the state of a single byte can require one contemplate, to an absurd degree, the meaning of very large systems. Object-orinted programming was supposed to alleviate this problem by having every object be its own, independent unit of knowledge, communicating with neighbors and siblings through well-defined and very small communications channels.

It didn't work out that way. We weren't disciplined enough to make it work that way. Instead, we would up with UML and RationalRose and ad-hoc Yourdonesque entity relationship diagrams and codeflow systems that try to specify the system in the large, and leave it up to the individual developer to remember, to the absurd degree shown in the cartoon, all the conditions that make the state memoized by a given object relevant and meaningful.

I'm not that smart.

No, really. I'm an average programmer whose favorite game is finding the right tool for the job. Time and again, my experience has shown that the right tool is one that constrains the problem to four lines of code, and constrains those lines further to function calls with type signatures that ensure the code is passed between them correctly. In 99.94% of programming, we only ever do four things:

  * receive
  * validate
  * transform
  * emit

That's it. If you think your code does anything special at all, you're probably wrong. You're as likely to be doing something not on that list as you are of select() being broken (and hint: select() isn't broken).

Every web page is like this: your server gets a request, you emit a page. You get an event, you emit a new DOM fragment that updates the page. Every video game is like this: you get a joystick event, you emit a new game state with your dude's jump variable set, your starship's turn rate updated. Every clock tick is just something you received and have to transform into a new view for the user. Sometimes, what you receive has to be combined with other data extant to your system, but that's merely part of the validation and transformation.

Four lines of code, each leading to a different function that performs its responsibility. Each function completely testable. Each function correctly constrained, either by its types or its contracts or both.

Even I can hold four lines of code in my head.

You still shouldn't interrupt me.  Those four lines describe specific issues that I do have to hold in my head.  They're easily spec'd, and easily written, but they still require a lot of thought.  By realizing that all programming comes down to these four steps, and that every program is actually an amalgam of several different sequences of these four steps, I've been allowed to think one step higher.  But I'm still thinking at the limit of my ability, so don't interrupt.