The association between skills listed in a worker's profile and hourly wages is accidental. The actual analysis we want to see should be project based, showing what projects (in which I would like to see technologies used as variables) command the highest hourly wages.
I would guess that most HN'ers do believe that using a better blub makes them more effective as hackers. What we don't see FTA is a link between USING the better blub and hourly wages.
Maybe Clojure developers are a subset of the top 5% of Java hackers. One possibility is they are then hired to work on projects using Java and that they might command higher hourly wages (being in the top 5% of Java hackers and assuming this is demonstrable to hiring orgs) rather than being especially valued for their Clojure skills.
And, make your chart x-axis start at 0 instead of 25. :) Tufte rules.
1) The data are what they are - these are the rates people are charging by listed skill. It would be very interesting to look at prices by actual completed projects, but that's just another approach one can take.
2) I make it very clear that there's an association, not a causal claim. I flag the fact, make a lame joke about it and put "might* in the title.
3) There's no Tufte rule about starting charts at 0 - you make choices that make it easier for people to make comparisons. Paul Krugman said it better than anyone on this topic: http://krugman.blogs.nytimes.com/2011/09/14/axes-of-evil/
Yes, but not rates being charged for using the listed skill.
As to the dreaded axis values: I think your chart, in this context, does exaggerate the variation in hourly wage by skill. At first glance, almost all your data points are between $25 and $35. Clojure hourly wage is around $31 per hour from the interactive chart. Your lowest hourly wage for a skill, haml, is $25.90. This simply is not much of a difference and your chart should make that clear.
I like your article. It is interesting, and I appreciate your efforts to take this data and provide some value out of it to the community.
I think we need to be more conservative in drawing any conclusions out of this data though.
The vital piece of information in the graph is the relative size of the wage. If the author had started at 0, it would be far harder to distinguish differences between the skills, by the same principles that make pie charts mostly unusable.
Relative (i.e. proportional/percentage) size is only apparent when you start a chart at 0. The absolute difference between 25 and 31 is 6. If you start the chart at 25, that's graphed as an ∞% difference, when it's really only a 24% difference.
Thanks for making my point for me! The chart really misleads re: the difference between languages. Do we even know if Clojure wages are statistically different from, say, Scala rates?
Other problems:
1. As hinted above, what are the standard deviations? Do we even know if Clojure is statistically different from HAML? Do Clojure rates exhibit higher variation than HAML?
2. $4 difference between pattern recognition v. machine learning, where pattern recognition is, effectively, a subset of ML? We see this with legal services v. contract drafting, and (arguably) info architecture v. interaction design (less overlap with these, to be sure).
Also, while John gets credit for joking about causality, I'd be very concerned about sampling bias if he uses oDesk data to examine human capital decisions.
We'll have to disagree about the axes---I think the choice of where to start axes depends on what you're trying to illustrate. For me, absolute differences in wages was what I wanted highlight.
Re: Standard error bars - you're absolutely right. I should have included them, but it was my first time using the googleVis package & didn't see an easy way to add them. I don't have the numbers right in front of me, but standard deviation for each skill was on the order of ~$7/hour and each skill had to have at least 30 obs., though many where much, much higher. If we say n=50, that's an SE of about $1/hour, so clearly one shouldn't take much stock in very small differences in wages. My goal was just to unearth some interesting data---I probably should tone down the implied recommendation lest I'm responsible for a glut of unemployable lisp hackers in a few years:)
The graph is visual, it's the relation visually; if you're trying to calculate the actual %change, then a table is needed. But having all the bars at full length makes it near impossible to see the differences between bars of length that are within a few % points.
I see the graph as answering the question: What is the difference in achievable wages between different "hacking" skills? The graph, as shown, displays that difference well. Like I said, there are no hard and fast rules, but I would have done it the same way!
"What we don't see FTA is a link between USING the better blub and hourly wages."
Neither the data nor the article make any connection between USING Clojure and hourly wages.
The connection is between LEARNING Clojure and high wages.
This is commonly known as the Python paradox, cited in the article. Learning currently esoteric languages signals a motivated self learner passionate about his craft. Listing Clojure in a job listing signals a company doing work that would be interesting to a motivated self learner passionate about her craft.
With a cap of $100/hr does the data really reflect "high-wage" skills? Lawyers start well above that and it's smack in the middle of a poll from a few years ago: http://news.ycombinator.com/item?id=553794.
That was my impression as well. The rates are from the lower end of the pool, people with general experience and no deep expertise.
I have worked off and on for many years as a contractor working on high-end database scalability and performance issues as well as parallel algorithm design. While the rates fluctuated with the market and how much I liked the project, I was always charging well above $100/hr even for terms that ran several months.
A lot of it has to do with who your customers are. If you are working on the design of a system that will be moving $250M per year if it performs correctly, spending an extra $100k to hire a deep expert in the design of such systems is below the noise floor. You might be a "database scalability consultant" but you are not fishing in the same pool as most of the people that claim similar labels for themselves.
My wife works at one of the largest law firms in the world, and trainees there makes about $10-$15/hour. On paper their salary is high, but the hourly rate is pushed far down because of ridiculously long hours. Their secretaries make as much or more than them.
Newly qualified lawyers there make $20/hour if they're lucky. This is in the UK, specifically in a London "magic circle" firm - one of the highest paying law firms in the UK. US firms in London pay up to about 1/3 more total yearly salary, commensurate with the same firms salary levels in the US, but also tends to expect even longer hours.
It's first quite a few years post qualification that their salaries get high enough that their hourly rates starts to become decent.
Average salary for a solicitor in the UK was around $37k/year a couple of years back, for longer than average hours, at a time when the national average salary in the uk was ca. $40k/year...
I'm sure there are lawyers who start out at high hourly rates from day one, but I'd be surprised if more than a tiny fraction starts out around the $100/hour rate.
Actual billed out rate from a major law firm, sure - my wife is billed out at around $300/hour as a trainee.
Good point, I was looking at it from the perspective of a client wondering "how much will I pay." As you say the lawyer doing the work won't be taking home nearly that much. I didn't know it would go as low as $20/hour though. My conservative estimate for a new lawyer in the US would be $80K/2400 hours = ~ $34/hr. How do the expected hours compare in the UK?
In a big market (NY, Chicago, DC) at a firm working for corporate clients, you're looking at ~$170k/2700 hours. For a more senior person (5-7 years in), you're looking at ~$280k/3000 hours.
You can almost certainly make more on a per-hour basis as a contractor in the software sector, but lawyers are risk averse and prefer a stable flow of work and decent health insurance. :D
Point: if you want to make nice money on oDesk, offer a niche expertise. I started a small company doing node.js/mongodb/redis and I can pretty much ask what I want. There is no competition. On the other hand, when i'm short handed, it's impossible to find people with these skills on a non-beginner level who are not really insanely expensive, so it's not exactly a highly scalable business ;)
The article is only looking at the relationship in one direction. It's not entirely that learning clojure makes you money, it's that high level academic types that are predisposed to high wage jobs are more likely to know clojure. I would actually argue that this is the far more significant causation relationship. But what do I know - I don't know clojure. :)
There are many niche skill sets out there where the demand far exceeds the currently supply, and as such hourly rates from $100/hour (lower level) to $200+/hour (architect level) are quite common and you really can pick your job/location/work from home, etc... The trick is finding one, and learning it quickly/well.
I've often thought about grabbing a bunch of folks with a similar relevant skill set, investing 6-12 months in training them, and then running a hugely profitable consulting company for a while. The problem being it's hard to prevent people from hanging out for your 12 months of training, and then jumping ship to do their own thing afterward...
The kind of expertise that consistently commands the high rates requires a level of experience that cannot be developed through training. It requires in-field domain expertise developed over a few years. What you are talking about is what many consulting companies actually do, and it is one of the reasons that consulting companies have such a poor reputation for execution. Customers are paying for the expertise you will not pick up in training or by reading a book.
I ran a successful consulting business many years ago (and hated it). One of the things you learn is that you live and die by the quality of the people you can deploy because that goes straight to your reputation. In practice, consulting businesses are very difficult to scale. While you may start out high-end with a great reputation because you really know what you are doing, it is very difficult to bring in additional people with your level of skill because there is almost no overhead to them working independently. As a result, "scale up" often involves diluting the quality of your overall team to the point where the rates you can charge decline as well. Consequently, you either have to run a very small boutique consulting shop that can maintain its standards and billing rate or run a large generic shop that makes up for the lower billing rate in volume. For people that care about the quality of their work, the former is more rewarding but the economics work out such that you will make about as much money by going direct as a highly-paid contractor to another company.
In this particular case I'm not talking about grabbing random people, I'm talking about people who are very skilled in a similar tech stack (which has a much higher supply/demand ratio, and getting them up to speed with the very similar but niche stack. Basically you're just learning some new APIs and some new service providers (i.e. proprietary ORM instead of Hibernate).
But I agree with your assessment of consulting firms and the scaling/quality issues therein. I also feel that consulting shops expenses tend to scale a lot closer to profits than some other businesses, so I stay out of it:)
I'd be really interested to read a list of these highly remunerative skillsets. Going to be taking some time off, and probably heading in a new direction when I start working again.
How does one go about finding developer resources for closed applications like Oracle ATG (or really any of the above list)?
I'm employed by an eCommerce vendor myself, so I'm sure I'd have an intuitive understanding of general architecture, but actually understanding the internals of a system as an outsider seems like a difficult proposition.
Until Oracle bought ATG it was basically impossible. But Oracle has made ATG available for download, including documentation, to anyone, without needed a million dollar support agreement. You can't run a production site for free obviously, but at least now you can read the docs, and play with the software locally.
The only real hope of learning it though is to have a company that you work for use ATG, send you to training, and get you coding on it every day.
This is why there is such a huge gap between the demand and supply of this skill set currently.
They're cutting some of the fat off, but they just dropped 1 billion dollars on the ATG product and are pushing it pretty hard and Oracle doesn't have anything that's a real competitor in the space. It'll get renamed as Siebel Commerce or something, but it's not going anywhere for a long time...
Thanks, that's very interesting. Why do you believe that Clojure/Scala are on the cusp of high demand? Those would be the most interesting directions to go on that list.
Note: what I'm about to say has zero technical base since uh, you know, I don't care about technicality or purity, we're talking about pure business direction here.
I'm unsure regarding Scala since a few articles have risen regarding getting burned by Scala (Yammer) or plainly suggested that Scala may not be it (David Pollack, one of the Scala celebrities).
Having said that, knowing Java developers, most (not all) of them would definitely flock to either Scala or Groovy instead of LISP. Have you heard anything about Groovy lately? Yep, nada, cricket. The cool kids (Yammer, Twitter) are using Scala (to some extend) so there you go.
Clojure on the other hand has that "LISP" tales behind it (LISP programmers are like gods or something like that) and it runs on Java so that gives people some kind of hope and smile on their face or something.
I don't know if either would be in high-demand but you may want to look around and do a bare minimum, out of the thin-air, lots of grain of salt type of assumption:
>The problem being it's hard to prevent people from hanging out for your 12 months of training, and then jumping ship to do their own thing afterward...
If someone is making a consulting agency that gets clients, deals with most of the risk, etc., then that is worth something to me and I'd be willing to take a less then I could get if I were doing the same work freelance. I'd give up, say 10-20% of the value of the contract to pay for such services. If the owner wants to take much more than that then he/she will have to expect people to jump ship after training. The salary difference is worth taking on these other responsibilities yourself or finding an agency that will take less.
As far as your second example of people, I don't think enough people are like that to warrant consideration. People are more likely to stay with a company beyond the point of rationality.
The problem is that if you spend 6-12 months training people you've got WAY more costs to recoup than a normal contracting firm so you'd have to take a higher percentage off the top. The rates would be higher for the niche so the take home would still be good, but a smart person would see you taking 30+% off the top, and know they can only give up 10-20% at another place or none by going freelance once they have some network in place. The sunk costs of the training and bench time around that are very hard to make back.
You'd be amazed at how much $240 a day is in developing countries. In some latin american countries $240 is the minimum wage for a month; earning $4800 per month is more than what a typical worker makes in an entire year.
$30/hour would make you part of the 1% in these countries.
On a completely unrelated note, I'm curious if anyone has tried odesk from a developer point of view? Freelance websites like elance seem to play host to a pretty poor type of client, so I've stayed away. Curious if odesk is any bettering that way?
Problem is, you're competing with people in places with a far lower cost of living - especially in "mainstream" technologies.
oDesk clients tend to be one of two types: Skilled project managers/architects/agencies looking for subcontractors, or businesses looking to save a buck by not hiring the former.
The first group are great, they know exactly what they want and will pay for quality. The latter are hell as they often have no idea how to communicate requirements, scope, process, etc and want everything cheap.
If you live in the first world and have the communication skills, the best place to find freelance development work (IME) is still community networking.
I tried it both ways; employer & developer; both work fine on oDesk. Much better than other sites I have tried.
Basic thing is ; don't go for mainstream. You cannot compete on price doing PHP or something like that. If you have something 'niche', you can pretty much ask what you want and get it.
I've tried a few Freelancer sites and found them to be a good way to find new clients but it's been worth being very selective about clients and never competing on price.
There are actually quite a few excellent clients out there on those sites but they actively won't talk to people who bid at the level of the bid-on-everything-then-outsource "suppliers" who plague freelancer markets.
So my anecdotal impression is that the most successful freelancers learn to get very picky about who they work with---they want to see a verified payment method (esp. if the client is proposing a fixed-price contract), a history of hires and successful projects at reasonable wages and a good job description.
Apologies if I'm missing this in the article, but it doesn't seem to take into account the level of demand for those skills. It's all very well having a skill that demands $50/hr, if openings for that skill only come up once in a blue moon.
You're right---there's nothing about the demand side yet. That's my next blog post. I'll show the earned wages by skill and some measures of demand & trade volume in different skills.
Judging by the number of people who contacted me about Python work when I accidentally implied I had Python experience, I'd say that's a pretty hot market right now. Certainly compared to PHP at least ;-)
I didn't RTFA yet but what I want to ask HN readers: what are some good niches in IT work that are proven to reap high wages in consulting?
If I'm going to be a highly paid consultant instead of an underpaid employee I have to do something more desirable/uncommon than .NET boilerplate coding...
It's just a particular way to analyze some data on oDesk, I wouldn't take it as a gospel of pure truth.
I want to find out about the tried and tested niches that HN readers might know about.
Background: my goal is to find some in-demand yet rare skill and hammer the crap out of that so I can get paid more per hour and cut down the percentage of my life that is spent generating income for food, shelter, clothes, etc. Working 40 hours per week doing boring C# code is very inefficient when I have so many other projects that need to be done. And for the time being (ie until I build the next Facebook :)) I think consulting will be the best way for me to reach my objective.
This data only reflects the oDesk labor market (which is notoriously a race to the bottom). I would hesitate to draw any other conclusions. However, it would be interesting to see this data broken down by geographic region.
"High-wage skills on oDesk (or why you might want to learn Clojure if you're not a lawyer) "
Totally a link bait title. Clojure hasn't been around that long and therefore hasn't been in demand that long.
Heading off in any one particular direction based upon the way things appear to be now vs. what they will be long term wouldn't be what I would do. Do you think "clojure" is like "plastics". I don't think it is.
Also, as has happened with many career/skill (nursing at some point, law now) once the word gets out that something is in demand (because of supply and demand in balance) that changes as people are drawn by the chance to make money.
And clojure is a skill it's not a profession. That skill can quickly be replace by the next new thing.
I take "Amazon RDS" being in the top 6 as a sign that these numbers are pretty worthless - the whole point of RDS is that it's easier to set-up and administer than a do-it-yourself install.
Comparing MongoDB (in absolute bootom) to Redis (5th place) makes me think I've missed something?
Is Redis that hard to use or does the number of Redis users increase exponentially with a resulting lack of skills? (Or is the web site not a good salary predictor?)
MongoDB is a VC-backed technology, which has spurred its adoption at funded startups. Since they're funded, those startups can also afford to pay engineers more.
MongoDB was also hyped to hell and back, which probably accounts for more of its adoption than the fact that it's VC-backed. IIRC, most of the big name adopters (Foursquare, etc.) were using it before it got funding, too.
The association between skills listed in a worker's profile and hourly wages is accidental. The actual analysis we want to see should be project based, showing what projects (in which I would like to see technologies used as variables) command the highest hourly wages.
I would guess that most HN'ers do believe that using a better blub makes them more effective as hackers. What we don't see FTA is a link between USING the better blub and hourly wages.
Maybe Clojure developers are a subset of the top 5% of Java hackers. One possibility is they are then hired to work on projects using Java and that they might command higher hourly wages (being in the top 5% of Java hackers and assuming this is demonstrable to hiring orgs) rather than being especially valued for their Clojure skills.
And, make your chart x-axis start at 0 instead of 25. :) Tufte rules.