This may be an idiosyncrasy, but I doubt it, because I see too many examples of it in open-source code all the time: I have this strong suspicion that software developers think too holistically. There's even a rather trenchant and famous cartoon illustrating how a developer loses context with a simple interruption and has to rebuild the scaffolding of his thoughts before he can fix the issue.

I had this problem recently. I've been noodling with a small lisp interpreter that I was building as an exercise, and one of my steps was to write a lisp-like "cons" list library, recodify each node from a record-in-a-vector to lists-in-lists, and then build upward from there. My target language was Coffeescript. There are three major components to the interpreter: an eval() function, the environment, and the syntax.

Special forms are injected into the environment at initialization time, and obviously both the "define function" and "if" statements need to be able to call eval() to evaluate their arguments, since this is an interpreter that works its way to the bottom of the AST and then evaluates upward to a final result.

As I was making the changes, I got terribly lost making the special forms respond to cons lists rather than vectors or dictionaries. The structure of a node from the reader became (type value blame), where a value would be a cons list of nodes when type became "list". The distinction between the two types became muddled in my head, and I kept worrying about what it would mean to switch to the other phase of processing.

And then I realized: I should stop worrying. Everything I needed really was right before my eyes. Knowing the code in front of me, I could easily reason about everything I was doing right then, right there. This data structure would get handed off eventually, but I shouldn't care. There shouldn't be context above and beyond what's on the screen.

I think this is why I'm really starting to like F# and Haskell and that family of languages so much. (And Lisp, really); I shouldn't have to think that hard, I shouldn't be spending every day at the utter limit of my human understanding just to get my job done. I know, that's the holy grail of development, yet I'm convinced that it's not only a reachable goal, it's one we perversely avoid. We're proud to plumb code through multiple layers when we ought to be ashamed of it.

I think we ought to consider the baseball bat as a unit of code quality: if the code is so hard to understand the next guy will want to come after you with a baseball bat, maybe you should consider re-writing it.