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

85 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 Frosty+Piss · · Score: 4, Insightful

      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?

      --
      If you want news from today, you have to come back tomorrow.
    2. Re:I was most frustrated by ... by Z00L00K · · Score: 2

      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.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    3. Re:I was most frustrated by ... by asylumx · · Score: 2

      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!

    4. Re:I was most frustrated by ... by knightghost · · Score: 5, Insightful

      I've worked at multiple USA and Canadian companies that followed SOX and SAS 70 but never had any of those problems. It's the corporation, not SOX.

      The responses of "unhappiness" is something you'd see from newbies, so I strongly question the data set. Far more pressing issues are age bigotry, politics, PHBs, and outsourcing.

    5. Re:I was most frustrated by ... by ShanghaiBill · · Score: 1

      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.

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

    7. Re:I was most frustrated by ... by Opportunist · · Score: 1

      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 fire them since they know something that would cause trouble if the west, I mean, the competition would know. Working hard only gets you more work and a disgruntled set of coworkers who blame you for higher expectations from management, so the general consensus is to work the bare minimum to not get sent to Gulag, I mean, to not get fired...

      Yes, they have a lot in common...

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
    8. Re:I was most frustrated by ... by Applehu+Akbar · · Score: 1

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

    9. Re:I was most frustrated by ... by aethelrick · · Score: 1

      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 programmers continually fix and improve code as they work on it. Usually compensating for weaker team mates, refactoring as they go, improving overall maintainability without spending vast amounts of time. Micromanage these good programmers at your peril, you'll just frustrate them and reduce the quality of your product, making it harder and harder to get those quick changes your business values so much.

    10. Re:I was most frustrated by ... by __aaclcg7560 · · Score: 1

      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.

    11. Re:I was most frustrated by ... by gweihir · · Score: 1

      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.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    12. Re:I was most frustrated by ... by luis_a_espinal · · Score: 1

      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 not necessarily an indication of good software engineering practices.

    13. Re:I was most frustrated by ... by luis_a_espinal · · Score: 3, Insightful

      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.

    14. Re: I was most frustrated by ... by luis_a_espinal · · Score: 1

      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?

    15. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      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 after that and supported small changes and we benefited from the few I managed to get approved.

      So sure- it frustrated me that a 24% to 36% annual improvement was blocked.

      Instead of getting a total 50%+ annual improvement we only got three to four 5% improvements (and of course new features).
       

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    16. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      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.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    17. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      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 fixes which could never get thru the process to be approved and customers screaming because of the buggy code the developers delivered.

      If you saw bad code which you knew was causing a problem but wasn't an outright bug- then you couldn't fix it any more. And you could before. And it was hard to maintain. And it was ugly. And it often performed worse which meant you couldn't implement features the business DID desire later because the hardware was fully loaded by crappy code.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    18. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      Exactly.

      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.

      And then there was another scale for senior directors.

      AFTER Sox- everything had to be approved by everyone up to the CIO- and tho I had no visibility to it, I'm pretty sure there was a CIO/CEO meeting too because ultimately the CEO's job was at stake.

      So the cost overhead for changes was so high that small changes could no longer be approved.

      And at first it was horrific. We had change meetings where 290 projects would come in and then only 60-70 would be approved in the 90 minute meeting and *that was it* for the week. You had to come back next week. But #71 wasn't #1 next time. Nope- it might be #41 or even #85 if higher priority projects got ahead of it. And after missing 6 change meetings, you missed the release. And that was it for three months. And at the same time, the people blocking you were screaming at your managers to get the medium priority projects approved and about low priority projects when that particular 13 million dollar customer called in upset that their problem wasn't being addressed.

      it was very unpleasant.. and it made me unhappy.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    19. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      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 started rolling it out and it utterly failed when it was under 7% rolled out and had to be rolled back. Last I heard the cost was at least 1.5 billion dollars.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    20. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      Age wasn't a problem for me. I saw it in 1980 when I was starting and saved accordingly. Retired early.

      It's a problem for those who think you can work to 67 as a coder. It happens but probably to under 10%.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    21. Re:I was most frustrated by ... by Billly+Gates · · Score: 1

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

      It is frustrating and sometimes not everyone is a gifted programmer in the I.T. field who can get a job next week. It took months and a termination after I blew up after working 70 hours a week for several months and undoing everything I did and redoing it over and over and over and an abusive coworker who bullied me for an hour and a half.

      But I can say I should of left a year earlier and a great employer can make or break your happiness in a heart beat. I am proud I stuck by bad jobs enough to gain experience so I can get to the good companies. Picking employers comes for non high demand people after you have 3 to 5 years proving yourself and going up the chain to be worthy of their time.

      I agree. Like a relationship if you are not happy and you try to work out changing and your partner won't budge or appreciate you it is now time to pack your bags and move on. I guess a working relationship is similar to a romantic one in that regards.

      --
      http://saveie6.com/
    22. Re:I was most frustrated by ... by Billly+Gates · · Score: 1

      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 has left your workplace for heavens sake take your body with it ... QUIT!

      I am not in management but I will say in the 20 seconds reading this that your employer is cheap and risk adverse. If the CIO is important then why is he auditing and approving changes?? Hire a freaking auditor/editor/technical reviewer who can deal with that shit instead! If your employer doesn't want to pay then its penny wise dollar dumb to waste you and everyone's time. SOX is for proper business decisions not auditing. Your employer is not freaking liabile if a coder puts in a backdoor and your legal team over-reacting big time if that is the logic on this??

      --
      http://saveie6.com/
    23. Re:I was most frustrated by ... by Billly+Gates · · Score: 1

      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.

      Not all employers are like that but I have observed the ones that are typically are yesterday companies that were hot back in the day and are losing money, talent, and resources to competitors with clueless PHBs and senior management left. When a company puts in surveillance and redtape and meetings to prevent problems and refused to listen do not walk away RUN! Many of these companies start outsourcing in the end of their death cycle and view employees as cheap commodities.

      They wonder what happened to the drive and talent of yesteryears? The answer is THEY LEFT with their former customers to greener pastures.

      Smaller companies too have more flexibility if that is what you want. Nothing is perfect man, but like a bad romantic relationship, a bad employment one is equally bad for you.

      --
      http://saveie6.com/
    24. Re:I was most frustrated by ... by turp182 · · Score: 1

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

      --
      BlameBillCosby.com
    25. Re:I was most frustrated by ... by Ryanrule · · Score: 1

      libertardian?

    26. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      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 they wanted assurances about every change from someone. We also had auditors who reviewed a about 2% of the changes every quarter and confirmed the process was being followed.

      As I indicated, there simply wasn't enough time to approve everything for quite a while after Sox came out. We went 6 months where it was a real night mare and getting approvals was tight for another year or so. And then sap came along and consumed even more bandwidth (despite statements it wouldn't occur, there was a lot of bidirectional double development in the old and new system... and in the new and old system.).

      If a coder made a change without approval- it was a firing offense. You could gamble and risk it I suppose but it wasn't worth the risk.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    27. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      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.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
    28. Re:I was most frustrated by ... by Maxo-Texas · · Score: 1

      Developers deliver kludged, hacked up, cowboy code.

      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 legibility and maintainability. It took about 15 months but at the end I'd reduced the program from over 30,000 lines of ill documented spaghetti code to about 12,000 lines of well documented, well structured code which was trivial for any programmer to maintain..

      In many cases, I've helped other programmers debug their programs- often merely by having them change the variable names to be more descriptive. Likewise, using eclipse refactoring tools to extract subroutines can turn a block of hundreds of lines of code into a dozen subroutines and a block of code that each fits on one screen.

      Once SOX came in, you could no longer do this kind of code improvement during downtime. Instead, you did nothing until something was approved. And in some cases, it was literally over a week of sitting doing nothing because you couldn't even check out the code without an approved ticket or project. And once things were approved, then you could start. And sometimes, they'd spent so long approving it, that you were very close to the point release date.

      --
      She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
  2. Summary of all future comments. by Narcocide · · Score: 1

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

    1. Re:Summary of all future comments. by coats · · Score: 1
      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 communications. Thanks to the arrogancew of this developer, there are at least 453 failures to follow this standard. IMNHO, the model is completely untrustworthy.

      And as the original systems architect for that model, that makes me VERY unhappy.

      --
      "My opinions are my own, and I've got *lots* of them!"
    2. Re:Summary of all future comments. by gweihir · · Score: 1

      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 should just opaquely pass though? Or all the instances where unprotected state goes to the client in a security-critical environment, despite the policies very explicitly prohibiting that (guess nobody looked what that nice "framework" actually did...).?

      Most coders are idiots and have no clue what they are doing.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  3. On Average I Feel Fine by BinBoy · · Score: 5, Interesting

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

    1. Re:On Average I Feel Fine by phantomfive · · Score: 1

      You can add to that list:

      Programmers who don't like programming and only got into to it because of the money.

      --
      "First they came for the slanderers and i said nothing."
  4. Users by allo · · Score: 4, Funny

    Users

    1. Re:Users by ChadSmith4920 · · Score: 3, Funny

      Sales Staff

  5. Being millennial winners! by Anonymous Coward · · Score: 1

    Software developers today are well groomed millennial hipsters who are all millionaires (at least) and swimming in pussy.

    Neckbeards are completely marginalized has-beens, are either dead or dying, and those still alive are living in poverty. No neckbeard is working in software development anywhere.

    Neckbeard stereotype is two decades out of date. Troll harder next time.

  6. Re:under-performing colleague by Anonymous Coward · · Score: 1

    You mean "old geezer who thinks before coding" instead of producing mountains of poorly conceived bug filled shit like you do. You're a fucking ageist dung beetle of a coder, aren't you.

  7. Re: Number 1 by Z00L00K · · Score: 1

    Or Pascal for that matter?

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  8. Re:It's easy by Z00L00K · · Score: 1

    Do you have any degree worth anything from Florida these days?

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  9. Spam by Lorens · · Score: 1

    Getting spammed with inane surveys makes me unhappy.

  10. What makes me unhappy by 93+Escort+Wagon · · Score: 3, Funny

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

    --
    #DeleteChrome
    1. Re:What makes me unhappy by Ol+Olsoc · · Score: 1

      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.

      --
      The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
    2. Re:What makes me unhappy by Anonymous Coward · · Score: 1

      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 anything, are worse. Sure most managers will turn a blind eye if you ignore process right and left, and will agree with you that the process sucks, but no one will officially say it is okay to ignore it, and the processes never really improve. They generally get worse, while most everyone agrees that we should fix that. Suggestions that might improve process generally die, one way or another, since they don't have a net immediate positive impact to the company bottom line, or someone points out a con, without really doing a plus minus comparison to see if something is better. For instance, not vetting every library through a process involving multiple third parties might result in malware getting in. Said process is likely to take weeks to months. We can't just trust our engineers to do their jobs and then have their back later if something goes wrong if it is found that they did exercise reasonable prudence. No, instead we keep pushing for more faster, and then silently ignore them when they do it anyway. This is insane. Basically your just setting everyone up to the point where everyone who isn't a failure has probably violated process and procedure many times and thus has many excuses on the books they could be fired for.

      Either make the processes painless (spend the money and once they work, don't randomly change them), and enforce their use, or get rid of them, but don't silently expect your employees to violate your processes to meet your goals. That kind of stuff just irritates me no end.

  11. Wait... by meglon · · Score: 3, Funny

    Running out of Mountain Dew wasn't top on the list? I call bullshit.

    --
    Fascism: An authoritarian and nationalistic right-wing system of government and social organization. See also: NAZI's
    1. Re:Wait... by Ol+Olsoc · · Score: 1

      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.

      --
      The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
  12. Anything except coding by petes_PoV · · Score: 3, Funny

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

    --
    politicians are like babies' nappies: they should both be changed regularly and for the same reasons
    1. Re:Anything except coding by cellocgw · · Score: 1

      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 line of comments in it (well, and that the dingbat hard-coded every object that should have been an input argument).

      --
      https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
    2. Re:Anything except coding by Antique+Geekmeister · · Score: 1

      > 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 provide a trail for others to avoid the same pitfalls.

      cakkegw also commented:

      > 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 line of comments in it

      What's making me sad lately is asking a project member for the tools they wrote that automate some task, finally getting them to put the tools in source control, and discovering that not only is there no documentation, the tools do not report errors, they've not been working correctly, and the tools already exist in much more stable and documented form in some open source project. It's coupled with the same engineer or group handwaving their way around the project, refusing to use stable upstream tools and instead using the latest unstable and untested tools that corrupt the original data without notice.

      I had the opportunity several years ago to review some of the code used for a major genetic analysis project. I was horrified, but unsurprised, at the lack of error checking. I was also horrified at the internal documentation that was in direct conflict with what the code actually did. I'm afraid the details are under NDA, but it was not cheap to clean it up and re-run all the analysis. I dread to think how much research money and effort the bad data analysis wsted.

    3. Re:Anything except coding by Kjella · · Score: 1

      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" and the reporter goes "so long? I was hoping it was a day's work and I need it in three", we have a chat with my manager and I do a stunt implementing the essentials before lunch. It'll still need documentation, testing and bug fixing but it'll be mostly there and that's really all the time I have to spare.

      Same often goes for bug fixing, unless it's important I've often found that the time I need to spend unraveling is better spent on creating the code I'm supposed to create. Rather than finding the one flaw in the old code, big chunks are rewritten often finding and closing undiscovered bugs in the process while enabling a cleaner structure for the future. That is, I certainly own my own messes and test/clean up my own code. But I'd rather ditch certain bug fixes on someone that I know will use 3x as long as me rather than write new code I know they'll use 10x as long to achieve with poorer results. Yeah I'm not stellar on the points above, but I don't think anyone feels I'm underperforming. At least my boss and colleagues seem to miss me when I'm not available and they're on their own.

      --
      Live today, because you never know what tomorrow brings
  13. Re:Number 1 by jiriw · · Score: 1

    That's a lot of 'unhappiness'...

    List of programming languages - section P

    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 the command line interface but there was a separate program called 'Pipelines' with its own utility programs and syntax, so you could do some similar tricks with pipes as what was available in UNIX... I learned some new things today :)

  14. The probing by Mats+Svensson · · Score: 1

    I bet having head shaved by researchers and electrodes embedded in brain, came pretty high on the list?

  15. Managers that distrust happiness by Anonymous Coward · · Score: 1

    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.

  16. Doesn't sound like most of the ones I know by DeplorableCodeMonkey · · Score: 5, Insightful

    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.

    1. Re:Doesn't sound like most of the ones I know by cellocgw · · Score: 1

      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 guessed it: usually there's more free space on that than on C: or any internal drive. Every single IT-pushed update or install fails due to their own rules. That saves me a lot of time in destroying their crapola mods to Office, screensavers, etc.

      --
      https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
    2. Re: Doesn't sound like most of the ones I know by buchanmilne · · Score: 2

      "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 "worked" because it also disabled all certificate validation)?

  17. I'll tell you what makes 'em unhappy by wonkey_monkey · · Score: 2

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

    --
    systemd is Roko's Basilisk.
  18. A less whiny list by Anonymous Coward · · Score: 1

    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 figure out how to fix.

    I have heard some complain about having to deal with 'pesky humans'?

    I've always said beer in the coke machine with an after 5 lockout and a recliner in my office would be nice.
    Come to think of it, I've seen that done. It worked, but there might have been a few more bugs.

  19. Re:under-performing colleague by Bengie · · Score: 1

    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 performance async concurrent library that could be easily reused and extended. Extending required little knowledge of concurrency as I wanted the library to be easy to use for any programmer.

    Another project came along about a year later that would have been a 100% perfect fit for my library. I could have had the project completed in 1-2 days. Instead management decided to give the project to some senior programmers, because the project was of "high priority". It was a two man team. They came to me for guidance because they were aware that I have worked on this kind of stuff before. I spent about 3-4 weeks in meetings with them, then it took about 5 months for them to complete it. In the end, there was no tests, because they didn't have time, the code was brittle, was slow, everything was hard-coded. Small requests for change would take days, where in my system, everything was just a configuration, so they changes would have taken minutes with my library.

    I got to look at their code in git. It's crazy simplistic. Loads tens of gigabytes of data into memory instead of streaming it, among other horrors. Looking at git, I could see they started coding the day they got the project.

  20. One solution for under-performing colleague by zedaroca · · Score: 1

    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.

    1. Re:One solution for under-performing colleague by Ihlosi · · Score: 1
      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.

  21. I would guess it's the standard stuff by NotSoHeavyD3 · · Score: 1
    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.)

    --
    Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
  22. I wonder about the under-performing coworker by chispito · · Score: 2

    I wonder if the happiest developers were the under-performing coworkers? (The Wallies.)

    --
    The Daddy casts sleep on the Baby. The Baby resists!
    1. Re:I wonder about the under-performing coworker by michael.karl.coleman · · Score: 1

      I wonder if some perceived "under-performing coworkers" aren't actually NPV performance leaders...

  23. Biased results by Nkwe · · Score: 1

    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.

    1. Re:Biased results by hvdh · · Score: 1

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

  24. Re: Number 1 by yurikhan · · Score: 1

    Prolog does not “do”. It just “is”.

  25. Selective memory is the reason by 140Mandak262Jamuna · · Score: 1
    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 wants to be root now and install random packages from unknown websites in his machine, or opens TCP-IP ports, reassigns UDP ports for the daemons... He will be remembered and talked about, "Do you know what that idiot did today ?..."

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
    1. Re:Selective memory is the reason by R3d+M3rcury · · Score: 1

      - My company's IT refuses to alter our company's firewall rule settings to be compatible with our company's own products. -- YES we cannot use our own products at all from our IT-issued systems!

      Hm. I'm not sure of what the firewall settings are, but perhaps you should consider making your products more flexible?

  26. You have stumbled onto the perfect analogy by SuperKendall · · Score: 1

    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 highs and lows would just be too boring I think.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  27. Null pointers by PPH · · Score: 1

    n/t

    --
    Have gnu, will travel.
  28. Summary: 80% Other People's Problems by UnknownSoldier · · Score: 1

    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 hardware
    * User Experience designers that don't know what the fuck they are doing

    The remaining 20% problems ARE things we can actually directly deal with:

    * Complexity
    * syntax/compile bugs
    * run-time bugs -- such as logic bugs, not handling exceptions such as Out of Memory, Out of Disk Space

    In the 40 years I've been programming Programming Languages, like fads, come and go.
    The one thing that is constant is that this list hasn't changed.

    --
    JavaShit, noun, a brain-dead programming language hacked together in 10 days by a moron where you are forced to use magic numbers like:

    "use strict";

    1. Re:Summary: 80% Other People's Problems by phantomfive · · Score: 1

      Complexity is what makes me happy.

      --
      "First they came for the slanderers and i said nothing."
  29. Re:under-performing colleague by gweihir · · Score: 1

    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 that they should find out beforehand whether there is actually a need to get to the other side of the road.

    --
    Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  30. Re:What makes me really unhappy by Bengie · · Score: 1

    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.

  31. Parallels? by Carcass666 · · Score: 1

    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 families, medical challenges, etc.

    Which got me wondering, what if you are an artist and find yourself painting repetitive lake and seafront landscapes, Venitian canal scenes, and the other sort of stuff you see in the Home Goods art aisle? I'm sure these artists are having to pump out sub-par work, stuff that they aren't thrilled with, are they inherently miserable creatures? Or do they say "I get to do something I like to do for a living, my work may not end up in the Metropolitan Museum of Art, but that's ok"? Same kind of thing with musicians who write soundtracks for straight-to-video movies or reality shows, are they in abject misery beause they are not the next Mozart, John Williams or even a pop star?

    Maybe closer to home for us Slashdotters, what about auto engineers? Not everybody gets to work on the next BMW concept car. For those having to work on generic sedans priced under $20k, are there corners to be cut analogous to what software developers are asked to do (safety, emissions, performance)? Does this result in similar misery/angst being described in TFA?

    1. Re:Parallels? by R3d+M3rcury · · Score: 1

      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 those out pretty quick (unless he got distracted--"Norwich Pubic School"?! Oh shit...)

      On the other hand, if somebody wanted a nicely carved sign with gold leaf, he'd probably charge them less--more than the boring square painted sign, but less than what others might charge--because it was something he enjoyed doing. Heck, I know he lost money on a few of those because he was learning. But he enjoyed it and got pretty good at it. After awhile, as the family became smaller, he got into a position where he could say, "No, I don't want to do that sign because it's boring. Here's a guy you should talk to instead." He also started doing more chip-carving and making the local craft-fair circuit. He finally got completely out of the sign business (retired) and did the craft-fair thing.

      The point is, kind of like in software, there are the boring things you do to make money. Sometimes you get to do interesting things to make money. Occasionally, you do exciting things and make money.

  32. I like to test by aepervius · · Score: 1

    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.

    --
    C. Sagan : A demon haunted world:
    http://www.amazon.com/gp/product/0345409469/
    visit randi.org
  33. Being stuck while solving a problem by luis_a_espinal · · Score: 1

    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.

  34. Old dogs who won't learn new tricks. by ed314159 · · Score: 1

    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.

  35. Switch jobs by Kwyj1b0 · · Score: 1

    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: "If you remove my idiot coworkers, remove deadlines, and everything I do just works perfectly, I'd be happy."

  36. Of course productivity and happiness are linked! by Ihlosi · · Score: 1

    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.

  37. Re:Has low pay been mentioned yet? by Ihlosi · · Score: 1
    "Competitive salary" is what they love to say, not understanding that it's transparent english for "as little as possible."

    Or even "we pay an average salary, but we only want top-of-the-line people". Which doesn't work.

  38. Were credit stealers mentioned by sandbagger · · Score: 1

    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.

    --
    ---- The above post was generated by the Turing Institute. Maybe.
  39. And the obvious by whitroth · · Score: 1

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