Also, the dynamic range among e.g. Ruby programmers of my acquaintance goes from something like $2k a month to $2k a day, not primarily based on skill with Ruby. (If I were comfortable describing the individuals at the high end some people might say "That's cheating! They're getting compensated for non-Ruby things which happen to be expressed in Ruby programs." I call that winning rather than cheating but to each their own.)

For the people that ultimately pay the bills, this is the only thing that matters. They don't give a shit what technology you know or what a nice guy you are. They just want it done. To them, the ability to understand their domain, communicate effectively, and get things done is far more important that how you do it. I regularly hear from people who say, "I need x fixed/working/solved. We use y. If you don't know y, then figure it out."

Languages and technologies are only important to CTOs and recruiters. The point when you get beyond them and start talking to their bosses is when your career will really take off, not when you learn a "better language".

While the people who pay the bills think that's the only thing that matters, your ability to confidently market yourself as providing perceived value plays a big part in your payment or salary negotiations, regardless of the actual value you provide.

Unfortunately I, like many others in our field, suck at this. Strangely, I've always found it easier to to market the work I do than to learn to market my own value. I can't even write a short bio without feeling like I'm stepping out of line.

My suggestion: replace the word "market" with "communicate" in your thinking. So:

"your ability to confidently communicate your value plays a big part in your payment or salary negotiations"

So it's not marketing, it's kind of like writing docs for end users. Still not coding, but a little further from "marketing". A small change, but it may give some mileage.

I feel like the term "marketing" is often used by not-so-great communicators to fill a gap of understanding of how value is communicated by those who are doing good business as a result.

I think the same goes for companies. E.g. a user friendly phone, tablet, computer or maybe just a very usable website, is not more expensive because of 'marketing', but because it does a better job communicating with the end user and thus creating a better perception of value to the customer.

150% agree. I had to write a bio when I judged a hackathon last month. It took 2 hours two write, what ultimately became one sentence.

Even at the CTO level, languages and technologies more of a strategic business decision than a raw technical decision. Questions like:

* can we hire enough programmers of quality in this language?

* is there sufficient support available for these technologies?

* is the technology sufficiently mature?

Selection of a core technology can't be purely a "wow, cool" decision at that level, although it may factor in to what kind of programmers you are likely to get (e.g. see pg's old article "The Python Paradox" http://www.paulgraham.com/pypar.html)

Jane St. Capital also does this to some extent by using OCaml, but I don't think that was the primary motivation.

Of course they do. Imagine trying to convince a CTO of a 20-strong company to switch to another, better suited for the business task at hand, programming language for a project with 1+ MLoC written over a course of couple of years.

So for example Java in London tends to be pretty well paid because all the investment banks hire for it heavily, this has also pushed up Java salaries in non-banking role.

The best PHP dev with great negotiating skill probably still makes less than an average Java dev at a bank.

- How much money are you making for your employer - What are the costs your employer needs to make to allow you to make that money for him

If there's a large and growing gap between the two, you can expect a raise, event if the company as a whole isn't doing too well. If there's a small or shrinking gap, you'll be looking for another job soon. If the gap is negative, you're probably the owner.

In the worst case, I... I mean my made-up friend Bob... has worked on teams that seemed to have no other purpose than to execute the new idea that week, with little or no connection to any actual business value.

Bob has seen this happen too many times for it to be a random occurrence. According to Bob, such engagements/teams are typically funded by the taxpayer or upper management at companies that have more cash than God. Then I told Bob to shut up, because he's in breach of all the NDAs and sometimes people read things on Hacker News.

What would be interesting in this survey is slicing it by industry and years of experience. Do Python programmers in Financial Services make more or less than C++ if they both have 3 years of experience? Which languages show tapering of salary after a certain amount of experience?

In case you don't remember, we had a discussion about the job market last year: https://news.ycombinator.com/item?id=4214543

You were claiming the hiring market was on fire and that being fizzbuzz capable was about enough to get meetings with hiring directors and that your clients were begging you to find them an engineer.

During that time I was spending a great deal of time applying to jobs, going to tech meetups and interviewing and had very little success despite a track record of successfully taking on challenges in the business world and demonstrable junior-level programming skills. I asked you to your back up your claims and put me in touch with any of these clients dying for an engineer, as you might remember.

