4 ms·

This post is flawed, starts with the wrong proposition that "10x programmer" means a programmer that writes 10x as much code, that is, it uses number of lines o

by drKarl 10y ago

This post is flawed, starts with the wrong proposition that "10x programmer" means a programmer that writes 10x as much code, that is, it uses number of lines of code as a metric which is a completely wrong metric (If programmers were paid for lines of code, copy-pasting would be best practice, and all kind of verbosity and unnecessary code or boilerplate, even dead code would be everywhere. With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs. So, a 10x programmer means a programmer who is 10x as productive, that is, delivers 10x as much features, fixes 10x as many bugs or not even that, since sometimes you have to do refactoring which improves the codebase a lot in several ways but doesn't provide as a result either features or bugs. Actually I would expect the mythical 10x programmer to produce LESS code for the same functionality, and most probably be reducing the amount of code littered by other lesser programmers and starting refactorings that would create abstractions, split classes and make the code more modular, that would have as a result deleting classes and methods, and overall reducing the number of lines of code rather than increasing it...

jl6 10y ago
I think a 10x programmer is someone whose efforts increase profits by 10x. A lot of people think they are 10x programmers because they can optimise something that nobody really cares about.
- caminante 10y ago
  I think a 10x programmer is someone whose efforts increase profits by 10x. Careful ;-). I think that falls into the same trap drKarl's critiquing. Someone spewing unnecessary lines of code can jack up their line count and bill more hours, thereby increasing profits. They aren't making complex problems disappear.
  - 1123581321 10y ago
    If you're in a billable hours environment, you can't be 10x as profitable by billing more hours. You need a higher billing rate (that is actually paid by clients). This is hard to get and keep if you are inefficient.
    - caminante 10y ago
      I agree that pulling it off requires help. That said, I've seen it happen where folks turn a (should be) 1 day task into a 10 day project. That's 10x more profitable. To be fair to the parent comment, I think he's getting at the super programmers that crack problems others can't. This capability provides competitive advantages. Maybe I'm talking about the other side of the table and did a poor job at that. Sorry!
      - 1123581321 10y ago
        Sure, I understand the gist of what you're saying (and what the parent comment was saying.) But the example doesn't work. Programmers at a consultancy/agency are probably billing 20-40 hours no matter what. So if someone spends 80 hours on an 8 hour project, that just means they didn't work on other projects. This impacts cashflow. Additionally, an inflated bill may be challenged and marked down. So, there's no way for a programmer to be 10x more profitable unless they had nothing else to do otherwise. Now, a company can be 10x more profitable if they hire enough programmers so that they have the capacity to inflate every project. ;) To be a 10x programmer at a consultancy, you need a combination of a high billing rate and long hours, but the easiest way is to implement a productized service that is billed by value/fixed price instead of hourly. For example, I know someone whose company was paid $81,000 for him to build an application, but he made a lot more for them charging about $40,000 to re-implement the same thing over and over for other customers. He didn't hit 10x, but he contributed mid six figure revenue in a year whereas the $81,000 was paid over 18 months. Obviously, he couldn't have done this if he was inflating his time.
itamarst 10y ago
You've figured out my rhetorical trick :)
wruza 10y ago
>With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs. I'll show this quote to my lil bros living in ~/bin/*.pl
- catnaroek 10y ago
  Consider the amount of code required to implement Perl's built-ins.
legooolas 10y ago
> With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs. Whilst this can be true, it's not always the case. Squashing code down to fewer lines can also mean doing something in a way that is much harder to understand or hides bugs behind complex subtleties in the code. Obviously it's a balance, and "lines of code" is, as usual, a poor metric of code complexity and readability.
- reacweb 10y ago
  For me, fewer lines means that it is easier to get a whole picture. More verbosity often induces splitting code in many methods. As always there is a balance, but I am more often annoyed by gratuitous verbosity than by cryptic constructions.
randallsquared 10y ago
> If programmers were paid for lines of code, copy-pasting would be best practice, and all kind of verbosity and unnecessary code or boilerplate, even dead code would be everywhere. Huh. Is that what it "would be" like.
- wry_discontent 10y ago
  I have technical leads tell me to copy paste code all the time instead of making better abstractions. It drives me slightly mad.
  - Pfhreak 10y ago
    I've generally followed the rule of thumb: If you're doing the same thing in two places, ok, if you are doing the same thing in three places, refactor. Let's me get away with copy pasting while I'm quickly prototyping something out, but reminds me that I need to clean it up before I try to iterate again. Plus, it's unlikely that I'll hit the right abstraction on the first or second time I see a problem. Better to wait until I've seen it three times before refactor.
    - wry_discontent 10y ago
      I'll forget to do it if I wait until the third time. I can't keep track of everything, you know.
      - ricksplat 10y ago
        My worry in that case though is you could end up with a whole heap of unnecessary abstractions which can make reading by a third party (or yourself even in 6 months) a little more tricky. I'm seen so many functions of the like of `Util.checkNull(String str)` where simply `str == null || str.empty()` would have done.
    - cema 10y ago
      I am of a different persuasion. Even if you are doing one thing, but it is indeed a thing, refactor it as a separate abstraction. You will end up with a better set of building blocks.
