4 ms·

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 imple

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.
- thr0awaz 8y ago
  or somebody rewrote object.sort() from scratch instead of looking at the documentation, which isn't necessarily a 10x engineering problem, it's more of a 1/10th engineering problem.
  - zimpenfish 8y ago
    Fixing that would definitely be one of the "good" cases of rewriting code into fewer lines. But it doesn't involve a "clever" solution (which is normally the problem), just a "smarter" one.
- GuB-42 8y ago
  Short code is greatly underrated. It doesn't have to be an "obtuse and clever hack", usually it just amounts to using the right tool for the job. For example, it is impressive how much code can be simplified by just using the correct API calls. Also, some language features are explicitly designed to address a specific problem, and yet they stay unused, even when the problem arises. As for your two points. - If you forget about how it works in an hour, you never knew how it worked in the first place. It can happen when you write code at random and tweak it until it passes the test. IMHO, that's the opposite of a clever hack. - I love to see clever hacks in code I maintain. Like everyone else I start going "WTF?!" but a few minutes later, it usually turns into "oh nice, I learned something today". To illustrate, this is the kind of code I like to read https://www.youtube.com/user/Bisqwit https://www.youtube.com/user/Bisqwit . This guy's code is short, clever, takes advantage of everything the language has to offer, and still manages not to be too cryptic. Note that these are educational videos and the author spends a lot of time to get to that level. I don't expect to see that in a typical project, but that's kind of an ideal for me.
  - zimpenfish 8y ago
    > If you forget about how it works in an hour, you never knew how it worked in the first place. Obviously I disagree. I'll have forgotten through a combination of being old, not being interested in that code any more, having spent an hour doing something else, and work not being important enough to take up rent-free space in my brain.
- ludston 8y ago
  In this case I can assure you that these "few lines of code" were much easier to understand, and more correct than the code that was being replaced. Basically, someone was trying to fix an IO error that they did not understand by writing a complex retry mechanism, even though the system already had a better and more correct retry system that wasn't being used for this. It wasn't a hack, so much as removing someone elses (unnecessary) hack that fixed the problem.
EliRivers 8y ago
The myth is the misinterpretation of the actual research; the myth is swapping "worst" for "median" in the comparison. The post in question makes this mistake; it compares best to "mediocre", but the actual page it references in support of itself gets it right, comparing best to worst. A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance. The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work. Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]
- ludston 8y ago
  I appreciate this follow up and information, so thankyou.

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.
thr0awaz 8y ago
or somebody rewrote object.sort() from scratch instead of looking at the documentation, which isn't necessarily a 10x engineering problem, it's more of a 1/10th engineering problem.
- zimpenfish 8y ago
  Fixing that would definitely be one of the "good" cases of rewriting code into fewer lines. But it doesn't involve a "clever" solution (which is normally the problem), just a "smarter" one.
GuB-42 8y ago
Short code is greatly underrated. It doesn't have to be an "obtuse and clever hack", usually it just amounts to using the right tool for the job. For example, it is impressive how much code can be simplified by just using the correct API calls. Also, some language features are explicitly designed to address a specific problem, and yet they stay unused, even when the problem arises. As for your two points. - If you forget about how it works in an hour, you never knew how it worked in the first place. It can happen when you write code at random and tweak it until it passes the test. IMHO, that's the opposite of a clever hack. - I love to see clever hacks in code I maintain. Like everyone else I start going "WTF?!" but a few minutes later, it usually turns into "oh nice, I learned something today". To illustrate, this is the kind of code I like to read https://www.youtube.com/user/Bisqwit https://www.youtube.com/user/Bisqwit . This guy's code is short, clever, takes advantage of everything the language has to offer, and still manages not to be too cryptic. Note that these are educational videos and the author spends a lot of time to get to that level. I don't expect to see that in a typical project, but that's kind of an ideal for me.
- zimpenfish 8y ago
  > If you forget about how it works in an hour, you never knew how it worked in the first place. Obviously I disagree. I'll have forgotten through a combination of being old, not being interested in that code any more, having spent an hour doing something else, and work not being important enough to take up rent-free space in my brain.
ludston 8y ago
In this case I can assure you that these "few lines of code" were much easier to understand, and more correct than the code that was being replaced. Basically, someone was trying to fix an IO error that they did not understand by writing a complex retry mechanism, even though the system already had a better and more correct retry system that wasn't being used for this. It wasn't a hack, so much as removing someone elses (unnecessary) hack that fixed the problem.

EliRivers 8y ago

The myth is the misinterpretation of the actual research; the myth is swapping "worst" for "median" in the comparison. The post in question makes this mistake; it compares best to "mediocre", but the actual page it references in support of itself gets it right, comparing best to worst. A 2nd edition of Peopleware summarises it; the 10x programmer is not a myth, but it's comparing the best to the worst; NOT best to median. It's also not about programming specifically; it's simply a common distribution in many metrics of performance. The rule of thumb Peopleware states is that you can rely on the best outperforming the worst by a factor of 10, and you can rely on the best outperforming the median by a factor of 2.5. This of course indicates that a median developer, middle of the pack, is a 4x developer. Obviously, this is a statistical rule, and if you've got a tiny sample size or some kind of singular outlier or other such; well, we're all adults and we understand how statistics and distributions work. Peopleware uses Boehn (1981), Sackman (1968), Augustine (1979) and Lawrence (1981) as its sources. [ "Peopleware", DeMarco and Lister, 1987, p45 ]

ludston 8y ago
I appreciate this follow up and information, so thankyou.