rss feed
2. nearby food: 2.9
3. internal team communication: 2.8
4. location: 2.8
5. business model: 2.8
6. quality of developers: 2.7
7. product quality: 2.7
8. source control: 2.6
9. health coverage: 2.5
10. paid time off: 2.4Much like the best employers (http://coderific.com/blog/post/368), the worst employers also are rated highly for casual dress policies. Granted, the casual dress score for bad employers (3.3) is a bit lower than for the best employers (3.6), but I would've expected a lot more suits and ties at the bad development shops.It is notable that even at the worst software shops, the quality of developers metric still gets a moderately decent rating. Is it that developers are unlikely to blame themselves for any problems that a company might have? Or are all of Coderific's users from Lake Wobegon, and therefore all above average? Obviously it's the latter.But what about the lowest-rated aspects of the worst employers? Why exactly are the bad organizations so bad to work for?1. hitting deadlines: 1.9
2. team-to-team communication: 1.9
3. automated testing: 1.8
4. quality of upper management: 1.8
5. other perks: 1.8
6. prevention of crunch time: 1.7
7. warm fuzzy feeling: 1.7
8. employee retention: 1.6
9. overall: 1.6
10. development of Free Software: 1.5Besides the fact that these scores are almost a full star lower than those for the best employers, the lists of the lowest-rated aspects are eerily similar. Both the best and worst employers have trouble with team-to-team communication, automated testing, hitting deadlines, and prevention of crunch time. A natural conclusion from this data is that perhaps all development organizations have these problems in one form or another. Developing software is a relatively new discipline, and neither the best nor the worst organizations have quite figured out how to do it without missing deadlines and slave-driving their developers.So if the best and the worst software shops have so much in common, then what differences are there to explain why the worst shops are so bad from a coder's perspective? Well, if the items present on the list above but missing from the list for best employers is any measure, then quality of upper management, employee retention, and that warm fuzzy feeling are all rather significant.They say that you don't quit your job. You quit your boss. This little aphorism might be more true than you would otherwise think. Quality of upper management is rated so poorly at the worst employers, in fact, that it could be the primary reason driving developers away, leading to the employee retention problems these organizations have.When coders feel like their management is incompetent, out-of-touch, or otherwise incapable of basic management tasks, they will be much less likely to go along willingly when asked to work that inevitable crunch time. Simply put, developers become resentful when they're negatively impacted by poor management decisions.But at a good employer, with decent or even passable development and upper management, coders feel much more like everyone's rowing in the same direction and there's less of an "us versus them" mentality between developers and management. So even though there are still missed deadlines and crunch time at the good employers, the code monkeys won't feel so resentful about it, and so will be much less likely to hop jobs to try to improve matters.Ah, and then there's the matter of the warm fuzzy feeling. It's the feeling that the code you're cranking out is worthwhile, that the products you're making are going to make users' lives better. There are a million tiny ways to erode this feeling, including everything from poorly justified management decisions to neglecting to give developers any actual software development requirements.Now, let's get to the OSes. Of the worst-rated employers, here are the platforms used:1. use of Free Software: 2.7
2. use of Windows: 2.6
3. use of GNU/Linux: 2.4
4. use of Mac OS: 1.9
5. use of Solaris: 1.6
6. use of BSD: 1.0Wow, the ranking of platforms used for best employers and worst employers are identical! I guess we can discount the platforms used in an organization as a major factor in how good the employer is for developers. Sure, some developers prefer one platform over another, but whether an employer is overall good or bad does not appear to correlate strongly with the OSes used.Of the worst-rated employers, here are the languages used:1. use of C++: 3.1
2. use of legacy languages: 2.8
3. use of Java: 2.7
4. use of C: 2.3
5. use of Perl: 2.0
6. use of ASP: 1.6
7. use of PHP: 1.6
8. use of C#: 1.6
9. use of Python: 1.4
10. use of Ruby: 1.1
11. use of Lisp: 1.1
12. use of Objective-C: 1.0Now this is interesting. The poorest development shops use a heck of a lot more C++ and legacy languages than the best employers do. It appears that the good employers use what can be glibly categorized as trendier languages, while the worst employers use languages like Fortan, COBOL, and C++. The heavy use of legacy languages isn't too terribly surprising. Bad development shops don't have the time, motivation, or leadership to refactor or upgrade, and so are often stuck supporting old cantankerous systems written in languages not mentioned in polite conversation since the Ford administration.But what about the large disparity in C++ use among the best and the worst employers? To put it plainly, higher-level languages like Java, C#, Ruby, and Python are more fun for most developers for most general-purpose programming. When your day-to-day debugging involves fixing the actual logic in your program rather than chasing down memory allocation problems, you tend to be a happier coder.So what can development organizations learn from this data? Well, if you have bad management in your company, throw them out. It could be costing you more than you think to keep incompetent managers running things, especially in terms employee turnover and general coder productivity.What if you are the bad management? Well, then either ask your developers for a couple of good books to read on the topic or think about another occupation. After all, you can sit in your office all day being ineffective just as well in any other line of work.
blog - what the worst employers have in common
posted by witten on February 08, 2007
If you've worked in the software industry for any length of time, you can probably rattle off a long list of problems found at the worst places you've worked. But to save you the trouble of dredging up those painful memories, I've collected a list of what the worst employers have in common, generated from the bottom of the barrel of Coderific employers: http://coderific.com/employers/worstFirst, let's look at the highest-rated aspects of the worst-rated employers. In other words, these are areas in which the worst employers don't completely suck. All scores are out of 4 stars, and employers lacking multiple ratings are excluded:1. casual dress code: 3.32. nearby food: 2.9
3. internal team communication: 2.8
4. location: 2.8
5. business model: 2.8
6. quality of developers: 2.7
7. product quality: 2.7
8. source control: 2.6
9. health coverage: 2.5
10. paid time off: 2.4Much like the best employers (http://coderific.com/blog/post/368), the worst employers also are rated highly for casual dress policies. Granted, the casual dress score for bad employers (3.3) is a bit lower than for the best employers (3.6), but I would've expected a lot more suits and ties at the bad development shops.It is notable that even at the worst software shops, the quality of developers metric still gets a moderately decent rating. Is it that developers are unlikely to blame themselves for any problems that a company might have? Or are all of Coderific's users from Lake Wobegon, and therefore all above average? Obviously it's the latter.But what about the lowest-rated aspects of the worst employers? Why exactly are the bad organizations so bad to work for?1. hitting deadlines: 1.9
2. team-to-team communication: 1.9
3. automated testing: 1.8
4. quality of upper management: 1.8
5. other perks: 1.8
6. prevention of crunch time: 1.7
7. warm fuzzy feeling: 1.7
8. employee retention: 1.6
9. overall: 1.6
10. development of Free Software: 1.5Besides the fact that these scores are almost a full star lower than those for the best employers, the lists of the lowest-rated aspects are eerily similar. Both the best and worst employers have trouble with team-to-team communication, automated testing, hitting deadlines, and prevention of crunch time. A natural conclusion from this data is that perhaps all development organizations have these problems in one form or another. Developing software is a relatively new discipline, and neither the best nor the worst organizations have quite figured out how to do it without missing deadlines and slave-driving their developers.So if the best and the worst software shops have so much in common, then what differences are there to explain why the worst shops are so bad from a coder's perspective? Well, if the items present on the list above but missing from the list for best employers is any measure, then quality of upper management, employee retention, and that warm fuzzy feeling are all rather significant.They say that you don't quit your job. You quit your boss. This little aphorism might be more true than you would otherwise think. Quality of upper management is rated so poorly at the worst employers, in fact, that it could be the primary reason driving developers away, leading to the employee retention problems these organizations have.When coders feel like their management is incompetent, out-of-touch, or otherwise incapable of basic management tasks, they will be much less likely to go along willingly when asked to work that inevitable crunch time. Simply put, developers become resentful when they're negatively impacted by poor management decisions.But at a good employer, with decent or even passable development and upper management, coders feel much more like everyone's rowing in the same direction and there's less of an "us versus them" mentality between developers and management. So even though there are still missed deadlines and crunch time at the good employers, the code monkeys won't feel so resentful about it, and so will be much less likely to hop jobs to try to improve matters.Ah, and then there's the matter of the warm fuzzy feeling. It's the feeling that the code you're cranking out is worthwhile, that the products you're making are going to make users' lives better. There are a million tiny ways to erode this feeling, including everything from poorly justified management decisions to neglecting to give developers any actual software development requirements.Now, let's get to the OSes. Of the worst-rated employers, here are the platforms used:1. use of Free Software: 2.7
2. use of Windows: 2.6
3. use of GNU/Linux: 2.4
4. use of Mac OS: 1.9
5. use of Solaris: 1.6
6. use of BSD: 1.0Wow, the ranking of platforms used for best employers and worst employers are identical! I guess we can discount the platforms used in an organization as a major factor in how good the employer is for developers. Sure, some developers prefer one platform over another, but whether an employer is overall good or bad does not appear to correlate strongly with the OSes used.Of the worst-rated employers, here are the languages used:1. use of C++: 3.1
2. use of legacy languages: 2.8
3. use of Java: 2.7
4. use of C: 2.3
5. use of Perl: 2.0
6. use of ASP: 1.6
7. use of PHP: 1.6
8. use of C#: 1.6
9. use of Python: 1.4
10. use of Ruby: 1.1
11. use of Lisp: 1.1
12. use of Objective-C: 1.0Now this is interesting. The poorest development shops use a heck of a lot more C++ and legacy languages than the best employers do. It appears that the good employers use what can be glibly categorized as trendier languages, while the worst employers use languages like Fortan, COBOL, and C++. The heavy use of legacy languages isn't too terribly surprising. Bad development shops don't have the time, motivation, or leadership to refactor or upgrade, and so are often stuck supporting old cantankerous systems written in languages not mentioned in polite conversation since the Ford administration.But what about the large disparity in C++ use among the best and the worst employers? To put it plainly, higher-level languages like Java, C#, Ruby, and Python are more fun for most developers for most general-purpose programming. When your day-to-day debugging involves fixing the actual logic in your program rather than chasing down memory allocation problems, you tend to be a happier coder.So what can development organizations learn from this data? Well, if you have bad management in your company, throw them out. It could be costing you more than you think to keep incompetent managers running things, especially in terms employee turnover and general coder productivity.What if you are the bad management? Well, then either ask your developers for a couple of good books to read on the topic or think about another occupation. After all, you can sit in your office all day being ineffective just as well in any other line of work.
3 comments
Write a comment!-
Re: what the worst employers have in common posted on February 10, 2007 12:56 AM
Here are some additional things to think about on the statistics being presented:In the past 2 months, there have been 50 ratings on companies. There are exactly 50 posts, as you can go here and see them at http://www.coderific.com/ratings/recent. I spent 10 minutes and clicked on each one to see if there were advanced ratings on the posts, and I counted up all the 1-4 star ratings.Interesting findings:Of these posts, 28 have advanced ratings (56%) and 22 have no advanced ratings (44%).What about erroneous postings? For the following calculations lets:
1) Assume 15% fake?
2) Assume 15% by a non-developers?
3) Assume 2% trying to get a refund on some game software they tried to buy.If we assume there are 32% ratings that fall into the category erroneous items (listed above), then this leaves us with 34 ratings by valid users. I left the "Canalside studios" team http://www.coderific.com/employers/163 in the statistics, because if I took the University based games development shop out of the statistics, that would be 10% of all postings! You may want to exclude "Educational" organizations in the future, as these are not places that Coderific users are going work, and will dramatically skew the stats due to large amounts of testosterone. Just so you know what I am talking about, Canalside Studios description on their webpage says "The studio is permanently manned by a core team of 8 placement students, but all students on the school's computer games courses contribute content through projects and get their name in the credits." Nice picture of the Yorkshire lads is here: http://www.canalsidestudios.com/index.php?page=aboutus.The statistics being presented in this blog are then based on 34 valid ratings in the last 2 months (at then end of this discussion I add more users to the pool of data by using another simple assumption just to get the sample size up a bit). Of these valid users, there are 56% with advanced ratings, so this is a total of 19 users with advanced ratings (advanced ratings are those things like "casual dress code" and the "nearby food") that are theoretically valid. A pool of 19 ratings covering both good and bad companies is extremely small.If we then look at the 50 posts (now using 100% of the sample size) and break them into 1-2-3-4 star ratings, we get some more statistics to use to apply to the model. (note: the reason I use 100% of the sample in this part of the equation is that there are so few posts that if I did not, the statistics would have such a high error rate the entire exercise is not worth looking at). Here are the stats:
1 star = 21 posts (42%)
2 star = 8 posts (16%)
3 star = 3 posts (6%)
4 star = 18 posts (36%)If we lump 1 and 2 star groups together, this is 58% of the postings (bad companies). This means 42% work for the good companies. Since the entire websites tag line attracts negative employees, this is not surprising ("Have you ever worked for a company that really understood software development? Neither have we."). This tag line itself throws considerable subjectivity into the data of any type of statistical survey. If this were my site and I wanted to provide real statistics, one needs to be a little more neutral in the tag line of this site.Using this ratio of 58%/42% (negative/positive responses) on a real user base of 19 users with advanced ratings, means the statistic presented in the blog are based on 11 users (bad companies) and 8 users (good companies) (based on a lot of assumptions listed above). I only had access to 2 months of data, so in reality these numbers may be low by 20-30%. If we assume 30% too low, then it is based on 14.3 users (bad companies) and 10.4 users (good companies).By leaving the "Canalside studios" crew in the mix, it also dramatically influences the number of 4-star rated companies. Since these guys make up 10% of all ratings, and these guys all posted 4 star ratings for their organization, it increases the positive ratings a lot. If we took them out of the game (pun intended!), the stats then go to 65%35% (negative/positive responses). It not only influences this "overall" 4 star stat, but this crew also clicked on 4 stars in the "advanced" ratings for almost all of the advanced ratings, so it puts a pretty decent skew on the statistics (4 out of 5 of them have advanced ratings). Very statistically significant, and should be considered in exclusions in the future.There are other companies that greatly skew the stats. Example is one of the best rated employers with 2 reviews. This example is Mermit Business Application Oy at http://coderific.com/employers/38. There is one 4 star and one 1 star score at completely polar views. Many statisticians would exclude this company due to a) not enough ratings to call it valid b) polarization of views indicates something not quite right (Ok to have polarized views, but not with this small of a sample set).You may note that the stats for "advanced ratings vs. no advanced ratings" and the ratio of good/bad posts are similar. Is there a correlation between them? Not really, from what I can notionally observe. There are basically random stats on 1-4 star ratings having any advanced ratings attached. No pattern detected, mostly due to such a small sample set.Some potential issues on the overall stats published on Coderific are:
- very small pool size
- very high questionable quality rate (possibly 32%)
- with very low quantity of reviews combined with clusters of high volume postings on some companies, this results in skewed results.As you can see in the calculations and methodology I used, there is a lot of manipulations to the data due to the small sample size and potentially high error rates (my stats teachers would roll over in their grave(s) if they saw these manipulations).Did the statistics posted by witten include all the postings? What is the basis for the statistics? There appears to be considerable room for inaccuracy as there are not enough ratings to even out the fakes, a guy asking for a refund for his Gamei on the site, and the lads from above the Watford Gap. Was this considered in the statistics? Maybe all this was factored into the stats presented on this site, but I just do not know. Can we know more details? As you can see, stats are very interesting to me.Please feel free to re-calculate anything I have presented as I am very fallible (not like those perfect coders talking about themselves on the blog "only good programmers don't like coding").I guess the first response by a Coderific user will be:
- Go to bed.
- We want users to understand "casual dress" is important.
- So what is your point?
- I do not understand.
- Where is your tin hat?
- What is a Gamei? (http://coderific.com/forums/posts/356?start=0) -
Re: what the worst employers have in common posted by witten on February 10, 2007 09:02 AM
Wow, thanks for all the feedback.First of all, let me bring your attention to what I stated at the very start of the first blog post in this series (http://coderific.com/blog/post/368):The coders have spoken, and through the rigorous scientific process of anonymous forum posts...
In case you missed it, that was a very tongue-in-cheek indication that the methodology, data, and presentation used here are not at all scientific in nature. For all intents and purposes, you should consider Coderific data slightly more accurate than an anonymous web poll. In other words, Coderific comments may be interesting or informative, but in no way am I claiming that any numbers are exactly representative of the development population as a whole. I'm just making generalizations.Another part of that blog post:I could try to make some generalizations about these organizations, perhaps to shed some light on what makes them so kick-ass. Unfortunately, it would be simply irresponsible to attempt to draw conclusions about the employers on this site based on the small amount of data currently available. Fortunately, I've never been big on responsibility. So here goes.
And there I am acknowledging the small data set.Okay, now that those disclaimers are laid out (for a second time), what about your other points?There are certainly some suspect or at the very least slightly questionable ratings. There's a FAQ entry for that (http://coderific.com/about/faq "How do you handle ratings of varying quality?"), so I won't rehash that here.The statistics in this most recent blog post include all ratings for companies on the "worst employers" list. It did not include forum posts that have no associated scores. So no, a guy asking for a "Gamei" refund did not get included in the stats.The bottom line: I'm just using what little amount of data that is currently present on the site as a tool to call out some generalizations about employers, both good and bad. I fully intend to revisit these numbers once there's more data available. But I just wanted to give people a taste of how the data was trending and perhaps suggest what that might mean about various employers. -
Re: what the worst employers have in common posted on February 11, 2007 06:10 PM
Dear Witten:Good response and thanks for that.You did point out that I missed a lot of your caveats - I read things too quickly!