Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on 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."

2 of 149 comments (clear)

  1. I was most frustrated by ... by Maxo-Texas · · Score: 2, Informative

    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.

    --
    She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    1. Re:I was most frustrated by ... by Gorobei · · Score: 3, Informative

      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.