The 10x developer is not a myth (2013)
ybrikman.com
The 10x developer is not a myth (2013)
1–10 of 248 posts
Re: The 10x developer is not a myth (2013)
#2Companies like MS and google have sufficient data to tell us whether the 10x programmer is a meaningful term.
Re: The 10x developer is not a myth (2013)
#3I thought the perceived idea about the 10x developer was that he/she is 10x better than the average programmer, not the worst.
So even this scientific study (from the 60s) says that there aren't 10x developers according to this definition: the ratio goes down to sqrt(20), using the geometric mean, if a good-enough sample was chosen. Program size and program execution speed would put that ratio to sqrt(5) and sqrt(10), respectively.
Re: The 10x developer is not a myth (2013)
#4Re: The 10x developer is not a myth (2013)
#5and
"From years of experience, a great programmer will know that errors are much more costly to fix later."
So which is it?
Re: The 10x developer is not a myth (2013)
#6Re: The 10x developer is not a myth (2013)
#71. Those who are good developers 2. Those who can't write any real code (cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the years because they were not able to FizzBuzz)(25%-50% of the market)
The 10x comes from comparing (1) and (2) - although dividing anything by 0 is larger than 10x.
Re: The 10x developer is not a myth (2013)
#8I've certainly known some 1/10x programmers. I'm a 10x programmer by comparison.
Programmers writing features that add points of failures to previously working systems
Re: The 10x developer is not a myth (2013)
#9There are two kinds of developers: 1. Those who are good developers 2. Those who can't write any real code (cargo cult or cut&paste developers, e.g. the 25% who I didn't hire over the years because they were not able to FizzBuzz)(25%-50% of the market) The 10x comes from comparing (1) and (2) - although dividing anything by 0 is larger than 10x.
Re: The 10x developer is not a myth (2013)
#10Yes, if you have a small team of say 10 people, a very competent lead engineer can make all the difference by setting up proper testing, SCM, CI, etc. i.e., by choosing the right tools and people for the job.
However, as soon as you have a slightly larger team, these decisions will usually not be made by one single person. If you have a large project with dozens or hundreds of engineers, you'll have dedicated teams for some of these tasks, making their own desicions.
In my opinion, the most important thing then is to spot anything that will make things go haywire, communicate them and convince the right people that this has to be fixed. If you force a new porgramming language onto the whole team because it makes you, the 10x engineer, more productive, you might face endless discussions, additional training costs and a big backlash ("why do we need this now?") from the team.