Actually, at the end of the day, I feel sorry for the XYZ developers- those who know one thing, and only one, no matter how well. Because sooner or later, and generally sooner, that one thing becomes irrelevant and obsolete. Well, at least for the things XYZ developers generally specialize in- being an expert in graph theory or linear algebra isn’t going to be obsoleted any time soon.

I knew a guy, once, who was an expert Windows developer- knew damned near everything there was to know about Windows… 3.1. He’d already had the unpleasant experience of losing jobs to people with 1/5th his experience, simply because they were experienced in Windows 95, and he wasn’t. You see the exact same problem in nature- species that over specialize generally die out, it’s the generalists who can adapt to a wide variety of climates and conditions that have the real longevity. For the exact same reason. Unlike in nature, where the same conditions can hold for geological amounts of time, in the realm of computers the analogical equivalent of massive climate change happens on about a 10-time frame.

So how do you be an adapter, not an over specializer? How do you survive when the whatever it is you so carefully learned gets left on the side of the road for something new and completely different? Well, first, know more than one thing. And always be learning something new. And second, concentrate on learning those things that don’t change- which effectively means, learn the theory.

Anyway, just a slight ramble there. The “XYZ developer vs developer who knows XYZ” distinction is *huge* and sadly one that is hard for many people to make.

Joel Klein said:

The cliched answer I know is that after 5-10 years the people with the domain knowledge get promoted to managers and tech leads and no longer write code.

Let’s think about this for a moment. There are two problems with this. First problem- this works only if each new generation of programmers is signficantly larger than all the ones previous to it. Think about it. Over, say, a fourty year long career, you spend, let’s be generous, 20 years doing “real work” and 20 years as a manager. If each generation of programmers is only as large as the one previous to it, that means half your people are now managers. If you only spend 10 years programming, 3 out of 4 are managers. At 5 years programming, 7 out of 8 are managers. Talk about too many chiefs and not enough indians. In the fifties, sixties, seventies, even the eighties, we could get away with this- because there were many more young programmers than there were old programmers. But the “promote to management” idea works a lot like a Ponzi scheme- once you stop getting enough new blood in, it collapses.

Second problem- you’re assuming that everyone who is good as programmer would be good as a manager. I, for example, would suck at being a manager, and it’s not something I’d enjoy doing. So, one of my career goals is to never be a manager (team lead, maybe. No higher).

My $.02 - companies always seem to want the “Top 1%”, CS-degree graduate “rockstars”.

My experience is that companies that ask for “rock stars” or “ninjas” or “gurus” are basically trying to be hip and authentic¹, and they generally fail at it. Worse, I’ve found recruiters using those words as ways to entice people into thinking it’s a prestigious position, and therefore you should lower your rates for the opportunity to work at such an incredible place.

As a rule, I don’t apply for any contract that uses those words anymore.

¹See The Cluetrain Manifesto for a reason as to why. The book also features a sidebar rant from some loud-mouth named Brian Hurt which is worth reading anyway.

Are 99% of these companies building compilers, facial recognition software, AI engines or a better bubblesort? No — it would seem that a large chunk of a CS-graduate hired developer’s day has little to nothing to do with “CS-stuff”.

Sadly (or is it?), CRUD rules the day if your customer accesses your product through a browser. And desktop Java or C# applications? The difficult part of the job is almost always about nailing down requirements, getting the UI right, shuffling data back and forth, etc.

Rarely does a programmer, at least from my experience, need to dust off their copy of:
http://www.icpc-bolivia.edu.bo/books/intro_algorithms.jpg

+1 — There are some pretty impressive business stunts pulled to accomplish exactly this (see my comment above). A lot of businesses want technicians, not developers: they don’t want people who design cars, they want people to work the assembly lines and fix them up. See my post The Programmer is Dead: Long Live the Technician! for more on that.

The cliched answer I know is that after 5-10 years the people with the domain knowledge get promoted to managers and tech leads and no longer write code. The cheaper fresh graduates do the grunt work and if necessary learn the new technology. Those who don’t care to get promoted because they want to keep coding learn the new tech, and I think those who don’t learn the domain knowledge are not invited to be promoted. I don’t know if this is what you mean by Business. I’ve seen this born out at tech companies with environments of largish teams (100-300 developers) making huge systems of end-user products. The complexity of these systems required lots of domain knowledge.