[Dewie]

I haven't even programmed for five years, but it seems like if I get into the industry, all the fabled "rapid change" in the industry seems to mostly be about learning new ways of doing conceptually old stuff, with most of the learning being new API's, slightly different syntax and all the gotchas and corner-cases that come with these new tools.

Maybe there will be some new (to the industry) programming paradigms, but from the reception that functional concepts have gotten from a lot of people, there seems to be a large amount of seasoned programmers that seem pretty displeased at the idea of having to learn stuff that is actually for the most part new to them.

[gav]

A large part of the "rapid change" is people re-inventing things or re-writing things in a hipper language.

I feel that a lot of this comes from unrealistic scaling expectations; stop worrying about serving Facebook-like traffic and use tried-and-tested tools.

[Shorel]

The idea is to use technologies that old bureaucrats can't understand, in order to avoid bureaucracy from creeping into the project.

If you have ever been in a project with some higher up dictating some technology because the corporate vendor is good at his job, but said technology is awful for the project, and you have no say about it, that's what the 'rapid change' tries to avoid.

For example: using Oracle for a small DB.

[robodale]

This. It's the old new thing.