If there's one thing in here that I wish I could drill into every programmer's head, it's that abstractions are longer-lived than details. So few programmers seem to understand how important abstractions are.
According to the Antipatterns book, only 1 in 5 programmers "get" abstraction, which roughly matches my quarter century experience in the real world.
A corollary of this is that absent really good hiring practices, "democratic" design processes are doomed to fail, since the non-abstractionists invariably out vote the ones who get it.
This is a fascinating comment. As someone who thinks he gets abstraction I'd love to hear some real world examples on the off chance I'm deluded. How do we know if we're actually non-abstractionists?
Pretty much by definition you'd have to be told by an abstractionist ^_^.
More usefully, look at some APIs that have earned serious respect, especially by people who clearly are abstractionists. If you don't "get" too many of the reasons why, then you probably aren't (yet) an abstractionist.
This also applies to languages and idioms in them. If you grok SICP, you're probably an abstractionist (if you don't, I wouldn't say you necessarily aren't one).
The best self-test, and it's eerie when it happens, is that you design a greenfield (new) architecture and start building it, and then discover that it solves problems you didn't realize you had. I suspect this requires a fair degree of experience: it happened to me in the mid-90s, having stared programming in 1978 ... although maybe I got a taste of it in 1992. But it might have happened earlier if I'd had a chance to do a greenfields project earlier.
Some facility with abstract math is a good sign, e.g. can you do pure algebraic manipulation, especially outside the context of solving a real world problem?
Do you get told frequently that your ideas are far too complex? This is probably the biggest sign that you're an abstractionist (or at least are more of one than your team). One thing that I've found helpful is learning to translate "that's too complex" into "I don't understand you", unless it's provided with a very clear explanation of why it's too complex.
Once you learn to do that, it becomes much easier to tell if you actually understand something they don't or if your ideas are genuinely really complex.
A corollary of this is that absent really good hiring practices, "democratic" design processes are doomed to fail, since the non-abstractionists invariably out vote the ones who get it.