Now—about a year later—I've achieved the goals I had at that time. I'm working in a purely technical role building a large site that many, many people use. My compensation is at least in the top decile of both programmers in the US and residents of the city where I live. And one thing that was key to me getting a flood of offers from both large companies and start-ups a few months ago was developing domain-expertise in JavaScript and becoming proficient in several frameworks. Putting up projects on github and contributing to others played a role, too.

There is a high rate of unemployment in the US right now. As a result, many, many people are trying to break into the software world. For new graduates, there's a bit of an open door via internships but it's not at all easy in the general case. I've seen many talented people struggle for months to break in and then suddenly get a flood of offers. There's clearly a good degree of herd behavior involved.

Without the specific framework skills that I had, companies would have had a very long list of applicants to consider before getting to me. And both understanding the frameworks and doing well in the technical interviews required some fairly deep understanding of the language. Yes, the company you work for and the team you're working on have a great deal to do with your compensation. But both of those things are heavily influenced by how skilled you are in what technologies, especially for typical engineering roles. Knowing the right stack can open doors for networking around the front-door, too!

>They're getting compensated for non-Ruby things which happen to be expressed in Ruby programs." I call that winning rather than cheating but to each their own.

I wouldn't call that cheating but I would call it a poor anecdote to generalize from. Some people with a legal background translate contracts and earn a great deal of money for it, but that fact doesn't speak much to the market for translators as a whole or show there's no appreciable difference in career trajectories for translators of various languages.

I would say that perhaps both of you are missing one important component - specialisation. giving off the right signals for a particular niche enables you to credibly sell yourself in that niche (be it email-life cycle products or Angularjs coding)

I read your post from a year ago - you mentioned three interviews, Ruby, ObjC and JS. I would guess that today you would not dream of going to the first two - simply because your strengths lie in JS.

You have specialised - and as such become more valuable. But you could have specialised in many things other than language and still gotten good jobs. A specialist commands more money, due to scarcity and percieved increase in the probability of success.

However I still think patio11 is also right - of two equally qualified specialists, one that is better at marketing and promotion and negotiation is going to do drastically better.

But no matter how good Ramit Sethi is on negotiation, if he goes for a C++ job he is not going to beat out a specialist even if the specialist just says yes to the first offer.

(Little assumption there about Ramit's C++ skillz)

You could however have picked Ruby, PHP, Python, Haskell, Java, C(++), Objective-C (holy crap, Objective-C), Scala, Clojure etc to deep-dive on and would have been just as employable.

To convince me otherwise, you'd have to make the case that all of my professional connections are conspiring to deceive me or that I'm experiencing hallucinations on a near-daily basis and need professional help.

Objective C would have been very strong as well. Many companies of all sizes, including my current one use it. It would probably have taken a successful app on the app store or a stronger resume in order to get the kind of interest I did from top tier companies. Ruby would have lead to openings, but probably wouldn't have done much for me my interviews with Google. Java is used all over the place but from what I've seen, few junior devs without a degree break into the better work. Haskell would have been absolutely horrible--I'd have been competing with freakishly smart people for a small number of low-paying jobs!

The beauty of JavaScript is:

1) It's in the front end of every web stack, so nearly everyone needs it.

2) The MEAN stack (which includes Node and Angular) is a fast rising platform with few people competent in it. Even knowing "old" frameworks like Backbone can lead to a lot of opportunities.

3) In general, there is a bit less conservative of a culture among JavaScript programmers. Java/C/Python shops are more likely to care about pedigree and formal credentials.

And salad. I don't have a link for it but I think salad is huge.

There are tons of other things to do but I don't generally do them. I eat about 4000kcal a day, often go out drinking with my friends, don't sleep enough, and I'm often a workaholic. But I exercise and I eat vegetables.

I don't want to imply maliciousness here, so I'm going to call this an example of unknowingly bad statistics (which, sadly, seems to be the default in most places). Bonus points for the bar (!) chart that starts at 90,000 and looks like ActionScript is twice as profitable as the rest of the languages.

