Posted
by
EditorDavid
on Sunday April 16, 2017 @03:50AM
from the spaces-instead-of-tabs dept.

Researchers recently surveyed 2,200 software developers to calculate the distribution of unhappiness throughout the profession, and to identify its top causes, "incorporating a psychometrically validated instrument for measuring (un)happiness." An anonymous reader quotes Motherboard:
Daniel Graziotin and his team found their survey subjects via GitHub. Contact information was found by mining archived data for past public GitHub events, where email addresses are apparently more plentiful. They wound up with 33,200 records containing developer locations, contact information, and employers. They took a random sampling from this dataset and wound up with about 1,300 valid survey responses... According to survey results released earlier this month, software developers are on average a "slightly happy" group of workers...

Survey responses were scored according to the SPANE-B metric, a standard tool used in psychology to assess "affect," defined as total negative feelings subtracted from total positive feelings. It ranges from -24 to 24. The mean score found in the developer happiness survey was 9.05. Slightly happy. The minimum was -16, while the maximum was 24. So, even in the worst cases, employees weren't totally miserable, whereas in the best cases employees weren't miserable at all.
The paper -- titled "On the Unhappiness of Software Developers" -- found that the top cause of unhappiness was being stuck while solving a problem, followed by "time pressure," bad code quality/coding practices, and "under-performing colleague."

And since happiness has been linked to productivity, the researchers write that "Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job...unhappiness is present, caused by various factors and some of them could easily be prevented."

Being blocked from doing small fixes by Sarbanes-Oxley and management. But really Sarbanes Oxley.

Prior to SOX, I could see a problem- fix it, refactor the code.. etc. or see a minor improvement- implement it, refactor the code, etc.

After SOX, I had to run everything thru the team lead who had to justify it to the manager who had to justify to the director who had to justify it to the senior director who had to justify it to the Department head, who had to justify it (in a group of other changes) to the CI

I don't think it's that simple. Typically what happens is business needs something in a short period of time in order to exploit an opportunity, but then development needs time to return the code to a well ordered state rather than the hacky (albeit working) mess left after the rush-job is delivered. Typically your average PHB has no clue what they are asking for in terms of human effort and often even the dev team don't appreciate the full extent of the impact of a change to the system like this.

Oh sure. I'd been coding for 32 years at that point, knew multiple languages and I understood the benefits of refactoring code and incremental improvement. Because of Sox requirements management only went for high cost, higher risk features with higher payoffs. This often resulted in programming resources literally sitting around doing nothing rather than making small incremental fixes and improvements which on an annual basis would greatly exceed the approved changes.

I read your posts for awhile. I assume you love in Texas which I now do. Outside of Houston you can get another job next week! Not all are Sarbanes Oxley shops. Even in Houston there are a few.coms and desire to have a senior level programmer or manager.

You owe to yourself and your wife if you are married to be happy and have a positive attitude and confidence vibe men are expected to have. A bad job impacts all around you and yourself and as Dave Ramsey says in his famous youtube video if you're spirit ha

I live and love in Texas. I saw how age discrimination went in computer science back in the early 80's before age discrimination protections were gutted in 2009.

So I saved hard and I've been retired for several years now. The only programming I do is for fun (star fleet battles, minecraft, noodling).

The last employer was only cheap in some ways. As I said, they dropped about 1.5 billion on a failed SAP implementation. As implemented at the company the CEO and CIO were legally responsible for changes so

Sure I could have done that- but as a low level manager (promoted after SOX), that would have made no difference unless i was assigned to a project to work on our controls and procedures. Complaining about the procedures beyond simple grousing would simply get you on the shit list as having a bad attitude.

What about having to do tedious and redundant work because leadership refuses to prioritize internal tooling and environment upgrades,

What about it? Life sucks. Shit sucks. You either settle and collect your paycheck, or you go to another company. Not all companies are like what you describe, so why do stay where you don't like working? Stop being a bitch. Stop complaining and change to a company that you like working for.

Have non-technicians constantly reject good ideas because they can't understand them, and don't bother trying to,

Being asked to work extra to meet arbitrary deadlines that have absolutely nothing motivating them,

Re-doing the same task three times because the stakeholders cannot make up their minds,

having to work in an open office that is full of noise, socializing, and distracting all the goddamn time while leadership just closes their office doors?

I don't know whether or not you would call these "pressing issues," but they sure make MY job suck.

Same bitching. No one owns you a dream job. Go out and seek it. Life is too short to be bitching about bad employers.

