Please don't attempt to operationalize this data by saying "I know PHP. If I learn Ruby, then I can get a $5,000 raise!" I talk to more engineers than is healthy, and many of them think that languages are the primary differentiator in salary (or some other metric of interest in their career). They're very mistaken. Far more salient are negotiating skill, location, what company you work for, where you're assigned in that company (profit center or cost center, favored project/division/etc or not, etc), and ability to use computer code as leverage to accomplish things that capitalism cares about.
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.)
I'm not sure I'd agree. By and large employers exist in language silos and will only hire devs with experience in their specific language, this means that there are distinct markets for different languages. That effect is amplified that entire sectors focus on specific languages.
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.
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.
ability to use computer code as leverage to accomplish things that capitalism cares about
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".
There are two factors that determine how much money you can make in a job such as programming:
- 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.
Very good point. It's not the language, it's how you market what you're doing with it.
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?
What are the distributions of the salaries among one language? Mean values alone are completely useless, give us some information about how you found the salaries out, what their standard deviations are etc.
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.
ActionScript has died out in many places, but still has heavy use, drumroll in the Federal Goveernment sector. I was working in a shop recently with a guy who ONLY knew ActionScript/FLEX...... pathetic, but his salary sure wasn't.
Those incomes look like fairly typical mid-level individual salaries (in the DC area, at least). I would expect the household numbers to be higher than listed to account for those that have working spouses.
Yeah, those are definitely all possible. I would have preferred to use personal income but it's not available via the API, and I figured that using household income was better than nothing.
Without knowing where the users are based, this data alone is pretty meaningless. Where I'm from in South West England pretty much all the programming jobs are Java (hence why I left), and you are lucky to get £40k. Spain and Portugal have even lower salaries. I'm guessing this is US based, but even then, I'm sure there is a lot of variation. Working in London as a Java developer in finance you could easily get over £100k.
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.
I can kinda understand why XSLT is one of the most expensive (on an intuitive level - as quchen said, it's not clear how the data was obtained for this post). Certain parts of it is a complete brainfuck. I worked on a small opensource project of mine once, where I decided to use XSLT to translate XML to HTML. I din't know much XSLT, so I started reading docs and eventually managed to accomplish my goal. However after struggling with it for a while, I realized it sometimes makes completely no sense. Or, to be more fair, it takes a rather different logic to understand it than I usually apply to programming languages... because, well it's not a programming language.
I only wonder, where is XSLT usually used? Can anyone outline the most typical types of projects and environments?
I just had an exam about XSLT, XML Schema, etc... this morning. My take-away is this. Pick any scripting language (python, ruby, php...) + templating engine and you'll avoid the World Of Pain that is XSLT.
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):
I use XSLT for https://emailprivacytester.com/ - The HTML part of the email that it sends is constructed from a small amount of dynamically generated XML, and a static XSLT file:
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.
The brainfuck is that it's purely declarative. It represents the transformation of one tree structure to another with no notion of sequential imperatives or associated concepts like variables and mutable state. This has some very distinct advantages: the execution can be very fast and parallelizable and predictable in space and time usage and secure in presenting nearly no attack surface for injections and overflows and such.
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.
I had to struggle with XSLT to transform XML into HTML a while back. Since it not intended to be a real programming language, I had trouble making it do the equivalent of something basic like iterating through a collection (recursion, ugh!). I can easily see how it would be a highly-paid skill because the lack of debugging tools (again, it is not a real programming language) made me want to curse MSFT and everyone else who were supporting XSLT at the time (way back) as the Second Coming of content publishing. If you ever want a headache, try reading the XSLT spec.
>However after struggling with it for a while, I realized it sometimes makes completely no sense. Or, to be more fair, it takes a rather different logic to understand it than I usually apply to programming languages... because, well it's not a programming language.
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.
You use it a lot in structured documentation business (think hardware manufacturer, military, pharmaceutical, ...). Where you publish some xml documentation into serveral output formats like HTML, epub, pdf, whathever..
Because XSLT is used to put a visualization of a data together with an XML-formatted document - very convenient for B2B. You may see content in a browser, and then extract info from the same page without XSLT.
At my workplace all of the legacy projects use XSLT as the templating language for our Cocoon (Java Framework) web applications.
Complete and utter clusterfuck, let me tell you...
I worked with XSLT for a few years a while ago, it's functional not procedural and that's the brainfuck you need to get your head around. It was also missing what seemed like basic functionality, like mutable variables.
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:
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.
"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.
The actionscript programmers may be getting paid higher (Mostly because the Flex enterprise hangover is still lingering), but in my experience the actual number of actionscript jobs available is sharply falling. I have been doing Flash/Flex dev for about 8 years now, and while my evidence is certainly anecdotal,i have gone from having tons of contract offers swamping my inbox to once every few months.Make no mistake, Flash and Flex IS dying. Javascript meanwhile is maturing remarkably, and it will soon be in a position where enterprise will seriously start considering it as a viable platform.
As a former actionscript programmer, this makes me cringe a little. My assumption is that actionscript is a new COBOL - tons of businesses rely on it, but now that it's looking like a dead end, the only way to fill those positions is to crank up the salary to compensate for the perceived dead space on a resume.
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).
Bare salaries don't tell you a whole lot. I suspect that most of the programmers in this dataset live in places like the bay area, NYC, and Boston. The cost of living in those areas are much higher than in much of the world.
> 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"
This is why many companies are getting out of the tech hubs. Costs are lower for the company and money goes further for the devs. Take Research Triangle Park in Raleigh, NC. A ton of companies have dev centers there (Cisco, EMC, NetApp, HSBC, Fidelity, Deutsche Bank, Verizon, IBM, John Deer, ConstantContact, iContact, SAS...).
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.
Perhaps my mistake was working for academia (support staff, not academic) but I make a bare fraction of that. (and for comparable work to what I've done elsewhere in industry.)
I would say location weighs heavily on average income as a programmer. For example, the average dev salary in the midwest might be more like $50,000 and anything approaching $100,000 being very high end.
Given the sample size here I don't think this means anything.
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.
This is absolutely useless. Emacs Lisp? Really? XSLT? What? CSS? Woah. I love that the internet has made it easy for anyone to share their opinion, I hate when noise is presented is as useful information.
After just reading the headline the first thought I had was "the comments are going to seriously question the statistical basis used" I was not disappointed.
The article lists household income, which makes it just about useless. Household income will be higher if you are married. People who are married are more likely to chose a more stable job working for a large corporation. Such jobs require languages more like Java, and less like Haskell. Such people might also have less spare time to play around with new languages due to family engagements, or a dozen other differences, all masked by this chart.
±10% is almost nothing... OTOH, maybe I could do XSLT, if I just took some nausea pills...
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).
Remember as patio11 says the most important and valuable skill is not making money for your employer but being able to enable them (and eventually other companies, as your own entrepreneurial soldier of fortune) to make more money.
[+] [-] patio11|12 years ago|reply
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.)
[+] [-] ig1|12 years ago|reply
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.
[+] [-] xiaoma|12 years ago|reply
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.
[+] [-] edw519|12 years ago|reply
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".
[+] [-] BlobbleBlab|12 years ago|reply
- 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.
[+] [-] mathattack|12 years ago|reply
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?
[+] [-] olitreadwell|12 years ago|reply
[+] [-] ritchiea|12 years ago|reply
[+] [-] quchen|12 years ago|reply
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.
[+] [-] frobozz|12 years ago|reply
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.
[+] [-] siddboots|12 years ago|reply
[+] [-] JPKab|12 years ago|reply
[+] [-] erikkri|12 years ago|reply
[+] [-] AlisdairSH|12 years ago|reply
[+] [-] bpodgursky|12 years ago|reply
[+] [-] lucaspiller|12 years ago|reply
[+] [-] rplnt|12 years ago|reply
[+] [-] dons|12 years ago|reply
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.
[+] [-] theorique|12 years ago|reply
Cool - do you have any articles/references about that?
[+] [-] snitko|12 years ago|reply
I only wonder, where is XSLT usually used? Can anyone outline the most typical types of projects and environments?
[+] [-] AlexanderDhoore|12 years ago|reply
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):
Just off the top of my head, I could invent something better, like:[+] [-] mike-cardwell|12 years ago|reply
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.
[+] [-] T-hawk|12 years ago|reply
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.
[+] [-] wallflower|12 years ago|reply
http://www.w3.org/TR/xslt
[+] [-] coldtea|12 years ago|reply
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.
[+] [-] xsace|12 years ago|reply
[+] [-] miga|12 years ago|reply
[+] [-] jbaiter|12 years ago|reply
[+] [-] mattmanser|12 years ago|reply
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.
[+] [-] sequoia|12 years ago|reply
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.
[+] [-] fbnt|12 years ago|reply
[+] [-] khalidmbajwa|12 years ago|reply
[+] [-] awkward|12 years ago|reply
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).
[+] [-] ck2|12 years ago|reply
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?
[+] [-] thedufer|12 years ago|reply
> 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?
[+] [-] GFischer|12 years ago|reply
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).
[+] [-] twistedpair|12 years ago|reply
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.
[+] [-] Mr_N|12 years ago|reply
[+] [-] canadiancreed|12 years ago|reply
[+] [-] mason240|12 years ago|reply
[+] [-] programminggeek|12 years ago|reply
[+] [-] jyap|12 years ago|reply
With a range that small, IMHO nothing significant can be derived.
It's not like the range is $50k to $150k.
[+] [-] PaulHoule|12 years ago|reply
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.
[+] [-] segmondy|12 years ago|reply
[+] [-] stewbrew|12 years ago|reply
[+] [-] talloaktrees|12 years ago|reply
[+] [-] kazagistar|12 years ago|reply
[+] [-] 6ren|12 years ago|reply
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).
[+] [-] regularfry|12 years ago|reply
[+] [-] wallflower|12 years ago|reply
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...