"fast-paced environment" says more about the people than the environment...
Let's say, for example, that your environment changes at rate "10".
If you normally move at rate "7", this environment would seem fast-paced to you.
But if you're accustomed to moving at rate "15", you wouldn't even consider it to be fast-paced.
In my experience, what most junior and enterprise programmers would consider "fast-paced" would seem fairly normal to most senior or start-up programmers. It's all relative.
I don't know about that. Consider someone working in a sandwich shop. Once you learn how to make the different sandwiches, you just keep making the sandwiches every day. Or a job as a taster at a distillery. You make sure the whiskey doesn't vary in taste. While it may be an enjoyable activity, there's only occasionally something new.
Whereas with coding virtually everything is something new. In coding if you run into the same thing over and over again, you use a reusable component or automate it. You build the equivalent of a sandwich-making machine or whiskey-tasting machine and move on to the next thing.
"In coding if you run into the same thing over and over again, you use a reusable component or automate it."
You and I both know this to be true, but there are wide swaths of development jobs that cater to the C players they've hired and don't allow this sort of automation. Frameworks, more powerful languages and tools, even techniques like recursion aren't allowed because "not everyone would understand them." There's plenty of reasons to not like Rails, or Ruby for that matter, but "because Joe Blub three cubes over might not get it" is one of the worst ones you could give.
That sort of environment sucks, and everyone on here is right to say "if you're in that sort of place, then quit!". That said, it does exist in wide enough circulation that it's hard to sweep it under the rug when talking about the industry as a whole.
Really? I read quite a lot opinions (articles, blog posts, comments) from IT people and haven't really found anyone expressing such a blanket statement.
Even the complaints about spec changes are seldom about changes per se, but rather about the impedance mismatch between the changes and an inflexible process.
Only unexpected change is undesirable. The reason that all change is met with the same hostility is due to the processes set up to document the changes that are wanted.
You know what fast-paced is - ideas thrown at you that invalidate your previous architecture once every 2 weeks. And I don't know how you can get any more fast-paced than that.
If I hadn't enough experience to make the architecture flexible enough or to do unit-tests or to choose the right moment to start from scratch, I would probably go mad.
Let's say, for example, that your environment changes at rate "10".
If you normally move at rate "7", this environment would seem fast-paced to you.
But if you're accustomed to moving at rate "15", you wouldn't even consider it to be fast-paced.
In my experience, what most junior and enterprise programmers would consider "fast-paced" would seem fairly normal to most senior or start-up programmers. It's all relative.