What about having to do tedious and redundant work because leadership refuses to prioritize internal tooling and environment upgrades,

What about it? Life sucks. Shit sucks. You either settle and collect your paycheck, or you go to another company. Not all companies are like what you describe, so why do stay where you don't like working? Stop being a bitch. Stop complaining and change to a company that you like working for.

Have non-technicians constantly reject good ideas because they can't understand them, and don't bother trying to,

Being asked to work extra to meet arbitrary deadlines that have absolutely nothing motivating them,

Re-doing the same task three times because the stakeholders cannot make up their minds,

having to work in an open office that is full of noise, socializing, and distracting all the goddamn time while leadership just closes their office doors?

I don't know whether or not you would call these "pressing issues," but they sure make MY job suck.

Same bitching. No one owns you a dream job. Go out and seek it. Life is too short to be bitching about bad employers.

Hey that is me! Or was me.

I left my last job and couldn't be happier. I learned something too? You can try to re-adjust your attitude in such a situation but it only goes so far. Eventually you will get fired too on top of it as you will break and no one wants to do business with someone with a bad attitude.

I used to listen to some motivational speakers. Larry Winget who has a book called it is work for a reason argues passion = bad employees and we all should not love our jobs. I think now that advice is b

Thank you. I was beginning to think I was the only one who felt this way.

No. You are not the only one who feels this way. The question is, are you the type that complains and complains and complains, but never ditches the bad job? Or are you the type who looks for what he wants in a job?

