There is a sort of stress that comes from a "slow-paced environment" where you've got a 50% or less duty cycle of doing real work because you're always waiting for somebody else to do something. Too little work can be just as stressful as too much.
This. Hurry up and wait. That's exactly how it worked for me when I worked for a large company. Need to make a database change? Be prepared to wait 3 weeks unless you can get someone several levels above you on the org chart to take notice. Same for any kind of additional access you might need, or to provision any amount of computing or network resources...
One company I worked for had the same problem - because the (Oracle) database was also linked to their payment system and because they were a big company, the simplest change would require 2 or 3 weeks of approvals (by law, not really their fault).
And you know what my department did?
We've managed to setup our own database servers, so changes became independent of any payment system and could be done on the spot.
I know things suck in corporations, but sometimes it's your fault for not doing anything about it.
Heh, I work in IT and have some users like that. They're pretty smug until they realize it takes us a while to set up any infrastructure because we do little things like, umm, backups, which they don't have, and now suddenly really, really need... Oops.
This isn't about devs versus ops. It's about bureaucracy versus getting shit done. If it takes 3 weeks to ensure reliable infrastructure and backup, I wouldn't complain.
All I was saying is that if you have to wait 3 weeks for the simplest schema change request (which I saw it happens in big corporations), then you should take charge and workaround it before throwing your hands in the air ... sometimes management listens.
This is fine as long as you actually understand what it is you're working around, why it's there, and what the consequences are of working around it. What looks like bureaucracy to a technologist may well be there for a very good business reason.
Sometimes there's a tree across the road simply because a tree fell across the road. But other times there's a tree across the road to keep you from plummeting into the ravine where the washed-out bridge used to be.
Oh yeah, if it's broken, fix it, I don't meant tech but organisationally. Just pointing out that there's often more work that goes into databases than endusers see.
At every job I've ever had, in the interview I have mentioned that I'd rather have 10 hours of work to squeeze into an 8 hour day than have 2 hours of work to expand into an 8 hour day. Thus far, nobody has taken me seriously.
Weirdly enough, I find that fast-paced and slow-paced can be combined into an annoying hybrid I'll just call "unpaced." An unpaced organization has a hurry-up-and-wait mentality about decisionmaking, but once a decision has been made -- inevitably, right before a big delivery deadline has come and gone -- everyone is sent into an unnecessary crunch mode: the aptly named "fire drill."
Nine times out of ten, if you're at a company with a lot of fire drills, it's because somebody a few levels above you isn't managing timelines appropriately, or some folks at that level just aren't talking to each other. Point is, the "fast-paced" moments are usually symptoms of a deeper issue.
Especially when your employer watches your every move every second you're in their building. Cameras, remote desktops on every PC, services that track what files you open and when, keyloggers, et cetera. Not having enough work in such a paranoid environment where you get griped at for doing anything outside of your responsibilities or for not being in the building exactly eight hours a day can be a living hell.
I'm in a situation like that currently, but in an open plan office, with a manager sitting behind me keeping me in line.
And since our bug tracker is linked to timesheets, things like refactoring don't happen anymore, unless linked to a specific feature/bug (developers can't create these). The nett effect is that things that used to take me 2 hours now take 8 hours, so I can fill the day. Parkinson's law is not a joke.
Just pretend you're at Google and you have a 20% project you work on. Or learn you some iPhone/'roid programming so you can earn some $ on the side.
Or manage your investment protfolio.
Robert Kiosaki (of Rich Dad/Poor Dad fame) in one of his books gives a couple of examples of people who became millionaires while working for the man and collecting mediocre paychecks. Both were in jobs with plenty of downtime or waiting around for other people. One was a fireman who would read the financial news/stock reports looking for bargain stocks, the other was (I think) working for the Postal Service and he would spend his 20% time looking for real estate bargains.
Alternately, you could start preparing now for your next job.
I worked one time for a boss that I really didn't see eye to eye with (his behaviour included being intoxicated at work to give you an idea). The company had done some semi-disastrous change over of an old reliable minicomputer that customers would access directly via modem to some new fangled dodgy and unreliable web based system. So to punish me for not sucking up to my boss, I got stuck in another building with no computer and had to take phone calls of people complaining bitterly about this. Basically our script boiled down to figuring out which browser they had, and then walking them through the upgrade to the latest version, and if that didn't fix whatever problem they were having, there wasn't anything we could do.
I was, of course, mortally offended. Tech support? The lowest of the low? the janitors of IT? ptooiee
But at the time I was reading through 7 habits and got to the bit about the guy in the concentration camp who decided that the only person that could decide whether he was unhappy was himself.
Anyway, that humbled me a bit. Tech support might not be glamourous, but it's certainly no death machine.
So I decided to enjoy it, even though I had to deal with angry people who had nothing to do. During the downtime I worked on adventures for Shadowrun or AD&D or something like that, basically just doodling. It filled up the time pretty fast. When someone angry would call I would empathise with them a lot more (which calms them down really quick), and I'd be apologetic that they'd been put in that situation by my company.
Eventually my evil ex-boss figured out that I was actually enjoying the tech support. So he took me off it, and gave me nothing to do. So then what I did was I took to wandering around, asking other people how they were doing, helping other programmers debug their code (there's something semi-magical about sitting down at the code they've been banging their head against and then indenting their code properly... half the time they suddenly see the problem, the other half the time it gives you time to figure out what the problem is but to them it looks like you find the problem instantaneously :D )
I'd also put my hand up for any work in obscure and dreadful old languages, things Man Was Not meant To Know. you know, like COBOL or C++ :D In a sufficiently large and sufficiently old organisation there's a surprising amount of that stuff lurking in the background that desperately needs maintenance.
This also happens in those implementations of Agile where they try to pretend that programmers are all easily interchangeable cogs in a machine. The problem is, anybody they get who is better than average or has some natural talent is going to be bored out of their tree.
What I would do, is start picking future cards and then when they come up give ridiculously low estimates for them (because they were already finished on my machine :D ).
"Oh, you want a persistence layer for all this? Okay, that will take... -17 minutes."
Or, alternately, if I didn't want to bend people's minds or break the wills of the junior programmers (messing with the jps is half the fun of these sorts of things :D ), I'd work on some technical debt, since Agile projects tend to accumulate it faster than a sophmore with Daddy's credit card.
