Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Programming Stats

Researchers Determine What Makes Software Developers Unhappy (vice.com) 149

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."
This discussion has been archived. No new comments can be posted.

Researchers Determine What Makes Software Developers Unhappy

Comments Filter:
  • 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

    • by Frosty Piss ( 770223 ) * on Sunday April 16, 2017 @03:26AM (#54243457)

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

      Because, well, you know better than the "PHBs" what the legal / business ramifications are?

      • 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.

        Good progr

      • 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 was promoted into management afte

        • 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

    • by Z00L00K ( 682162 )

      Maybe it was because the company also used SOX as an excuse to save on development costs.

      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.

      • 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.

    • by asylumx ( 881307 )
      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!
    • by Gorobei ( 127755 ) on Sunday April 16, 2017 @09:09AM (#54244433)

      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.

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

      Also, not being treated to that celebratory pizza after putting in two weeks of mandatory unpaid overtime.

      • When you get a chance to make the code sing, it's not overtime.

        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.
    • by gweihir ( 88907 )

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

      SOX is there for a reason, and the ability to just "fix it" is

      • Development coders deliver crap.

        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.

        So it was poorly running code dumped by developers and proposed fixe

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

    • libertardian?
  • Don't let people who don't know fuck all about coding think they're qualified to manage software projects.

    • by coats ( 1068 )
      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

    • by gweihir ( 88907 )

      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

  • by BinBoy ( 164798 ) on Sunday April 16, 2017 @03:34AM (#54243483) Homepage

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

    • A statistician with his head in an oven and his feet in a freezer says, âoeOn average, I feel fine.â

      I think that is the perfect analogy for software. Sometimes you are facing what seems like an utterly insoluble problem, with people breathing down your neck for a solution... so much stress.

      But then more often than not, you work past the problem, and all is well. It's a huge feeling of accomplishment.

      Honestly it's what I like about working with software. A profession that offered more minimal h

    • You can add to that list:

      Programmers who don't like programming and only got into to it because of the money.
  • Users (Score:5, Funny)

    by allo ( 1728082 ) on Sunday April 16, 2017 @04:09AM (#54243569)

    Users

    • Re: (Score:3, Funny)

      by Chad Smith ( 3448823 )
      Sales Staff
    • 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.
  • by Lorens ( 597774 )

    Getting spammed with inane surveys makes me unhappy.

  • by 93 Escort Wagon ( 326346 ) on Sunday April 16, 2017 @04:47AM (#54243667)

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

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

      I wonder if the underlying purpose of this is to try to understand why women aren't interested in becoming programmers?

      We have to face it, for most people of either sex, programming doesn't radiate money, glamour, satisfaction or respect. You don't become a programmer for any of those reasons.

    • by Anonymous Coward

      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

  • Wait... (Score:4, Funny)

    by meglon ( 1001833 ) on Sunday April 16, 2017 @04:54AM (#54243687)
    Running out of Mountain Dew wasn't top on the list? I call bullshit.
    • Running out of Mountain Dew wasn't top on the list? I call bullshit.

      You had to go there - now I'll have nightmares all week.

  • by petes_PoV ( 912422 ) on Sunday April 16, 2017 @05:24AM (#54243741)

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

    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.

    • 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

    • by Kjella ( 173770 )

      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 bet having head shaved by researchers and electrodes embedded in brain, came pretty high on the list?

  • by Anonymous Coward

    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.

  • by DeplorableCodeMonkey ( 4828467 ) on Sunday April 16, 2017 @05:47AM (#54243805)

    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.

    • Yeah - locked-down stuff can be funny. I am allowed to use Chrome, but can't install plugins, so can't install the "be like IE" plugin, so internal web pages like SharePoint don't work.
      But my favorite is that our systems are locked to not allow executables on USB drives. Ok, whatever, but... Windows installers apparently want to dump the install packages onto the drive with the most free space (dumb idea, really). I've got a IT-approved terabyte USB drive permanently mounted for data storage. You guess

    • 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 "

  • by wonkey_monkey ( 2592601 ) on Sunday April 16, 2017 @06:24AM (#54243861) Homepage

    What makes developers unhappy is bloody researchers coming to the door with their surveys.

  • by Anonymous Coward

    Figuring out how to get unstuck is part of the fun.

    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.

    • by Ihlosi ( 895663 )
      Only solution for the under-performing colleague problem

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

      Having more underperfoming colleagues vastly increases your chances of getting ranked higher and therefore bigger raises.

  • Let's me see some of the stuff that annoys me

    Not being given the tools I need to do my job.

    Being blown off when I try to get them to do more basic stuff like source control and release management.(Oh we don't need to do that, we're fine.)

    Working under a manager where you seriously begin to wonder if they're literally a psychopath.(Hasn't happened much to me but there's been one or two where I started to wonder.)

  • 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.

    People smugly nouning verbs makes me unhappy.

  • by chispito ( 1870390 ) on Sunday April 16, 2017 @09:40AM (#54244597)
    I wonder if the happiest developers were the under-performing coworkers? (The Wallies [wikipedia.org].)
  • 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.
    • by hvdh ( 1447205 )

      Right, having to use ClearCase immediately came to my mind when reading the title. But finally, we're migrating to git later this year.

  • n/t

  • 80% of the problems of unhappiness are caused by other people:

    * Lack of communication from upper management
    * Excessive communication from upper management
    * Over (Micro) management
    * Under management
    * Unrealistic schedules
    * Unrealistic features usually promised by Marketing / Sales
    * Lack of Design
    * Over-engineered design
    * Constant interruptions
    * Meetings that drag on
    * Excessive meetings
    * Hardware bugs
    * No authority to make changes
    * Lack of Quality Assurance
    * Excessive Quality Assurance
    * Lack of ergonomic hard

  • 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.

    Honestly, me no get 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.
  • From the paper:

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

Technology is dominated by those who manage what they do not understand.

Working...