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.
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.
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.
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.
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).
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
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.
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.
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 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.
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 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.
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?
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.
