Nate Meyvis

Yes, there's a lot of extremely bad applications of design patterns out there. There are also a lot of bad splints and bandages, but you'd be foolish not to know the theory and work with reference materials to hand. [8/N]

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]