4 ms·

I see they repeat the myth about a great developer being ten times as good as a mediocre one, even though the actual reference they point towards in support of

I see they repeat the myth about a great developer being ten times as good as a mediocre one, even though the actual reference they point towards in support of that statement disagrees with them.

busterarm 8y ago
And the myth that great developers are always trying out the latest new thing.
aceBacker 8y ago
BUT, an average developer is better than a developer who just puts in their 8 hours a day and never learns new skills. The people who you make a point to address an issue with and then a few weeks later you see they created the same issue again. I think the key is to actually care about your work. You got even a little bit of that and you're fine.
hvidgaard 8y ago
I don't think that a single developer can be thought of as 10 times as productive. But a good developer absolutely can have a tenth of the "collateral damage" after releasing a product with less need for support, fixes, and refactoring. If I think of it as team dynamics, I can see a single developer making that much of a difference. On his own (s)he is not that much better than your average developer, but in a team (s)he can lift the team with his/her experience and really make them significantly better. 10 times better is probably a stretch, but measurably better at least.
ludston 8y ago
I know that this is not a myth because I have seen it. Just today I saw someone reviewing some piece of work that had taken another developer two weeks to implement, throw it all out and solve the same problem with only a few lines of code. The speed improvement isn't like, "This person can type 10 times faster than everyone else", but more like, "This person doesn't get stuck or waste time chasing dead-ends". Possibly your code-base needs to have more than a certain level of complexity before developers start getting stuck like this.
- zimpenfish 8y ago
  > piece of work [...] two weeks to implement, throw it all out and solve the same problem with only a few lines of code I've been in similar situations and, invariably, the "few lines of code" is inscrutable nonsense that no-one else will be able to maintain (and often even understand.) I can write obtuse one line "clever" hacks to solve problems but I'm keenly aware that a) I'll have forgotten how it works in an hour and b) some poor bastard (which might well be me) will have to maintain it for N years after I'm gone.
  - techopoly 8y ago
    Right, and the product owner will expect all future maintenance to be done as quickly as the one-line clever hack that took 15 minutes but didn't encompass the edge cases.
    - alexandercrohde 8y ago
      Some 10x engineers just say "No" to product owners. If you let a product owner to convince you that you need an .xls export rather than .csv for internal use (this is a real-life example!) you may add a week+ of work/maintenance versus the time it takes me to explain "no."
      - zimpenfish 8y ago
        > an .xls export rather than .csv for internal use Presumably this was a trivial data dump and not something like a report that could have benefited from, e.g., embedded formulas, multiple sheets, etc.? (I've produced exports with the latter and the enhancements were greatly appreciated over the plain old CSV export.)
    - dsego 8y ago
      From my experience it's the opposite, a mediocre programmer will create way more code than needed because they don't try to understand, but just blindly copy conditions and cases they see in the surrounding code (cargo cult). This leads to more convoluted code that looks clever and covers edge cases that wouldn't exist if it was coded properly or if they pushed back. Then the experienced programmer comes in and rewrites it to solve the actual problem with as few lines as possible.

I see they repeat the myth about a great developer being ten times as good as a mediocre one, even though the actual reference they point towards in support of that statement disagrees with them.

busterarm 8y ago

And the myth that great developers are always trying out the latest new thing.

aceBacker 8y ago

BUT, an average developer is better than a developer who just puts in their 8 hours a day and never learns new skills. The people who you make a point to address an issue with and then a few weeks later you see they created the same issue again. I think the key is to actually care about your work. You got even a little bit of that and you're fine.

hvidgaard 8y ago

I don't think that a single developer can be thought of as 10 times as productive. But a good developer absolutely can have a tenth of the "collateral damage" after releasing a product with less need for support, fixes, and refactoring. If I think of it as team dynamics, I can see a single developer making that much of a difference. On his own (s)he is not that much better than your average developer, but in a team (s)he can lift the team with his/her experience and really make them significantly better. 10 times better is probably a stretch, but measurably better at least.

ludston 8y ago

I know that this is not a myth because I have seen it. Just today I saw someone reviewing some piece of work that had taken another developer two weeks to implement, throw it all out and solve the same problem with only a few lines of code. The speed improvement isn't like, "This person can type 10 times faster than everyone else", but more like, "This person doesn't get stuck or waste time chasing dead-ends". Possibly your code-base needs to have more than a certain level of complexity before developers start getting stuck like this.

zimpenfish 8y ago
> piece of work [...] two weeks to implement, throw it all out and solve the same problem with only a few lines of code I've been in similar situations and, invariably, the "few lines of code" is inscrutable nonsense that no-one else will be able to maintain (and often even understand.) I can write obtuse one line "clever" hacks to solve problems but I'm keenly aware that a) I'll have forgotten how it works in an hour and b) some poor bastard (which might well be me) will have to maintain it for N years after I'm gone.
- techopoly 8y ago
  Right, and the product owner will expect all future maintenance to be done as quickly as the one-line clever hack that took 15 minutes but didn't encompass the edge cases.
  - alexandercrohde 8y ago
    Some 10x engineers just say "No" to product owners. If you let a product owner to convince you that you need an .xls export rather than .csv for internal use (this is a real-life example!) you may add a week+ of work/maintenance versus the time it takes me to explain "no."
    - zimpenfish 8y ago
      > an .xls export rather than .csv for internal use Presumably this was a trivial data dump and not something like a report that could have benefited from, e.g., embedded formulas, multiple sheets, etc.? (I've produced exports with the latter and the enhancements were greatly appreciated over the plain old CSV export.)
  - dsego 8y ago
    From my experience it's the opposite, a mediocre programmer will create way more code than needed because they don't try to understand, but just blindly copy conditions and cases they see in the surrounding code (cargo cult). This leads to more convoluted code that looks clever and covers edge cases that wouldn't exist if it was coded properly or if they pushed back. Then the experienced programmer comes in and rewrites it to solve the actual problem with as few lines as possible.