First, thanks to everyone who took the time to complete our Developer Happiness Survey. Using a highly-scientific and proprietary method, we can safely conclude from our >500 responses that the average DZone reader (as if any of you are average) is a moderately satisfied yet fairly paid to underpaid engineer who generally avoids user groups and extracurricular coding while boasting a manageable commute to a somewhat quiet office where mildly challenging development is performed by an average team (led by average management) using an ill-defined development methodology and unclear requirements employing subpar/mediocre tools practicing source control/continuous integration and consistently updated schedules, where testers test (and bugs are found and promptly fixed), interviewees don't code, and software is a source of profit.
Does that sound awesome or what? Forget all that for now.
About The Survey
I designed the happiness survey based on two theories. My primary goal was to test the accuracy of nearly twenty years of anecdotal evidence, amassed over thousands of conversations with developers looking to change employers. There are only a handful of common answers cited as reasons for leaving a job, and another handful of responses that developers tend to echo when asked about their critical criteria for their next position.
Second, I was curious how well the individual elements of the Joel Test and a combination of the Joel Test questions might "stack" up (see what I did there?). I peppered the survey with variations on 8 of the 12 questions Joel Spolsky wrote back in 2000 to try and rate the quality of a software team.
Survey Results Breakdown
Just under half of you feel underpaid, and this is almost identical to those earning market rate. Both underpaid and at market respondents were mostly in the average job satisfaction category, but among the underpaid the unhappy outnumbered the happy 4:1.
Those who felt they were paid market rate were equally likely to claim happiness and unhappiness.
The smallest amount of responses (2%) in this category came from those claiming to be overpaid and unhappy.
Many developers have cited a lack of technical challenges as a reason for leaving their jobs over the years. Half of you claim to be still learning at the workplace, and dissatisfaction among that "I'm still learning" group is a mere 11%. Half of the underchallenged are unhappy, while only 2% are happy when not learning on the job.
Tools and Stack
Only 25% reported that your employer uses the best tools regardless of price, and a combined three-quarters identify as using a rather standard (48%) or cutting-edge (26%) tech stack. Less than 1% of all respondents reported being happy while still using a dated stack. Only 12% of those who use the best tools are unhappy, compared to the 38% dissatisfaction rate among those using second-rate tools.
The competence of co-workers and management is often cited as important to job seekers, and the numbers here seem to validate that observation.
Regarding co-workers, three-quarters rated your team as average (45%) or above average (33%). Just under half of you also claimed to be the most knowledgable person on your team. On above average teams 10% are unhappy. Compare that to 3% of those on poor teams being happy (more than half are unhappy), and the value of a good team is clear. Being the best on your team also comes with a 1/3 dissatisfaction rate, which may be felt by those who can no longer learn from peers.
As for management, about one-third of you described your bosses as 'mostly incompetent or dysfunctional', which came with a whopping two-thirds dissatisfaction rate. Less than 1% of all respondents reported being happy under bad management or unhappy under competent management.
Cost vs Profit
I have heard developers regularly expressing more interest in working for companies that either build a software product or are generally associated with the technology business, as opposed to firms where tech is a cost of doing business. The ratio of happy to unhappy developers at tech firms is unremarkable, but dissatisfied developers outnumber the satisfied by nearly 4:1 where software and tech is not the focus.
Responses to certain questions on the Joel Test were clearly more revealing than others.
There were 14 responses that scored positive for all of the Joel Test questions. It's clearly a small sample size, but these respondents reported to mostly be paid at market (50%), challenged (85%), code in their free time frequently or on occasion (71%), have competent managers (57%), work on above average teams (85%), and use newer technologies (64%). Only one of the 14 reported being unhappy.
As for the individual Joel Test elements:
Quiet — Only 1% of you claimed to be both happy and working in a loud environment, while half of those subjected to loud noise are unhappy. The differences between the happy, average, and unhappy in quiet offices were insignificant.
Tools — Companies that use the best tools regardless of price see over one-third happiness rate, and developers that use lesser tools experience 38% dissatisfaction.
Testers — 64% of your employers have testers, but that doesn't impact happiness (for developers anyway).
Timely Bug Fixes — Just over half of you reported that bugs are fixed in a timely fashion and the developers try to make fixes before moving on to new code, but there the satisfied only slightly outnumber the dissatisfied. Teams that don't squash their bugs see 44% unhappiness rates compared to a slim 10% reporting as happy.
Source Control — Three-quarters of you work in places where source control is taken seriously. Our data shows that good source control won't guarantee developer happiness, but only 9% are happy in companies without source control (as compared to almost half being unhappy).
Continuous Integration — NOTE: Joel's original questions were "Can you make a build in one step?" and "Do you make daily builds?", where I asked a true/false "My company practices continuous integration." CI is practiced by over half of our respondents. As you might expect, our results here are similar to the source control question. Development shops that have CI in place have an almost identical number of happy and unhappy developers, but the unhappy dwarf the happy at a 4:1 ratio where CI isn't practiced.
Schedules — Half of you feel your work is kept on an up-to-date schedule, but that alone doesn't impact satisfaction. 40% of those with poor schedules report being unhappy.
Requirements — 64% of you are not getting clear requirements. Good reqs result in keeping one-third of developers happy and one-seventh unhappy, while those with poor reqs are almost one-half unhappy and only one-tenth happy.
Interviewees Code — I was quite surprised to learn that only just over one-third of you work for companies that require applicants to write code as part of the interview process. Once again, happiness and unhappiness numbers were nearly identical at employers that require interview coding. Where interviewees don't code, the unhappy contingent is almost triple the size of the happy group.
I would have expected more than 18% of all respondents would have reported as happy when compared to the 30% unhappy.
Across all questions with a third "average" answer available, many or most respondents (43-74%) tended to choose that response.
The ratio of happy to unhappy tends to be similar (and near 1:1) in several of our questions when the answer is positive, but the ratio jumps significantly when we review the negative responses. It seems that "having" some positive characteristic in your environment doesn't make workers happy, but not "having" it makes workers unhappy.
This survey and my analysis has some obvious flaws. Our sample is almost entirely DZone readers, an audience that may not be representative of the global development community.
One major factor in overall happiness which was not addressed is the mission of the employer. Many employees achieve job satisfaction by working for companies that share their values and principles (non-profits or civic groups).
I hope you found the results as interesting as I did.