They aren't making 22k/yr is his point though. A US based dev, who is working 60 hours per week, and not making 50,000$+ is doing something wrong (or chose low pay for a cool company etc)
Not necessarily. I think a lot of developers are subjected to employment myopia, because they tend to reside in areas with a high concentration of startups that pay well and have generous benefits and "perks." Outside of those areas, the space is dominated by corporate entities, consultancies and other bastions of bureaucracy. These companies can get away paying little because they are entrenched in their market and face very little competition for developers from startups.
People who live in or attend school in non-tech-centric cities are often screwed. There are few companies that offer attractive employment opportunities, and those that do are in a position whereby they can hire only the best. (To be honest, I think that this is true everywhere. All startups want to hire the absolute best, and only the best. It appears otherwise because the best are the vocal minority. For every Google engineer on HN that made 120k out of college and extols the ease of finding lucrative employment, there are probably several developers who went to community college or a state school that spend their days in a cubicle in a Palo Alto office park for 30k per year. We just never hear from those people.)
So, I think a more accurate statement is "A US based dev, who lives in New York or San Francisco who went to Stanford and who is working 60 hours per week, and not making 50,000$+ is doing something wrong."
I'm not so sure. I went to college in a non-tech city in the middle of the country and all of my peers, many of whom stayed local, were making at least $55,000 working for boring companies (USAA being a big one). This was not an elite school either.
No startups, nothing sexy but if any of those companies recruiting us offered <$55k they were laughed at.
So that does seem like the ballpark figure, with the following 2 caveats: I don't know how reliable Monster is for this kind of data, and I picked three cities off the top of my head roughly in the middle of the USA that I don't think of tech centres but I don't know how out-of-touch I might be in that regard.
I have a webapp that I built, that utilizes rackspace's API and chef. I have a chef server that I use for all my configuration management, I have a Rails app that I use to talk to my chef server to manipulate machines, or rackspace's api to spin up machines, and I am building "triggering" into it (low disk space, high CPU do X). I am able to change IP addresses, spin up a machine with a specific stack etc. Granted this isnt the default chef-server, but the ability to do all this stuff, and not be locked into AWS is there.
"Chef's Data Bags are incredibly useful." Very true. Not having to deal with a DSL (which is a personal opinion) is the reason I chose chef over puppet. Plus the IRC channel seems to be more active.
Is the AWS opswork link broken for anyone else? I tried to view their pricing/sign up, but received 404's.
I like data driven stuff. Though there's still a DSL. This is a large reason why I made http://ansible.cc, as I wanted the actual description of the policy to be data as well.
The author should hire a hacker for 100k/yr and let them work on whatever "is fulfilling" to them then, as it must be nice to look down on "optimizing your paycheck" when student loans exist. Fwiw making cool stuff and money are not mutually exclusive.
Another thing I think helps to explain how beneficial a good configuration management system is, especially if you have a good deal of systems, is to think of the servers as part of a botnet, and chef as the command and control.
Another benefit is abstracting away the management via a boxed in webapp. I manage about 2000 servers all running chef. Things like IPs, host files, firewall settings etc, are stored in databags, each server has its own databag that can be manipulated by a Rails app/the Spice gem (thanks Dan Ryan!). As someone who is tasked with managing all of this, along with bringing the less experienced employees up to speed, it is a way for me to normalize all of these things, and abstract things away enough that almost anyone can open a port up on any server, setup a rails app etc etc. And whomever takes over after me, will just have to read one set of docs, get an overview, and they should be able to follow the design patterns of how things are setup, much more easily then random ssh/bash scripts.
