Nate Meyvis

He said that discussion of design patterns is a good sign someone is junior. Well, maybe using the literal phrase "design patterns" suggests a certain professional immaturity, but no way do less advanced programmers think about patterns more! [6/N]

One very crude sign that someone is a bit more advanced in the discipline of programming is simply knowing that patterns exist--that (in Koppel's phrase) the logical level of code exists and that you'll make a mess of it if you don't think clearly. [7/N]

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]