3 ms·

> 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 ti

> 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. [1] http://blog.fogcreek.com/10x-programmer-and-other-myths-in-software-engineering-interview-with-laurent-bossavit/ http://blog.fogcreek.com/10x-programmer-and-other-myths-in-s...

eecc 10y ago
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 https://leanpub.com/leprechauns
- SomeCallMeTim 10y ago
  I personally have at least a 10x productivity advantage over an "average" dev on some tasks, so I guess I'm a leprechaun? The canonical reference is here: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_surgical_team https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur...
  - azeirah 10y ago
    :|
biocomputation 10y ago
> My personal experience does not support this. 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.
SomeCallMeTim 10y ago
>My personal experience does not support this. 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. >Citation needed. [1] [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_surgical_team https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur...
- vonmoltke 10y ago
  > 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. > [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur.. https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur.... The relevant quote: > Brooks muses 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.

eecc 10y ago

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 https://leanpub.com/leprechauns

SomeCallMeTim 10y ago
I personally have at least a 10x productivity advantage over an "average" dev on some tasks, so I guess I'm a leprechaun? The canonical reference is here: https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_surgical_team https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur...
- azeirah 10y ago
  :|

biocomputation 10y ago

> My personal experience does not support this. 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.

SomeCallMeTim 10y ago

>My personal experience does not support this. 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. >Citation needed. [1] [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_surgical_team https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur...

vonmoltke 10y ago
> 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. > [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur.. https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_sur.... The relevant quote: > Brooks muses 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.