So you're actually arguing for companies to hire employees who will likely produce negative output (their code will be so bad as to take not only their own time, but other programmers' time to fix) just to ...what, not hurt the feelings of the bottom 80 percent of developers?
Your analogy is poor: Hiring a bad programmer is an extremely high probability event, even in a broad pool of candidates as would apply to a high-end company like Amazon, not a low priority event. There have been studies dating back to the 70's that show a 10-20x skill difference between average and great developers. If you're going to pay roughly the same for a 1x as a 10x developer, wouldn't you want the 10x? So they tune their hiring process to skew that number as high as possible.
OP above may be an exception who fell through the cracks, not really ragging on them in particular.
I did know at least one person who applied to Amazon and who was rejected -- and rightfully so, in my opinion. His skills were sub-par, and the interview process detected that. Most others that I worked with while I was at Amazon were also above average; people I've encountered at other jobs have been mediocre by comparison, with the exception of a number of game developers I know.
> Most others that I worked with while I was at Amazon were also above average;
> people I've encountered at other jobs have been mediocre by comparison
> people I've encountered at other jobs have been mediocre by comparison
> people I've encountered at other jobs have been mediocre by comparison
> people I've encountered at other jobs have been mediocre by comparison
Here you are flogging the horse of Amazonian
exceptionalism, and your own, of course, whilst simultaneously deriding most of your current and former co-workers at other businesses as merely average.
This raises an issue that is just as important as technical prowess: emotional intelligence. I'd personally green light ten or twenty 'inferior' ( by your standards ) developers over 1 technically superior ( again, by your standards ), but arrogant and morale-destroying, primadonna.
> simultaneously deriding most of your current and former co-workers at other businesses as merely average
I specifically excepted game developers because they're an above-average bunch, but yes, I'm merely relating the facts as I see them. And honestly I think, based on the kind words I've received from many coworkers over the years, that many would actually agree with my appraisal, and would report that I was helpful in teaching them better ways to accomplish things.
>This raises an issue that is just as important as technical prowess: emotional intelligence. I'd personally green light ten or twenty 'inferior' ( by your standards ) developers over 1 technically superior ( again, by your standards ), but arrogant and morale-destroying, primadonna.
I'm assuming for sake of civil discussion that you're not implying that I am the arrogant, morale-destroying prima donna, because that would have been rude and confrontational.
>Sorry, but technical chops aren't everything. Soft skills matter just as much.
Technical chops can get you 10x-100x-infinitely more productivity. I've frequently accomplished things in minutes that other developers have been blocked on for weeks. Extremely poor soft skills can disqualify an otherwise good developer, sure. I'd block the hiring of someone who was excessively arrogant, abrasive, or otherwise a harm to morale.
But many really good developers are actually really polite and helpful in a team setting -- I've worked with multiple developers that fit that description. And good technical chops are much more rare than decent soft skills, so the former is what's grilled most in an interview. The soft skills show through as well, though, and can equally get you disqualified.
It does depend on the domain whether you really need a great developer. Presumably you work in a domain where you can get away with average developers. That's fine, you can get away with paying them less, go for it.
But that attitude is a big part of why most companies' servers seem to get hacked sooner or later. Note that you don't hear about huge security breaches at Amazon revealing tons of private customer data, despite the fact that they likely are the top target for any exploit that could be used against them.
And part of that is, in fact, that they have a higher bar for developers.
> So you're actually arguing for companies to hire employees who will likely produce negative output (their code will be so bad as to take not only their own time, but other programmers' time to fix) just to ...what, not hurt the feelings of the bottom 80 percent of developers?
I did nothing of the sort. In fact, I am arguing that your hypothetical negative output employee is much rarer that some people think.
> Your analogy is poor: Hiring a bad programmer is an extremely high probability event, even in a broad pool of candidates as would apply to a high-end company like Amazon, not a low priority event.
I have seen no data to support this. My personal experience does not support this.
> There have been studies dating back to the 70's that show a 10-20x skill difference between average and great developers. If you're going to pay roughly the same for a 1x as a 10x developer, wouldn't you want the 10x? So they tune their hiring process to skew that number as high as possible.
Citation needed. I have certainly seen this bandied about the Internet quite a bit, but the best the citations only claim a 10x difference between great and terrible developers, and even those studies are likely flawed.[1]
> I did know at least one person who applied to Amazon and who was rejected -- and rightfully so, in my opinion. His skills were sub-par, and the interview process detected that. Most others that I worked with while I was at Amazon were also above average; people I've encountered at other jobs have been mediocre by comparison, with the exception of a number of game developers I know.
I'm not saying people shouldn't be rejected or that bad developers should have jobs at places like Amazon. I'm saying that optimizing for false negatives because you are paranoid of false positives is an anti-pattern and that there are better ways to deal with false positives.
About the 10x difference in programmer productivity: it's a "leprechaun", a false myth emerged from misquoting of previous articles, poor review processes of the claims made and the generalized tendency to ape a scientific process in the software engineering world. Quite some tall claims but I have read a book that makes some good arguments supporting this as well as debunking a couple of these legends turned truths: https://leanpub.com/leprechauns
Mine does. Sometimes all the work done by a new developer ends up needing to be ripped out and redone. I've had that happen to me in the last year (a developer with high credentials and who answered the questions well!), and I just had a friend show me a developer who would copy-and-paste code from StackOverflow into different places until the result was what he wanted -- leaving all of the other references because he didn't really understand WTF he was doing.
>10x difference between great and terrible developers
It's 10x between great and average. The studies were done on actively employed developers at large companies, and also showed the 10x developers produced more easily readable code that was better optimized.
> ... a developer who would copy-and-paste code from StackOverflow into different places until the result was what he wanted -- leaving all of the other references because he didn't really understand WTF he was doing.
> Sometimes all the work done by a new developer ends up needing to be ripped out and redone. I've had that happen to me in the last year (a developer with high credentials and who answered the questions well!), and I just had a friend show me a developer who would copy-and-paste code from StackOverflow into different places until the result was what he wanted -- leaving all of the other references because he didn't really understand WTF he was doing.
How did that code get in there in the first place? Does your or your friend's companies not do code reviews, particularly for new team members?
> It's 10x between great and average. The studies were done on actively employed developers at large companies, and also showed the 10x developers produced more easily readable code that was better optimized.
I have the book. I've read it. Brooks has nothing other than conjecture on the subject. As Laurent Bossavit said in the Fog Creek interview,
> When I looked into it, what was advanced as evidence for those claims, what I found was not really what I had expected, what you think would be the case for something people say, and what you think is supported by tens of scientific studies and research into software engineering. In fact what I found when I actually investigated, all the citations that people give in support for that claim, was that in many cases the research was done on very small groups and not extremely representative, the research was old so this whole set of evidence was done in the seventies, on programs like Fortran or COBOL and in some cases on non-interactive programming, so systems where the program was input, you get results of the compiling the next day. The original study, the one cited as the first was actually one of those, it was designed initially not to investigate productivity differences but to investigate the difference between online and offline programming conditions.
Both my anecdotal experience and independent research into the subject corroborate what Laurent is saying in this interview.
>How did that code get in there in the first place? Does your or your friend's companies not do code reviews, particularly for new team members?
His company didn't do regular code reviews, no.
It's a game company. Game companies frequently don't follow the same set of best practices common in other industries. In part because typical game developers are a notch above app/web developers, though in part because it's just a lot more "wild west."
>Both my anecdotal experience and independent research into the subject corroborate what Laurent is saying in this interview.
All I know is that I was a better developer at 15 than most professional developers I encounter today, and I'm much better today than I was at 15.
I had no Internet to search for answers. I had no debugger. After I made a change to the game I was writing, it would take 30 minutes to run it (off of a tape). I had to reinvent the idea of linking because I couldn't edit all of the game in the memory I had available; I'd hand link the (ultimately four) app modules by setting constants. After running my game, it would take me 30 minutes to re-load the editor/assembler app and load up one of the modules of my game, so I learned to take careful notes of where things would fail so that I'd be able to fix them in the next editing cycle, and I learned to read the code and understand exactly what it all did and how it all interacted in my head so that it wouldn't break at runtime.
I found and fixed all the bugs in that assembly language game, and it was quite fun at the end, if not very deep (think Space Invaders crossed with breakout, with moving breakout bricks). It was more responsive and smooth in animation than many games are today, and it had no OS support: I was writing directly to the hardware. Hardware that totally sucked for doing games on, by the way.
I'd say 80% or more of professional developers today would have thrown up their hands at the assembly language manual and the hardware reference guide that I used to develop that game. My prior experience was in writing BASIC.
When I do web development or NodeJS or C++ or Python or Go today, everything is so easy by comparison that I can quickly put together much more sophisticated architecture in a few hours than a typical developer can do in weeks. The bar is much lower; people can accomplish simple tasks without much mental effort, and so many professional developers never learn the advanced design or debugging techniques at all.
There was a time when I hired a highly recommended team in the past few years, and they took easily 5x longer (and therefore cost 5x as much) as they should have based on the complexity of the problem I gave them. Painful lesson.
More importantly, I can design systems that are easy to use and understand for other developers, and I've received many compliments on the design of the most popular game library I wrote. You can see some of the game credits here [1]; there were over a hundred published games based on that library. At least half of those were developed by people who used the engine because it was free and good, not because the company I worked for was requiring it.
So I don't need external proof that 10x developers exist. NOTE I'm not claiming to be uniquely brilliant or a unicorn or a genius: I've also met many others who were easily as good or much better than myself at development, at Amazon and at other companies. But I'm at least in the top 5% if not the top 2% of developers, and at my level I really can do things that most developers just can't, and for the tasks an average developer can take on, a top developer can produce code more quickly and of better quality. Except for CSS. I hate writing CSS and I'm sure a CSS expert could write it more quickly than I can. :)
So I tend to speak out in protest at the idea that 10x developers don't exist. Being egalitarian and denying the skill range is popular because junior and average developers outnumber the experts. But it doesn't reflect the full reality. Just maybe 80% of the reality.
My personal experience doesn't support this either. There are many different kinds of skill and it's really a management issue to find the right roles for people, and to lead them in a healthy, humane, productive, and profitable direction.
There is much to be said for being a solid programmer who can sketch out a system; there's also a lot to be said for being an average programmer who is great at taking direction and methodical. Most companies need both types of engineers.
The arguments used by people at certain tech companies are like saying "it's so hard to become President of the United States that anyone who becomes president is obviously the cream of the crop'.
Imagine if we said the same thing about doctors or lawyers, or really any other profession. We all know that such generalizations are total BS.
Your analogy is poor: Hiring a bad programmer is an extremely high probability event, even in a broad pool of candidates as would apply to a high-end company like Amazon, not a low priority event. There have been studies dating back to the 70's that show a 10-20x skill difference between average and great developers. If you're going to pay roughly the same for a 1x as a 10x developer, wouldn't you want the 10x? So they tune their hiring process to skew that number as high as possible.
OP above may be an exception who fell through the cracks, not really ragging on them in particular.
I did know at least one person who applied to Amazon and who was rejected -- and rightfully so, in my opinion. His skills were sub-par, and the interview process detected that. Most others that I worked with while I was at Amazon were also above average; people I've encountered at other jobs have been mediocre by comparison, with the exception of a number of game developers I know.