Ageism

A short while ago I dropped a line to the always thoughtful Rad to let him know of my changed circumstances since he might be interested in talking about some tech things, and he sent me back this interesting link on the ageist culture in technology companies.

There are a fair number of comments posted, showing near-unanimous agreement that a) this particular phenomenon is very real (and I don't doubt it for a moment), and that b) the suggestion that we more seasoned folk should enter management or sales-type roles is both insulting and impractical (which is certainly how I find it).

Like a number of those commenters, I'm now in my mid-40's and as I'm supposed to be writing a CV or resume or some such thing (having never had to bother before) I've found myself puzzled by the problem of explaining all the things I've done over the past 30 years in terms a modern employer might understand, given that most of them are either going to go well over their heads, or be thought of as obsolete (which is of course utter nonsense - having written a TCP/IP stack and the OS it lived in isn't diminished by the fact that the 68000 processor it targeted is now a museum piece, since the understanding and insight that comes from having that experience never goes away).

This is one of the big differences between merely having read of something and having done it: a potted summary, even a reasonably deep one, can really only cover the topmost layer of engineering decisions that go into any substantial piece of technology. However, when you're creating an entire large ecosystem from scratch without relying on others, there are a myriad small details that you have to get right, many of which are actually related to deep engineering problems you'll encounter again and again.

The same thing also applies in spades to the "snap-together" programming culture which is utterly dominant today. Modern developers appear to simply be uninterested in learning the inner workings of the artifacts they are throwing together, and are equally unconcerned that the results of their labour are huge, slow, and inflexible.

There are a lot of articles I intend to write on the beauty of the small - an engineering virtue on many levels from the practical to the aesthetic - but one of the best things about there being no mysteries is that you can fix anything. In the computer systems I use, there is simply nothing that I couldn't write for myself; I've done text editors, compilers, interpreters, GUI widgets, OS kernels, all from the ground up. Not all of them were as pretty as you see today, mind you, being constrained by the hardware at the time and by the fact modern commercial systems have been polished to a fine sheen by the labour of thousands, but in functional terms there are no important secrets at any level of the software stack.

That understanding confers some real power, because as a consequence you are never constrained at all to colour within the lines. If you have a problem, it's possible to take things apart and fix them. It's one thing to make a hard-headed economic decision to build or buy, another entirely to be unable to build software to get from A to B unless someone has already done it before.