Pre-Sox, you could refactor code and if it had the same outputs for the same inputs, you were fine unless there was a major failure in production (which happened about 20x more often for new development than it did for maintenance and 20x more often for existing code getting a new unexpected condition or data that killed it.

And for larger changes, you could get approval from your team lead- who might mention it to the manager. If they were good then that was it.

Corporations indeed more and more resemble communist countries. Nobody gives a shit about the corporation, everyone's trying to find out how to abuse company resources for personal gain, which leads to corporate spending more and more resources on internal surveillance, eventually to the point where the surveillance costs more than the corruption did, but that's ok because it can be planned. You have incompetent people being promoted so they can do less damage to the production process, because you can't fi

Damn man. All I can say is QUIT. I refuse to do the bare minimum. If I try everything and adjust my attitude as it is always the workers fault with an attitude problem when you try to fix it then I start looking for an exit.

I left my last employer and starting a path for a newer and so far seems much better one. I get paid more but it is a step down in responsibilities and title but it is more technology present wise which will help my resume and I feel a sense of calm as stress lifts away.

Almost completely true. But if there was any change noted (even if not a problem) then it was a firing offense. After a couple people got burned, everyone else just gave up.

It's like when they tried to go to SAP. Many of us could see the way they were approaching it was doomed and actually - probably literally impossible. After two people firmly fought against it and said it was very likely to fail and were fired, everyone else just shut up and did their jobs and after 18 glorious months of design they

Imagine the impact if the company was reviewed and then it was revealed that a fix for a security problem wasn't put in place due to the process.

Bureaucracies don't work that way. There are almost never negative consequences for inaction, especially if the proposal was never explicitly rejected. If someone comes to you with a proposal, you just bury it in some file drawer, or pass the decision (and blame) on to someone else.

I totally agree with the parent -- I also have the 'luxury' of being in a FDA regulated field so there even if your systems aren't in SOX scope, they are often still in FDA scope which is just as bad. Then you have overzealous compliance folks who think every system is somehow within SOX or FDA scope, who make the situation even worse!

Being blocked from doing small fixes by Sarbanes-Oxley and management. But really Sarbanes Oxley.

Prior to SOX, I could see a problem- fix it, refactor the code.. etc. or see a minor improvement- implement it, refactor the code, etc.

After SOX, I had to run everything thru the team lead who had to justify it to the manager who had to justify to the director who had to justify it to the senior director who had to justify it to the Department head, who had to justify it (in a group of other changes) to the CIO.

SOX dictates policy, not process. Nothing in SOX requires the process your company has chosen to implement. SOX basically says: do whatever the fuck you want, but it had better be understandable and sane; if you fail at that, but claim you are compliant, we can jail your senior management.

If you are lucky enough to be working for a good company, you hardly notice SOX. If your company sucks, well, senior management doesn't want to get jailed, so they make a process of hierarchical justifications that is understandable, sane, and stupid: they keep their jobs and stay out of jail.

There were many years pre-sox where I would work 2-3 hours into the night polishing the code on my "own" time because it was fun and I enjoyed the beauty and elegance that resulted. And, it was a dream to maintain later on company time.

SOX was a big thing when I did help desk support at Intuit in 2005-07. All approvals for VPN accounts went from being informal (checking supervisor's approval email attached to ticket) to formal (checking approval chain in Oracle). After I left Intuit, it became less of a big deal. The last time SOX got mentioned to me was during a job interview at pre-IPO bio tech company in 2014.

Ah yes, I recently fixed a bug that causes higher-than-needed effort in error handling for a hard to reproduce error case. I am still explaining to them that they cannot really test the fix with reasonable effort with their testing set-up.

Being blocked from doing small fixes by Sarbanes-Oxley and management. But really Sarbanes Oxley.

Prior to SOX, I could see a problem- fix it, refactor the code.. etc. or see a minor improvement- implement it, refactor the code, etc.

After SOX, I had to run everything thru the team lead who had to justify it to the manager who had to justify to the director who had to justify it to the senior director who had to justify it to the Department head, who had to justify it (in a group of other changes) to the CIO.

Just the overhead meant that something which would make the code 2% better was blocked many times per year. Not worth the ROI.

And the overhead meant that improvements to the code which would make future maintenance easier were never approved any more. So the code just got harder to maintain over time.

The time constraints would also be important. I didn't really care about co-workers performance. That was between them and management.

If SOX gets in your way to fix shit so much that makes you unhappy, there is something wrong with you, you wild cowboy you (or with the organization you work for, or both.) I've worked in SOX-bound companies, and that never really got in the way to get shit done. You simply become more organized. I mean gee, what's bad about firewalling root access to production and knowing what hands touches what (which is at the root of SOX in terms of IT.)?

Then maintenance programmers actually have to support it- potentially for years.

It made me unhappy to go from an environment where I could make code more efficient and elegant to an environment where a 1 letter change to the code which wasn't signed off by all levels of management was a firing offense.

We went thru about a 6 month period when sox first came out when we almost couldn't get anything done at all.

SOX and OFAC are just government mandated job programs, forcing companies to add staff.

I've been in insurance since the 1990s, went to school to be an actuary (I chose to pass Go, collect $200, and went into IT immediately after graduation; passed 5 of the exams in college though - different system of exams now).

Maintenance programmers fix the bugs in that code and should also be able to make it easier to maintain.

I managed both development and maintenance teams and I was a maintenance programmer at heart from the first code I took over in the early 1980s.

The original rule was no one can touch the program INVTUP. After they grew confident in my abilities, they let me make a series of changes to the program that didn't change functionality but which did improve le

Even worse: people who think they know everything but in fact know only bad ways of doing things, and who are too arrogant to take correction.

Example: EPA's CMAQ air quality model. The first requirement is that this model support regulatory application: in particular, it must maintain adequate chain of custody of its own data to stand up in court; silent data corruption is completely unacceptable. However, one of the primary developers NEVER checks the status of operations that may fail -- e.g., MPI

Usual situation is fuckups on both sides. True, management is often pretty bad, but so are coders. I am somebody that sometimes gets called in to help when this happens.

I mean, for example web developers that put all their stuff in the top level directory in an enterprise landscape and hence make any kind of mixed-application proxying impossible? Or people that parse an URL (because they thought it was a neat way to get parameters) that comes from another application and goes to a third one and that that sh

> software developers are on average a "slightly happy" group of workers...

As the old saying goes... A statistician with his head in an oven and his feet in a freezer says, “On average, I feel fine.”

Overly complicated, bloated frameworks, lack of documentation, buggy tools and incompatibilities make life miserable. Learning something new, finishing a project your proud of or raising your skill to a new level feels great. It would be nice to eliminate the lows though.

P seems to be the largest group behind S and C. Don't let your happy little code experiences be thwarted by one or two rotten eggs;)

Postscript, Powershell and Python are very well known. But... did you know there is a Prolog interpreter written for.NET CLI called P#? Pizza likes a cup of Java on the side and there seems to be an entire family of PLs. And apparently, in the 80's, VM/CMS (currently z/VM) didn't have pipes built into t

No, just under-performing. I am one of those that does not write any code before thinking about the problem. I may go weeks without even opening a prorgamming tool. Just staring blankly at my computer, thinking. For any slightly complex project, I am about 10 faster, ignoring my reduced number of bugs and higher performance.

A more recent projects was one that I had already done in the past. I spent about two weeks working on it. Around 4 days thinking and 6 days coding and testing. It was a high performan

Ah, yes, _those_. Another field they excel in is identifying "(web application) implementation worst practices" and then using them extensively. Many coders seem to struggle getting it to work at all and have not grasped any of the finer points that are so all-important. They are about as useful as a person that has figured out how to get to the other side of the road, but has never understood that there are little things like looking for and avoiding traffic and quite often even has failed to understand th

Fearing concurrency is irrational. Difficult to reason about concurrency when you're in an irrational state of mind. The ability to quickly debug concurrency issues separates cargo-cult from programmers, because understanding concurrency requires understanding of the code. I will agree that working in poorly designed concurrent code is a major headache.

I like my current job. My domain includes 80,000+ workstations and NO USERS. Except for the power users who can figure out who scheduled an after hours reboot on their system and complain to their management that I was on their workstation. It does them no good to complain as policy backs me up. I sometimes wished I could replace their workstation with a box of crayons.

You would be amazed at how easy help desk or desktop support would be without users getting in the way.

Oh, not even bothering to write another post to lie.

I get accused of being a liar a lot. But the people who take the time to look into my "lies" are often surprised that I'm telling the truth.

Your job is to support them, not be a lying ass.

My job is support 80,000+ workstations. I no longer work in help desk or desktop support. The only consideration I'm obligated towards users is to avoid rebooting their workstation during business hours.

These researchers who keep asking me if I'm happy are making it hard for me to focus on getting my work done...

I once was on a team that saw a slew of exoduses to other parts of the company, for a myriad of reasons. We, as software engineers do, had lots of complaints. Process, no forward thinking, managers rather than leaders, etc, etc. At one point they brought out the HR people to "help us" *shudders quietly*. The consensus of that is that we would complain less in the future, since we didn't want their "help" anymore.

I'm actually with a different group in the company now, and the problems I saw before if any

In my experience what makes developers unhappy is having to write documentation, perform testing and fixing bugs.

Well, that attitude makes me sad. I'm never satisfied until I've written a man page or help file detailed enough that a new user can understand how to use the tools without any difficulty. Fixing bugs? There's no such thing as "being a programmer" if you don't fix bugs. You're not a car manufacturer if you don't fix obvious system failures before going into production.No, what makes me sad is asking a colleague for the script he wrote that automates some task, and discovering that there's not a single l

> In my experience what makes developers unhappy is having to write documentation, perform testing and fixing bugs.

I suspect those are factors that make _poor_ developers unhappy. For good developers, and admins, many of us find writing good documentation to be an invaluable tool that helps people actually use our work. For those of us who've come back to a project after 3, 5, or even 15 years, it's invaluable. For me, the act of documenting helps me think about why I'm making certain choices, and provid

In my experience what makes developers unhappy is having to write documentation, perform testing and fixing bugs. Of course, that might simply define the habits of the "under-performing colleague" that then drags down the happiness of other, more diligent and professional, developers.

Depends on whether you think "make working code" should be on a list of developers' priorities or not. In a bad workplace what you list are code words for "explain the code so I don't need to make any effort to understand" and "please clean up my hacky semi-functional spaghetti code mess". Here's usually how my day goes, I got my things to do and my deadlines to keep. Then someone requests a change, said developer assigned essentially says "I got no clue on how do to this so I'm estimating a week or two" an

What makes me unhappy is not to test, is to ask me to mix 3 jobs : being a thorough tester, a full time job, and a thorough programmer, and a thorough business analyst again both full time job. Sorry guys, I can do 1 very good, 2 passable,and 3 badly. Or I will give you estimate which will shock you.

I've seen my share of managers who seem to think people can't be serious about their work if they are having a good time. I suspect this is linked to a strong protestant christian influence on the culture of my country. It's frustrating, it makes them actively fight something that (to me) obviously boosts productivity.

The single biggest gripe would be "forced to use the same super-locked down image from IT that is given to management, secretaries and marketing, but expected to 'build great stuff'." Seriously, while I've worked with some very smart IT people, I'd say that the majority of IT is no more knowledgeable about infosec than the average developer and even frequently less knowledgeable.

All developers remember bad IT interactions and forget the good ones. The VPN portal is rock solid and gives a nice throughput of 5 Gbps, "yeah, sure, great". IT showed up with replacement headphones for skype calls the same afternoon. "Good ok, big deal". It ran bit9 that killed the build process randomly, "these IT nitwits never do anything right..."

IT forgets all the developers who do it by the book and cause no trouble. But that developer who used to the root of some CFD lab in grad school 20 years ago

"I'd say that the majority of IT is no more knowledgeable about infosec than the average developer and even frequently less knowledgeable."

Like some developers I have worked with in the past, who insist that the application user must have write access to the Java keystore? Why? Because they wrote code to import the SSL cert of any host they connect to as a trusted cert to the keystore, because they couldn't figure out how to import the CA cert with keytool (but found random java code on stackexchange that "

Making a great gadget and having it come to nothing due to marketing.Also having the project direction jerked around for no good reason.Schedules are pretty high on the bad list.Silly lack of resources where the cost of not having them is higher than having them.Captain Obvious required training to satisfy a legal (often SOX or EEOC) checkoff box is only annoying.Dilbert-like clueless bosses are not always a problem, sometimes they are another problem to fi

Only solution for the under-performing colleague problem is acceptance of different skill and engagement levels. It's very hard to deal with it, but people knowing how to accept and live with it is the only solution.The alternative is giving you better colleagues, but then you might start upsetting them. In any group there will be under-performers.

What problem? I'd love some underperforming colleagues, since the yearly ranking is on a relative scale (or rather - the distribution is forced, e.g. 50% of all people need to be ranked "average", 20% good, 10% superior, etc).

Survey responses were scored according to the SPANE-B metric, a standard tool used in psychology to assess "affect," defined as total negative feelings subtracted from total positive feelings. It ranges from -24 to 24.

While the results are interesting, they are likely biased due to the source of the survey respondents being GitHub users. I would assume that GitHub users lean toward the open source world. While I like the open source world, it does not represent the whole of software developers. There are lots of developers that work on proprietary software and or projects that are not allowed to use cloud based (like GitHub) repositories and tools.

If you are a software developer working for a company that is not a software shop, your life is pretty much compromise. You have to build applications and systems that often seem repetitive, within timeframes where you are pretty much forced to cut corners. Usuall the cut corners are in in testing/documentation if you are lucky, but sometimes you miss in functionality and stability. Yes, you can refuse to cut corners and quit (or be fired), but this may not be a near-term option for people supporting fam

Actually, my father taught high school for 21 years and became miserable. He finally quit (which was a good thing) and went and did something he enjoyed--making signs.

Now, he had a family to help support. So if someone needed a sign, he made them a sign. He'd suggest ideas, try to steer them in the direction he wanted to go, but ultimately, the money was what was important. So if they wanted a square painted sign, he'd give them a square painted sign and charge them for it. He got so that he could whip

The paper -- titled "On the Unhappiness of Software Developers" -- found that the top cause of unhappiness was being stuck while solving a problem, followed by "time pressure," bad code quality/coding practices, and "under-performing colleague."

Isn't that the whole nature of software. Any challenging work worth doing is going to get you blocked at some point or another, and it is one of the reasons we get paid well (compared to other professions.) If shit were easy, we would never get blocked. And then it would be the type of work anyone could do it.

One of the annoyances I have are seasoned developers who don't want to learn. There isn't a lot of benefit from experience if you don't take advantage of language constructs if they didn't exist in FORTRAN.

“
I feel negative when I get really stuck on something
and cannot get around it
”. Another respondent elaborated: “
I also
thought of situations where I’m debugging some issue with the code
and I can’t figure out why it isn’t working – when it seems like ev-
erything should work, but it just doesn’t. This is definitely one of the
biggest gumption traps I encounter
”.

While I've definitely encountered these situations, these are some of the best learning experiences. In fact, the whole task of problem solving is why you should be in this field. If you wanted an easy job with simple step by step procedures that will always work, find a different field. If you want to just write an algorithm and not deal with implementation quirks, go in to a more theoretical area.

In fact, the whole list is a whine fest about anything that anyone in any job has to deal with

Software developers know when they are productive, and being productive means being happy. If they are unproductive because they have to wrestle with stubborn tools, hardware, management, processes, etc, then of course they are unhappy.

I have one at work and am forced to work with him. He spends all day giving sidelong glances at my screen and I've caught him announcing things to people in a way that it makes it look like he's the originator of the thought.

Upper management changing specs on you, with no change in schedules. And, of course, they created the schedules, while having no idea that programming doesn't mean moving a mouse around for a few minutes and voila, there it is.

Then there's the environment... like the infamy of "open plan offices", so that managers can walk around and see if you're working (which they can tell by seeing you typing).