4 ms·
If the problem was oversupply, we wouldn't be getting the cushy salaries and benefits we do. I think the issue is more that it's pretty easy for people with no
by Analemma_ 7y ago
If the problem was oversupply, we wouldn't be getting the cushy salaries and benefits we do. I think the issue is more that it's pretty easy for people with no programming ability to appear competent on a resume, especially to a clueless HR rep or headhunter. There are a lot of people out there whose backgrounds look good on paper who can't solve FizzBuzz...
- codingslave 7y agoI think the cushy salaries come from the fact that programming done right is extremely profitable. So the capitalists toss a chunk of money to the engineers.
- lkrubner 7y agoFor most programming jobs wages are lower now than in 1995. Back then, I had many friends who were charging $100 an hour just to build VisualBasic apps and they had more work than they could handle. And Phillip Greenspan has written that his company, from 1996 onwards, offered $100,000 to recent college grads. That was really good money back then, especially if you wanted to buy a house. Wages right now only look good compared to where they were during the depths of the Great Recession. Over a longer time frame, wages look terrible, except for certain jobs at FANG companies.
- ummonk 7y ago100k then would be 170k today, in line with (if not slightly lower than) entry level comp at FANG companies.
- alteria 7y agoThat's a TC number that includes vesting RSU right?
- lkrubner 7y agoThat’s my point. Ars Digita (Greenspan’s startup) was a small startup. You don’t see small startups paying 170k as a base salary nowadays. All available evidence shows that wages have fallen for software developers. If the market for software developers was tight, then we would see very different behavior from companies.
- deleted 7y ago[deleted]
- Benjammer 7y agoI think this point is really key, more than the general idea that "there isn't really a short supply of good programmers." It's imminently easy for a rich capitalist to tell the difference between a factory laborer who works hard and one who does not, than it is for them to say the same about an engineer; the evidence is plain as day in front of you. Longer hours, more sweat, quantitatively more physical tasks done, period. For engineers of most sorts, the signals are actually counter intuitive, a lot of the time. There's the easy cliche story of two engineering teams tasked to the same project (not necessarily even software only). Team A has a slow and steady road map, no drama, everyone leaves at 5pm, they never make any noise, mostly hit their deadlines, even if the deadlines are unambitious, etc. Team B always is fighting fires, huddled around someone's desk talking, always working overtime burning to make aggressive deadlines that are never quite reached anyways, always communicating with the wider company about status of issues and problems, etc. Which is the more effective team? Team B will definitely be "known" more in the wider company, and might have more individuals who respect them and think they are hard workers. If you took a "peer survey," Team B might actually still come out ahead. But they may still be a much less effective team for the larger business in a lot of ways.
- bulatb 7y agoHypothesis: There's such a flood of qualified labor that employers can afford to arbitrarily shrink the pool of applicants without significantly worsening their outcomes. Their behavior indicates that just the top N% of the market is enough to fill the needs of all selective companies. "Top" can be a semi-random filter, since the pool of basically competent people is much deeper than N. (There's also a much larger flood of people who aren't qualified, which definitely complicates the process.) All else equal, if employers simply stopped rejecting qualified applicants for arbitrary reasons, they could solve the "shortage" overnight and pay much lower wages that developers would still accept. But all else isn't equal. Their past decisions shaped the playing field, so now external-but-related factors like the housing market and competitors' responses limit their options in practice. They can't just take a bunch of people and drop wages, even though they "could", without disrupting other things that aren't worth disrupting. Edit: Too late to delete, but this is not a good analysis. Companies are clearly feeling some pressure to do something, but there are too many unknowns in this to draw the conclusion, and a ton of factors I've ignored.
- aidenn0 7y agoNot exactly. If every employer randomly threw out 80% of the resumes without looking at them, and then perfectly evaluated the remaining 20%, then you would expect that all qualified developers would have a job (they just might have to apply to several jobs to get an offer).
- bulatb 7y agoI don't think the filter is literally random. It's a poor predictor of success, applied inconsistently. Just from what I've heard and experienced, I'd guess that if N = Q (percentage of qualified workers), everyone in N would find some job as you describe. Alice gets Apple and Google but not Netflix, Bob gets Netflix but not Apple. Could Alice do Bob's job at Netflix, or vice-versa? Absolutely. Does Apple care they could have had Bob? Does Netflix care they could have had both? Not really. Everyone in N lands somewhere, eventually, enough though a better process could have had a better outcome overall. Maybe Alice really wanted Netflix; maybe she picks Netflix-like projects at Apple that aren't Apple's best use of her skills. Maybe that rejection shook her confidence or maybe she's distracted getting ready for another Netflix interview next year. (She's learned she has to study really hard at who-knows-what to prove she's capable of doing a job she's already doing.) Does Apple care? Not really. Her manager might, but not Apple. Inefficient allocation is death by a thousand cuts. The greater problem is when Q > N and the difference keeps growing. If you take the Googler joke of PhDs as protobuf jockeys at face value, that's where we've been for a while. But I don't know if we are.