davelnewton 10y ago
That was my immediate reaction as well. "10x" means "10x productivity" which is likely inversely proportional to the SLOC/etc. If you have to spend your time writing code that isn't meaningful that's code that erodes productivity.

by drKarl 10y ago

jl6 10y ago

I think a 10x programmer is someone whose efforts increase profits by 10x. A lot of people think they are 10x programmers because they can optimise something that nobody really cares about.

caminante 10y ago
I think a 10x programmer is someone whose efforts increase profits by 10x. Careful ;-). I think that falls into the same trap drKarl's critiquing. Someone spewing unnecessary lines of code can jack up their line count and bill more hours, thereby increasing profits. They aren't making complex problems disappear.
- 1123581321 10y ago
  If you're in a billable hours environment, you can't be 10x as profitable by billing more hours. You need a higher billing rate (that is actually paid by clients). This is hard to get and keep if you are inefficient.
  - caminante 10y ago
    I agree that pulling it off requires help. That said, I've seen it happen where folks turn a (should be) 1 day task into a 10 day project. That's 10x more profitable. To be fair to the parent comment, I think he's getting at the super programmers that crack problems others can't. This capability provides competitive advantages. Maybe I'm talking about the other side of the table and did a poor job at that. Sorry!
    - 1123581321 10y ago
      Sure, I understand the gist of what you're saying (and what the parent comment was saying.) But the example doesn't work. Programmers at a consultancy/agency are probably billing 20-40 hours no matter what. So if someone spends 80 hours on an 8 hour project, that just means they didn't work on other projects. This impacts cashflow. Additionally, an inflated bill may be challenged and marked down. So, there's no way for a programmer to be 10x more profitable unless they had nothing else to do otherwise. Now, a company can be 10x more profitable if they hire enough programmers so that they have the capacity to inflate every project. ;) To be a 10x programmer at a consultancy, you need a combination of a high billing rate and long hours, but the easiest way is to implement a productized service that is billed by value/fixed price instead of hourly. For example, I know someone whose company was paid $81,000 for him to build an application, but he made a lot more for them charging about $40,000 to re-implement the same thing over and over for other customers. He didn't hit 10x, but he contributed mid six figure revenue in a year whereas the $81,000 was paid over 18 months. Obviously, he couldn't have done this if he was inflating his time.

itamarst 10y ago

You've figured out my rhetorical trick :)

wruza 10y ago

>With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs. I'll show this quote to my lil bros living in ~/bin/*.pl

catnaroek 10y ago
Consider the amount of code required to implement Perl's built-ins.

legooolas 10y ago

> With code, less is more, less code to do the same means easier to read, easier to maintain, less bugs. Whilst this can be true, it's not always the case. Squashing code down to fewer lines can also mean doing something in a way that is much harder to understand or hides bugs behind complex subtleties in the code. Obviously it's a balance, and "lines of code" is, as usual, a poor metric of code complexity and readability.

reacweb 10y ago
For me, fewer lines means that it is easier to get a whole picture. More verbosity often induces splitting code in many methods. As always there is a balance, but I am more often annoyed by gratuitous verbosity than by cryptic constructions.

randallsquared 10y ago

> If programmers were paid for lines of code, copy-pasting would be best practice, and all kind of verbosity and unnecessary code or boilerplate, even dead code would be everywhere. Huh. Is that what it "would be" like.

wry_discontent 10y ago
I have technical leads tell me to copy paste code all the time instead of making better abstractions. It drives me slightly mad.
- Pfhreak 10y ago
  I've generally followed the rule of thumb: If you're doing the same thing in two places, ok, if you are doing the same thing in three places, refactor. Let's me get away with copy pasting while I'm quickly prototyping something out, but reminds me that I need to clean it up before I try to iterate again. Plus, it's unlikely that I'll hit the right abstraction on the first or second time I see a problem. Better to wait until I've seen it three times before refactor.
  - wry_discontent 10y ago
    I'll forget to do it if I wait until the third time. I can't keep track of everything, you know.
    - ricksplat 10y ago
      My worry in that case though is you could end up with a whole heap of unnecessary abstractions which can make reading by a third party (or yourself even in 6 months) a little more tricky. I'm seen so many functions of the like of `Util.checkNull(String str)` where simply `str == null || str.empty()` would have done.
  - cema 10y ago
    I am of a different persuasion. Even if you are doing one thing, but it is indeed a thing, refactor it as a separate abstraction. You will end up with a better set of building blocks.

davelnewton 10y ago

That was my immediate reaction as well. "10x" means "10x productivity" which is likely inversely proportional to the SLOC/etc. If you have to spend your time writing code that isn't meaningful that's code that erodes productivity.