Nate Meyvis

It is simply not easy to see a given software problem as an instance of a type of problem, to which various established patterns might give a solution. And in some contexts you can make working, maintainable code without explicitly thinking in these terms. [9/N]

But if you're trying to do something tough and/or big and/or unwieldy and you aren't thinking in terms of interfaces and design--not "system design" in the narrow sense of "what database do I use," but (again) the high-level logic of your code--you'll get smoked. [10/N]

"I need a new thing to happen. Do I make it happen here or there?" Very often, if you put it in the right place, six months later you'll be doing O(n) work (where n is some natural unit of "stuff happening in your system"), but O(n^2) if you get it wrong. [12/N]

That's reductive, certainly not always true. But many mistakes amount to subtle duplications that mean that you need to check two things against each other when one thing should be handling it all. Usually that means a linear -> quadratic penalty. [13/N]

And--the devil is a busy man--these tend not to take the form of nested for loops, which means that it can require a keen eye even to perceive that this quadratic work is happening. (And you'll probably be having to reason about code that's all over the place.) [14/N]

And if you fix the downstream problem the wrong way, you're only going to compound the issue. And this is why "average time to 'fix' a bug" is a pretty bad metric by which to distinguish levels of programmer, too: [15/N]

Someone who's "fixing" a problem by bashing in some glue and tape in the first obvious place, but making an interface worse, might do so quickly but at huge technical cost. (See John Ousterhout on "tactical tornados.") [16/N]