America's 10 Least Stressful Jobs includes Programming & Software Engineering.(newsfeed.time.com)
newsfeed.time.com
America's 10 Least Stressful Jobs includes Programming & Software Engineering.
http://newsfeed.time.com/2011/05/09/overworked-make-a-leap-to-americas-10-least-stressful-jobs/
18 comments
Programming isn't really a stressful activity. However, bad management can make anything stressful.
I have to agree. We get paid very well to play on computers all day; something most of us would be doing anyways. Don't confuse this with the job of running a startup though.
Less stressful...? Let's see...
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...
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...
This describes most knowledge workers--attorneys, architects, designers, etc. However, the field of software is so new and complex that developers are held to a lower standard. For example, an attorney's supervisor knows exactly what is being worked on and how long it should take. Software, in contrast, is a black box that affords a number of excuses.
Knowledge work is rarely low-stress. Further, I'd argue that because the field is so new and complex, that's exactly what makes it stressful. (as well as exciting!)
The main sources of stress in computer related jobs:
- 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.
- 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.
«Dealing with failure scenarios (everything's down and won't come back up)»
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.
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.
"This is avoidable, if you do your job well."
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.
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.
Failures are only avoidable if everyone does their job well. I have occasionally been called in the middle of the night because my peers put out something that wasn't really tested (and either I was more reachable or they were at a loss) or because a machine fell over that wasn't monitored as well as we thought.
Software Engineering for an advertising agency gets pretty stressful. It pays well and it's fun usually but crazy demands from clients that account and project managers don't push back on, constantly getting the creative for sites late and not being able to push back the development schedule, etc. I would describe my job as frantic.
Maybe I'm being pedantic, but if you can describe your job as "frantic" then I don't think you're Engineering anything. Sounds more like it's being hacked together and rushed out the door as soon as possible.
I've been in pdenya's situation before. It is very much a hack, and it lacks any Engineering period.
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 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.
What exactly is the difference between being a Software Engineer and a Computer Programmer?
I'd like to see this explained too. Usually they are interchangeable, but when I see them together I assume by programmer they mean code monkey.
Yes - me too - especially when everybody in the finance & insurance world calls us all 'IT' regardless of occupation.
The actual list: http://www.careercast.com/jobs-rated/10-least-stressful-jobs...
I wonder how their "stress rank" is calculated...
I wonder how their "stress rank" is calculated...
If they don't mention their methodologies than it's safe to say there isn't much science going on here, just an exercise in getting traffic and links.
It's interesting that in that list, "software engineer" has a very good "hiring outlook rank" (5 of 200) whereas "computer programmer" has a relatively poor one (168 of 200).
I hate to think what my anxiety levels would be with a legitimately stressful job.
I love hacking, but consulting is another matter.
I love hacking, but consulting is another matter.
For how it was ranked:
http://www.careercast.com/jobs-rated/2011-jobs-rated-methodo...
Software Engineering? Really? As an ex-IBM employee I beg to differ!
Don't get me wrong, I love to hack. At the end of the day, it all depends on how your employer treats you.
Don't get me wrong, I love to hack. At the end of the day, it all depends on how your employer treats you.
Not just how your employers treats you but also how much you care about your job. They can shout and scream and tell you to work weekends but if you don't care then you can, at least partially, insulate yourself from that stress.
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
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
Mathematician falls into the 10 least stressful jobs (at #8) after years of also being in the 10 best jobs in America (at #2):
http://ti.me/ivYEZr
http://on.wsj.com/g7MTWh
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.
http://ti.me/ivYEZr
http://on.wsj.com/g7MTWh
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.
I am an audiologist who programs for a living (audio-stuff, obviously). I guess that must make me a really relaxed personality. Only I don't live in the US. Oh well.
And from what I understand, audio programming typically involves fairly heavy mathematics (also on the list).
To a certain extend, yes. But then again, it is not so much about mathematic accuracy as it is about 'sounding good'. Many of the most successful audio effect devices have really meager processors. Careful tuning of simple algorithms is often more productive than crazy mathematical forays.
(This is kind of the same thing that applies to Openoffice and MS Office: OOo is not really technically any worse than MSO, but MSO just has the nicer presets and that makes all the difference).
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.
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.
Any job that makes it easy to take work home, and/or has real customers, and/or involves several teams that you might block can be very stressful if you let it.
I work 12+ hour days. I am constantly harassed to fix things 'now'. A companies future rests on my ability to do all of this.
How is this not stressful?
How is this not stressful?
I know that there are semantic differences between "Software Engineer" and "Computer Programmer", but they seem really insignificant to me. I'm curious how they differentiate the two. How does HN differentiate them?
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.
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.
For the most part, the general public doesn't differentiate. Within the industry, the common expectation is that "Engineering" means that some sort of repeatable process is being applied to control the quality of the output.
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.
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.
In Canada, part of the distinction is that Software Engineers are real (with a ring) engineers. A lot of their education is in engineering principles - same classes as Electrical, Mechanical and Computer engineers.
I know in the states Software Engineer describes most developers. How many Twitter engineers are actual engineers? Exactly.
I know in the states Software Engineer describes most developers. How many Twitter engineers are actual engineers? Exactly.
Does that mean Canadian software engineers are required to study stuff like statics and dynamics and metallurgy, wasting time on mechanical failure modes that are utterly irrelevant in software?
Yes to statics and dynamics.
some googling came up with these links:
http://stackoverflow.com/questions/27516/whats-the-differenc...
http://en.wikipedia.org/wiki/Programmer
http://stackoverflow.com/questions/27516/whats-the-differenc...
http://en.wikipedia.org/wiki/Programmer
I think the long and short of it is that in some countries, there's a significant difference, in the US there's not -- at least not a significant difference that's well-known/understood. The fact that they appear as different professions in a time magazine poll is a bit absurd.
The criteria for this are pretty terrible in terms of defining mental stress. I'd be far more interested in a study that looked at actual stress as evidenced by medical conditions and tied it back to careers, rather than a set of arbitrary categories that are chosen base on a perceived link to stress.
Philosopher is a job? Surely it's a university research post, at least if you're not willing to live in poverty like Socrates, or are independently wealthy like Thoreau [later in life].
If a university pays you to do the same things as you would do on your free time, and what you would do on your free time could be considered original philosophy, then yes, it would be the job of "philosopher". There's also philosophers like Stefan Molyneux who make their money from books/donations/speaking engagements.
Is this a joke