Nate Meyvis

Closely relatedly, you get better at figuring out precisely what objects your system should be defining, and what the interfaces to those objects should be. I find it useful to factor this into aspects having to do with (i) conceptual knowledge and (ii) discipline. [4/N]

Re: (i), there's an arsenal of techniques for dealing with any given problem (e.g., "it sure seems like I have two things here, each of which should depend on the other"). Lots and lots can be said about this. Here I'll just register emphatic disagreement with @marcoarment: [5/N]

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]

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]

And if I fix a problem the wrong way, I'm likely to be the one best positioned to fix the downstream problem four times as fast as you--because of a hyper-local knowledge gap I created through my mistakes. Getting this kind of thing right is super-hard... [17/N]

...and it requires not only knowledge but *discipline* (see (ii) waaaay up a ways in this thread). It can be tough to not just throw in an extra parameter on a function, to split one object into two when it's called for, and so on. [18/N]

Anyway, why don't I do poker software? Because, basically, this stuff is what I care about, and the comparative advantage one should have to do poker software is (basically) something different. [19/N]

I like math, and I like learning about optimizations that help with numerical stuff, and game theory is cool. But, basically, I should leave software that relies heavily on that sort of thing to folks like @ivan_bezdomny. [20/N]