[microarchitect]

Some thoughts on this issue. Some of these have been expressed by others like pg already.

1. Workers are not a commodity and not interchangeable. You can't a take a network-layer programmer who got laid-off from Cisco and ask that person to work on big data and reasonably expect success.

2. I suspect a lot of tech workers are not motivated by money as long as it's above a threshold. I know for a fact that I've taken jobs that paid me as much as 25% less because I got to work on "cooler" stuff. This also fits in with the stories of Google's early days when they actually paid less in dollar terms than MS but were able to lure workers away from MS because they had better "perks" and more interesting technology.

2a. If progammers were optimizing for money, most of us would be working for wall Street, and we'd all be contracting in our free time instead of building open source apps. Clearly this isn't happening.

3. Anecdotally, I know for a fact there is huge demand for competent programmers/engineers because I have standing offers from multiple employers. The reason for this is that a good programmer is orders of magnitude more productive than an average programmer so good managers will move heaven and earth to get their hire. On top of this, an average programmer in a good team will have effective negative productivity. So restricting your supply pool even a little bit can leave you with a drastically less productive team.

[debacle]

> an average programmer in a good team will have effective negative productivity.

I have a qualm with that statement, I think. Do you have anything to back that up? It doesn't make logical sense to say that "If I have four programmers and they give me nine megawarbles of productivity, and I add a fifth programmer who can only create one megawarble of productivity, I will have a team that only generates eight megawarbles of productivity."

Too often, programmers are drawn into this romantic idea of being a 10x programmer, but I can honestly say that, in my experience, there are more 10x programmers out there than there are 10x programming problems. The IT world needs more data janitors than it needs data scientists.

[clueless123]

A couple of points on negative productivity

0. There is a cost on the communications between team members, if the team is larger the cost is larger 1. There are costs on integrating (in some cases re-working) sub-par code that does not fit with the rest of the team

If the programer is just average, the impact is not that terrible but it exists, but if the programer is actually bad, I can tell you from personal experience that the costs will be very significant.

[BerislavLopac]

Programming is knowledge work. If someone is "worse" than another, it means that they less knowledge. If you have four programmers with a similar amount of knowledge, and one with much less knowledge, to gain more knowledge this one will have to go to the four, who will then spend time transferring knowledge instead of using it effectively. That's your Fred Brooks 101.

[gaius]

The key to this is understanding that engineer A is a 10x guy at interfaces and engineer B is a 10x guy at databases yet the way real work happens is that sometimes they will both be working on the interface and sometimes they will both be working on the database. In other words, there are a lot of people who think they're that "10x programmer", and are, but only for a fraction of the scope of a real project.

I used to work with one guy who was an absolute wizard at performance tuning. Helpless as a newborn lamb tho' when it came to setting up a new test environment, he was a 10x guy at what he did, but a 0.1x guy at "restoring last night's backup from tape" despite having all the privs he needed to do it...

[jiggy2011]

Depends if you mean a programmer who is average relative to the rest of the team or a programmer who is average relative to all programmers but who is on a team of significantly better than average (therefor bad by the standard of the team).

A programmer who is worse than everyone else will tend to produce bugs that they themselves can't fix and also make poor design decisions. Both of these things will make things harder for the rest of the team.

In my experience there's a lot more bad programmers who produce lots of buggy code than produce low quantities of good quality code.

[dkl]

I agree with the GP only in this situation: there is little or bad management. I think an average programmer can definitely be very productive (relatively) in a team with more experience and skill. I've seen it (both ways).

[mathattack]

On points 1 and 3 - people are not interchangeable, and good ones are in tremendous demand.

I think the big difference between 1999 and now is back then anyone who could spell HTTP could get a great offer, because there was a lot of dumb money chasing people. The industry has learned it's lesson. Now it's very hard for a Marketing person with a personal website to pass themselves off as a web guru.

It's also much harder for people with "bad signs" on their resume to garner interest. Most of the top companies don't look at 10 years of internal IT work at the same firm as a plus. And when you get 20 years, like it or not (and I don't!) there is age discrimination.

Net - there are lots of new jobs for talented new people, but it's wrong to assume that people losing their jobs can naturally fit into them.

[gaius]

ou can't a take a network-layer programmer who got laid-off from Cisco and ask that person to work on big data and reasonably expect success

I think you massively underestimate the complexity of routing and equally overestimate the difficulty of "data science" there. I'll wager a guy that can program router firmware can turn his hand to anything.

[sjg007]

I imagine the perk at early Google was cheap stock options.