America's 10 Least Stressful Jobs includes Programming & Software Engineering.
newsfeed.time.com
newsfeed.time.com
Burning your brain all day to solve problems that are usually underspecified, while having to meet deadlines set by people that don't have much of a clue of what it really means to program, to satisfy users which don't know exactly what they want, and wouldn't like it even if you gave it to them.
Yeah, what's to be stressed about...
- Dealing with failure scenarios (everything's down and won't come back up)
- External time pressure (This needed to be done yesterday)
- Dealing with human issues (payment, expectations of work, etc.)
Some bits of programming/SE are high on certain forms of this - for example in the service provider world, it's often #1, whereas game development is high on #2 (and #1 if it's an online game).
But for the most part, programming is somewhat stress free.
This is avoidable, if you do your job well.
«External time pressure (This needed to be done yesterday)»
This tends to get worse if you do your job well. Do something in a month once, and get asked to do it in a week the next...
«Dealing with human issues (payment, expectations of work, etc.)»
Every problem is a people problem. Between the users complaining, co-workers blocking your work and management putting impossible deadlines.
That's awfully snarky. And I doubt many developers have the authority to overcome systems issues. Even if it were possible to compensate programmatically, it may justifiably count against you if you assume the authority to invest the additional time to turn a working delivery into a super-resilient-never-goes-down delivery.
Either way, it's generally a management decision developers don't have the authority to make.
I was at a shop that didn't pay their employees well and enticed them with big projects for big clients - really neat work in many cases. A lot of people working there were young and ambitious (ie new grads,) but they didn't stand up for themselves. The result is that inexperienced developers run projects that go over time and over budget, which results in lots of overtime (unpaid, because you're on salary) which leads to extremely high employee turnover.
It's huge short term thinking, and I suggested as much when I left. But I'm sure management has that figured out and they've found a model that produces decent work and keeps the clients happy, so why change? Buggy code = more time charging out maintenance projects.
I wonder how their "stress rank" is calculated...
I love hacking, but consulting is another matter.
Don't get me wrong, I love to hack. At the end of the day, it all depends on how your employer treats you.
For me, the worse stress is the pointless, boring nature of the job. That's a much bigger life stress than someone fretting over a Sev1 defect and telling me to work weekends
Both lists also contain Software Engineers. Does that mean math majors (esp. computer oriented ones) should take more software engineering classes? SE helped me (although I was surprised how much), I encounter Use Cases and Requirements on a daily basis here. I majored in Computational Mathematics.
That said, you are often limited by available processing power and micro-optimizations can be important. Calculating dozens of filters for dozens of channels on one DSP can be quite a challenge and getting that right algorithmically makes a big difference.
How is this not stressful?
I've always just thought of "Software Engineer" as someone who takes their profession more seriously, but it is more of a self-applied label than anything else.
http://stackoverflow.com/questions/27516/whats-the-differenc...
I know in the states Software Engineer describes most developers. How many Twitter engineers are actual engineers? Exactly.
In real life what that should mean is that at every step of the life cycle, you know what has to be done next, or you know where to look it up.
Customer reports a bug on release 12.4.1 of the software? There's a procedure that says what you do to record it, how to decide if it's a bug; how to decide if/when it's fixed, etc.
Boss asks why the customer saw the bug if he's spending so much money on extra testers? You have output documents that show the Test Plan for that release, the results of all Test Cases that were run. You can show that the reason no test cases found the bug is that the customer was working in an area that had no real requirements, so was never properly designed, so the designs weren't reviewed and the code was just the programmer's best guess and since there was no requirement, the testers didn't think to test that area.
How do you keep it from happening again? Your process has some kind of Continuous Improvement baked in so you can capture mistakes made and fix the procedures that caused them. Lather, rinse, repeat, automate.
That's Engineering in a very small nutshell. Most shops can't be bothered, but for an increasing percentage, it makes sense.