Career planning: Where do old devs go to?

Eeek. What is an old dev? :-)

Who is older: a) programming commercially since age 20, currently 35 (15 yrs full-time experience) b) programming commercially since age 35, currently 40 (5 yrs full-time experience...)

Once your arms and fingers start giving out (or eyestrain), people start feeling old really fast. Doesn't matter how old you are. Take care of your health (including keeping your brain active on interesting projects...) and you'll stay "young".

This is probably what you are thinking of: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html (It was linked to in the comments of the blog post.)

It'd be fun to ponder all the deeper causes and consequences, but for some reason I simply find myself agreeing with Poul-Henning Kamp:

"So asking where we are is the wrong question.

"You should be asking what it would take for us to become fired up about your company?

"For one thing, you'd have to be within commuting distance, because we're not going to uproot our family and ditch our real-estate investments for some random job anymore, in particular not now that the lawn and roses are finally starting to look nice.

"Telecommuting is fine, but it wouldn't be the same for your company, would it ? You wouldn't have a genuine graybeard to berate and lecture all the young ones around the office.

"And I doubt you can muster at set of 'benefits' which can motivate us, what we'd probably like most of all would be to work fewer hours not more."

(Agreeing with Poul-Henning Kemp? God help me!)

Another commenter pointed to a post by Robert Martin[1], with the following quote:

"...what caught my attention was the shape of the age distribution in the first graph. If this graph is correct, then most programmers are under 28. Most programmers have less than 6 years experience!"

Which seems entirely true to me. Unfortunately, I'm significantly less optimistic than Uncle Bob:

"One seasoned programmer in their 40s can have a profound effect on a team of a dozen or so twenty-somethings. As a leader, that programmer can teach the team about principles, patterns, practices, and ethics...."

Mostly because it seems impossible to lead those 20-something programmers. Most of them seem to have a project or two behind them (mostly unsuccessful, but that hardly matters) and they know everything. As a result, it's not so much a question of leadership than one of beating them into submission every time a new question comes up.

To quote me:

"Ok, X works, we've done X successfully for a while, several people around here are familiar with X. Let's use X."

"Sure, we'll look at X'," quoth they.

Then, "X' is too hard; we can't get it to work," when they come back.

"So, X?"

"No, Y is the new hotness, let's use Y."

[1] http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

I'm spectacularly bad at keeping up with previous co-workers. I'll certainly admit to that---it's one of my "listen to my advice, what I'd do, and then do something completely different" points.

But then, I spent 8 years at one job and in grad school. Anyone I knew before that would be really hard to find even if they could be a useful network.

And I was really bad at connecting with my committee--I graduated, but without a good network there.

Then I moved across the country.

I've never had any problem finding work, if I shop my resume around to local contractors and "body shops". In fact, I've made a pretty good career out of that. But "exciting" work? Not so much.

At this point, I'm considering getting out of the field. And I love what I do. I just hate what I'm doing, if you can see the difference.

Engineering is about applying heuristics and rules to solve problems. You build a bridge in one way one time, then you build a similar bridge elsewhere in a very similar manner. The same thing happens in software, but only in the boring areas. Software is far more varied, and far more interesting. But most of the interesting parts are under the hood or otherwise invisible (such as the mechanics of actually making the software, which generally not a standardized process).

Imagine if software was physically manifested and somehow translated into familiar aspects of life. Going to buy a car you wouldn't see a lineup of several incrementally different models from different companies, instead you'd see: a bicycle; a tank; a bamboo framed solar powered moped held together by duct tape; a rocketship; a jet pack; a houseboat on top of an enormous tracked crawler; and a pair of rollerskates (both for the left foot). Also, half of them are free, a quarter of them can be bought for cash, and the remaining quarter cost tens of thousands of dollars per unit and can only be purchased through very elaborate contract negotiations (and there's no rhyme nor reason which is which, because the rocketship is actually free, and the rollerskates is one of the crazy expensive ones).

That's software, and that's just a tiny pocket of it. The entire software industry is basically fractally weird in the same fashion, but on a much larger scale. It's commonplace for some metrics to differ between direct competitors by not just percentage points but by orders of magnitude. It's also commonplace for competing products to offer entirely different paradigms of use. Imagine considering buying one of two different hammers, one of which is an ordinary hammer, while the other somehow submerges and infuses your surroundings in a bubble of liquid glue 1 light year in radius, then rapidly cures just the portion of glue you want to cause two things to stick together, then instantly vacuums up the uncured glue remaining in the bubble. That's the scale and weirdness of differences between SQL and NoSQL, or between systems built on node.js and java, for example. But we accept that as if it's normal, and the end user never really sees it. HN is a perfect example. As a user you can't really tell what HN was written in, and you can't discern a difference between its underlying structure and, say, how facebook works (except at a functional and UX level). But underneath HN is written in Arc by a tiny team and facebook is written by an army of devs on PHP and makes use of custom PHP compilers.