With data like that, I'd imagine the only sort of data you could trust would be the mean, since I'm guessing its much harder to be wrong about relative income levels between large groups than it is to be right about actual income numbers.

What the author tries to get at is a precise quantity, namely the average salary for each language. However, we cannot measure that quantity directly, so taking samples (from a good source) is as good as it gets.

The easiest assumption about that data is that it follows a normal distribution, which does have a mean, but also a standard deviation; both of these are required to talk about any meaning of the result. (If the normal distribution is not a good fit things may get more complicated.)

What I'm saying is that providing just means is not a ballpark way of doing statistics, it is wrong. The statistical ballpark is the normal distribution, and maybe a value ensuring that it is at least somewhat appropriate to use that one.

I was trying to say something along the lines of "once you've played with rapleaf, you won't care what the stdev is", because rapleaf's data isn't good.

The standard deviation here isn't going to be the standard deviation of programmer salaries -- it will be the standard deviation of rapleafs estimates. Which as I previously mentioned are horrible, and not particularly interesting.

I agree with the author that Haskell is estimated at a lower rate because it's academic. I think the reason we see higher salaries for older languages here is that rapleaf must be using age as an input (with makes sense in some fields).

> The only sort of data you can trust is the data itself.

Agree. Again, here there is no data. It's gibbs sampled noise from shitty models.

> Providing the mean of data is providing a sum value a person thinks is useful to convey the shape of the data, and the mean in particular is unsuitable at conveying shape on its own.

I don't think anyone here is confused about the question of the mean showing the shape of data.

> The easiest assumption about that data is that it follows a normal distribution

Salary most certainly does not follow a normal distribution. I don't understand how you came to write what you wrote without knowing that. It's a classic example of the exponential distribution.

