Why you would want to program at fifty (or any other age)

He has been there and done it all: punch cards, assembly, VB6, managed a development team and worked for 20 years as a Project Manager.

He told me a few weeks ago that he never wants to retire. Work less - sure - but he doesn't want to stop. And with an ability like his, he won't need to.

In 30 years, when I'm 62, I want to be like him :)

The problem older programmers face is that the world as-is still defines engineering as a subordinate role, and people know from experience that it usually ends badly when an older person has a younger boss. Maybe it "shouldn't matter" in some PC fiction world, but in the real world we actually inhabit where people are primates, it matters a lot.

Just as tall women and short men are "diagonalized out" by being contrary to society's expectations regarding height in coupling-- there are much more politically incorrect diagonalizations in dating, but I'll side-step them-- young people don't often get to manage (even if they could) and old people are disqualified for subordinate roles. The business world invented advisory positions for this purpose (the semi-retired older employee is effectively non-subordinate, because he doesn't need the job to retain an income, but isn't a full-time executive). That's how it finds a use for active older people who are ineligible (often because they just don't want it) for full-time executive positions but have extremely valuable experience and relationships. Advisory positions keep skilled older people from being diagonalized out by the traditional subordination model.

What's needed to fix this problem is for engineering to become closer to an advisory relationship than a subordinate one. If engineers had the level of autonomy seen at places like Github and Valve, age wouldn't be nearly as much of an issue. Right now, people look at a 55-year-old code monkey as a chump-- he's that old and he's still taking orders? But there is absolutely no reason why a 55-year-old can't program; it's the subordinate context rather than the work that is the problem.

C isn't horrible at all. I'm one of those guys who find beauty in simplicity, so I consider C a very beautiful language. It's simple, efficient and extremely powerful. It's easy to learn but hard to master. All in all it's really all I look for in a programming language.

What I find particularly great about writing C code is that it keeps reminding me that programming is really a craft. I'm exaggerating a bit, but it feels like putting together something step by step, taking care of all the details, much like a clockmaker would, to produce an end result that works really well. Sure, it is probably more demanding than more modern languages but to me it's more rewarding as well.

History repeats itself.

Full screen apps, to me are a throw back to the 80's (before Windows and the Mac); and "Cloud Services" sounds awfully like time sharing to me; Centralized access point for distributed data reminds me of running apps on the old mainframes; Time Machine - real time TMS (backing up to tape in real time) - the list goes on and on.

All the kids thinking they invented new ways to share and use data. I feel like I'm knocking on a door reminding them that none of this is new. It's just been re-branded.