Be careful of the large selection bias there: you're looking at the 20-30 year old code good enough not to have been replaced 18-28 years ago.

Survivorship bias, to be precise.

So what's a good example of the code of today that will survive the next 30 years?

Get back to me ... in 30 years.

> Code written 20-30 years ago almost always looks cleaner to me than the code I'm working on today :(

You aren't looking at the average workaday C program from that era. I guarantee you that OpenSSL, for example, does not look cleaner than code of today.

No incentive beyond personal satisfaction these days. Most people write and jump ship, which is so sad.

Many people don't have the luxury of write and jump ship. The vast majority of my career was not greenfield development. It has almost all been maintaining pre-existing software. Some of which is more than a decade old.

The challenging part of us in the software maintenance job is to balance a need to refactor with a need to add features. It colors your opinion about a lot of things. You start to evaluate methodologies, technologies, frameworks, and even library choices by their impact on long term maintainability.

I frequently find myself at odds with a primarily greenfield developer in tool choice because I'm looking forward into the future and it doesn't look pretty.

Greenfield developers look at me funny when I say we should just use Spring or .net for new projects. I actually have to maintain my projects for years, and I've been burnt many times before.

+1 for industrial-strength solutions.

I came to the same conclusion and for most projects there's not really a lot of good choices there outside of those two.