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.
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_sur...