(To be fair, salary estimates from rapleaf do seem to follow a normal distribution :p maybe you can guess why? [hint, it's a phrase I used earlier that starts with "gibbs sampled noise from" and ends with "shitty models"])

Since they show the minimum and maximum we can judge the overall spread, the mean tells us...well...the mean and first and second quartile lets us judge how close data is clustered around the mean.

See http://gnuplot.sourceforge.net/demo/candlesticks.html for gnuplot examples.

It would make sense perhaps to use standard deviations and means for some data, but in cases like this I think quartiles and medians make more sense.

I suppose I am looking for mathematically faithful whilst still Omnigraffle good looks

Cheers

For example, here's a histogram of ages of passengers of the Titanic: https://www.statwing.com/demos/titanic#workspaces/21

Or rents in the bay area: https://www.statwing.com/open/datasets/034b4af16d50a0ad35f1a...

Gives a real nice feel for the data.

These histograms are lacking in that they don't actually have the mean line or std devs on the plot itself; my general point is that if the goal is to get across a distribution, a histogram is the best way to do it, perhaps aided by markers for mean, median, std dev, etc., as the case merits.

Disclosure: I work at Statwing.

They're typically used for confidence intervals or standard error, but you can theoretically use them with any measure of variability as long as you're clear.

When I make charts like this, I always let the X-axis be zero. I find it confusing to look at a chart and not immediately know the percentage difference without using a calculator. With the X-axis at 0 you can immediately tell the proportional differences.

It's like looking at the intra-day variations of a stock's price, and thinking "Whoa! What happened here?!". Then you zoom out and it's a completely straight line.

I could assert the following from the data:

* ActionScript developers are horribly underpaid, but more likely to marry lawyers, doctors and bankers.

* Haskell developers are relatively well paid, but more likely to live alone or with a stay-at-home parent.

* Pythonists get roughly the same salary as Haskell developers, but their partners are all low-paid key workers.

This is quite easy to check, Google: living costs Cluj London

http://www.expatistan.com/cost-of-living/comparison/london/c...

(Don't trust information about cities with too few data points.)

Most commercial Haskell jobs are in finance -- where you don't get to contribute code to github. That leaves the PhD students and open source folks, shifting the data sideways.

Cool - do you have any articles/references about that?

Seems like more than a few quant shops advertise that they use Haskell.

I only wonder, where is XSLT usually used? Can anyone outline the most typical types of projects and environments?

We used to automatically convert SQL queries into XML using the AS column naming (like SELECT p.Id, p.Name, k.Id [kids\kid\@Id], k.Name [kids\kid\Name] FROM Person p JOIN Kids k ON k.FatherId = p.Id).

Then we could transform server-side to send down the HTML as well as do client-side updates in javascript by sending XML and the running the XSLT clientside to do partial updates (you can specify which part of the XSLT you want to run).

Worked pretty well as at the time, most browsers ran XSLT much faster than they ran Javascript.

I even got a pretty funky pivot table working in it that could handle 10,000s of rows when in javascript it would die after a 1,000 (we're talking IE6/7 era here).

There's actually a Daily WTF article where someone posted Sketchers.com's use of XSLT as a WTF and a lot of people chimed in in the comments that they did this and it was actually really good and not a WTF at all:

http://thedailywtf.com/Articles/Sketchy-Skecherscom.aspx

Note the featured comment was a response from the lead dev!

As for what situations in industry, our use was pretty uncommon as you can see from the WTF, but it's often used to transform XML in one format to another so they can get different systems actually talking to each other.

XSLT is kind of 'declarative', but it has ifs, switches, ... They probably didn't start out with the plan to implement a programming language with xml tags, but they did. It's horrible.

Edit: XML Schema is horrible as well. This is how you define an element with string content, and one attribute (which is VERY basic):

  <xs:element name="myElement">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute name="myAttribute" type="xs:string" />
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <myElement myAttribute="xs:string">xs:string</myElement>

    <xsl:if test="x">template</xsl:test>

    (if eval(x) (apply-template template) nil)

XML Schema tries to validate both the tag hierarchy and the contents, which requires data types and complicated definitions. So much overkill...

DTD and XPath are actually very nice and simple. This is the DTD equivalent of my XML Schema example above:

  <!ELEMENT myElement (#PCDATA)>
  <!ATTLIST myElement myAttribute CDATA>

Hand editing XML schema files is too much of a pain.

    <element name="myElement">
      <attribute name="myAttribute">
        <text/>
      </attribute>
      <text/>
    </element>

https://github.com/mikecardwell/email-privacy-tester/blob/ma...

The cool thing is, I initially wrote the application in Perl. I then re-wrote it in NodeJS, but was able to re-use the same stylesheet as it's language independent.

This sounds great in theory. But the problem is real world business requirements don't work that way. Real specs are never a straightforward declarative transformation. They always include bells and whistles and rhinestones that don't fit into XSLT. Loop over this set and suppress records where this field matches the previous record (state!), or include pagination, or call somebody's web service in the middle of it to display today's stock price, or grab the user's preferences for colors and time zones. (All real examples from a job I had with XSLT once upon a time.) XSLT doesn't do any of that and isn't supposed to. So you add another layer of data munging in whatever produces the XML before the XSLT operates, or hack it in Javascript afterwards, and either way now you have two problems.

Maybe XSLT skews high for income because it takes huge sums of money to get programmers to even touch the thing.

http://www.w3.org/TR/xslt

IIRC, it actually is turing complete (or nearly powerful), and it works in the paradigm of functional programming. Have done a large-ish project with it circa 2002-2004.

>I only wonder, where is XSLT usually used? Can anyone outline the most typical types of projects and environments?

Well, it's used a lot in the enterprise, where there is also a lot of XML.

http://www.rapleaf.com/about-us/faq/#where

"Rapleaf aggregates consumer data from data providers, cleanses it and maps it to emails, and ultimately makes it accesible through our easy to use Append portal and API. We partner with dozens of large and small data companies to aggregate data that we ultimately anonymize and tie to email addresses. We source it from only legitimate data bureaus who adhere to the highest consumer privacy standards -- sources that give consumers appropriate notice and choice about sharing their information and have opted in to make their data accesible."

What? Are they claiming to know the salary of all the github users used in this study? Were the users filtered down to those who had income data available? Because if so, that's a really weird (bad) selection technique. If not, what is being done with users whose income data is not available? Also where the hell is rapleaf getting their data?? This whole thing confuses the heck out of me, someone please help.

Is there really any way to correct for the fact that not all the data is going to be available? It certainly doesn't exclude a sampling bias, which I did mention in the post, possibly not aggressively enough.

IMHO experience in it translates well to Javascript, but I miss some of the features - especially the type system and the token API (which was much more consistently implemented than the various JS deferred systems).

Language doesn't really seem to be too big a variable, it affects the income level by typically less than 10%

Are people really making that much around here? Why are you on HN then?

> Why are you on HN then?

Why is this relevant? Is there a reason you'd expect higher-paid programmers to not be interested in relevant news?

I live in Uruguay, and program in VB6, VB.NET, and occasionally in Forte4GL, C# or PHP, but I'd make the same programming in Java or C# (it's an average local salary for a developer).

The way to make more money, as Patio11 said, is not to switch languages, but the "ability to use computer code as leverage to accomplish things that capitalism cares about"

https://news.ycombinator.com/item?id=6249373

If I made $100K, I wouldn't mind reading HN either :) (I know people that make orders of magnitude more and who occasionally browse it, or even post).

I barely manage on 24K for me and my girlfriend (made some bad decisions though).

I've heard rent and cost of living is cheaper in Poland than in Uruguay - we're still in a housing bubble here, and it's close to the most expensive country on earth for some stuff (example: cars).

As many mentioned, 100K is a lot, but you have to take into account cost of living.

Can't believe Uruguay is 50% more expensive to live in than Poland, used to be the other way round a decade ago.

We still have a housing bubble, that accounts for the ridiculous rent - just across the river from Montevideo, in Buenos Aires, rent is 50% cheaper.

The economy is pretty strong at the moment, so the exchange rate for us is favorable, that means cheap imports, but relatively expensive local stuff (especially bought in USD).

However, there are stiff trade tariffs, so we can't import cheap foodstuffs, and local ones are pretty expensive - mostly labor went through the roof, and we aren't that much automated yet.

The left-wing government imposes taxes on everything - left-wing voters would say that most were left over from other governments, but they were added upon and expanded.

An employee is extremely expensive due to all the added social security stuff - close to 100% over the salary the worker receives, and very hard to fire. While the take-home salary is lower, a restaurant employee is probably more expensive in Uruguay than in the U.S. (and more expensive to replace)

Same for other stuff, taxi drivers, etc.. are more expensive.

Gasoline is more expensive than in Europe, basically twice as much as in the U.S., utilities are not subsidized as much as in other Latin American countries, and very inefficient, so they're a lot more expensive than in the U.S. or Europe.

Clothing is taxed absurdly, there's now a 200 dollar allowance for imports, which are basically 3 to 4 times cheaper.

We also have some ridiculous bureaucracies in place that impose a huge burden on buying and selling property (housing, cars), creating huge market inefficiencies.

The differences with, say, Argentina, are that they're subsidizing heavily - while cratering their economy, since they impose ridiculous tax burdens on exports (Soy, etc..) and have protectionist barriers which are hurting capital expenditures.

Brazil is almost as expensive as Uruguay. Other countries such as Chile or Peru are a lot cheaper, because they took much different approaches (with their pros and cons of course), and other countries have an "informal" economy where they don't care that much about nominal taxes and legal system.

As a dev your money buys 50% more and yet devs are in such demand that unemployment is under 3% in the sector. Because of this you can easily beat all the salary benchmarks in this article and have a four bedroom house too.

It seems like this article is biased towards California or New York salaries. I once jokingly told a SF based recruiter that $55k might not seem too much, but those aren't California dollars, which are worth less than Pittsburgh dollars. If I wanted to make six figures right now, I'd probably move.

With a range that small, IMHO nothing significant can be derived.

It's not like the range is $50k to $150k.

I've seen real world programming jobs in the U.S.A. everywhere from $25,000 up to $250,000. Everything you get is closely clustered around $100,000k and when you consider the sample size I;m nit sure any of these mean anything.

PS: I actually think XSLT is a brilliant application of some cool ideas - putting them to work in (e.g.) grammar compatibility, it's just, like XSD, using XML itself as the syntax (e.g. i < 10 pls shoot me) and lack of helpful conventions (e.g. the empty stylesheet should be the identity transform, which you can then tweak).

This is probably something that many well-paid "XSLT developers" probably figured out early on. Develop your XSLT using ANYTHING except XSLT. ...and then they go on to create the "actual" programs to vomit the crapwads of excessive mark-up, and mystify those who made their own unfortunate beds and chose to consume this... this... XSLT.

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...

On a side note, I am always wary of the statistics Github gives for each repository where they estimate the percentage of code from different languages used (e.g., 90% Python, 10% C, etc.). In your opinion, how accurate do you think these are?

This all said, to extract a lot of power from Puppet you also have to script in Ruby, as to add additional functions not included in the Puppet core DSL requires you to write your own scripts.

The answer if I'm not mistaken is yes.

Personally I would be afraid to use Puppet as a substitute for my own configuration scripts. With the later, I'm required to know how things work at the shell level (and I use a small POSIX-like shell, not bash). But is this true with Puppet? I note it currently has some open security issues. But hey, if you are paid a competitive salary to write Puppet scripts, then there's little reason to learn more than how to do that.

I imagine Puppet probably saves you heaps of time.

Puppet is generally meant to be a replacement for configuration scripts. Essentially your Puppet scripts define a 'state' that you want the server to be in, thus if you want a user account called 'bob' you'd do something like this:

user {'bob': ensure => present, gid => '0', uid => '0', password => '<my encrypted password>', }

From this Puppet would do all the 'difficult' bits for you.

You mention that if you get paid to write Puppet scripts you wouldn't need to know how things work at the shell level. That is extremely far from the truth. You need a strong background and experience with shell commands, configuration layouts, shell/CLI methodology, etc. Without those you would quickly be lost both in terms of managing and dealing with Puppet and scripting in it.

Knowing Puppet is no replacement for Shell knowledge unless the extent of what you need to do with Puppet is understand you're using it to launch your Vagrant instances. Honestly there are things which to build out in Puppet would require extensive Ruby based functions and sometimes you really just need to fall back to using exec {} statements in Puppet (Meaning you're running shell commands from within Puppet). You can see some examples of this in the zookeeper module I built: https://github.com/justicel/puppet-zookeeper

Feel free to message me with Puppet questions and really, if you're just using Shell scripts I highly, highly recommend moving toward configuration-management (even if it's not Puppet), unless you only have one or two servers to manage.

Perhaps my time has been well spent mastering the shell at the expense of not learning Ruby and Puppet.

I have a need for keeping things small (too small for Ruby) so if I do need to use scripting languages other than sh for configuration, I'm planning to use Lua.

Here's a question for you since you mentioned Vagrant: I'm interested in hosting that allows me to run my preferred bootloader that reliably boots my DomU kernels instead of the PyGrub hack that AWS uses. I can deploy my systems as Xen kernels, as filesystem images that have a Dom0 that can run my DomU kernels, whatever. I can also run limited purpose kernels in userspace so I am not necessarily restricted to Xen as a means of "virtualization".

I want the AWS convenience of creating and launching an instance remotely rather than having to visit a datacenter. But I do not want anything to do with grub.

All my configuration is in the DomU kernel's embedded filesystem. When I change configs I simply edit the kernel source and recompile. My kernels recompile very quickly. I don't use kernels provided by third parties.

I'll probably have to build my own "cloud" to get things the way I want. Big itch; relentless scratching. Easy? No. But, so often that's how useful software comes into existance: because of someone personally finds the status quo inadequate.

The big question is: How significantly do these datapoints deviate from the null hypothesis of “all programming languages average the same pay).

on a side note: really? xslt is second on the list? i remember using it to create a code generator years ago. probably one of the poorer decisions i've made in my life :P

And if you're looking to be at the top of your game, one single piece of advice: master C. Once you've mastered it, you can pick and choose whatever else you want.

On the other end of the scale, I have almost six years in PHP and it's worth as much as a broken kinder egg for anything outside the LAMP stack world (and in some cases, within that world as well)

For all I know, they could all be the same (within error).

The unknown languages may appear on the outsides just because of the statistics: smaller sample size => higher variance in the sample mean.

Otherwise, I'm really, really, really underpaid.