5 ms·

> I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much ti

> I personally know an objectively measured 500x engineer. He is humble because he knows someone who produces 10x what he does (albeit spending twice as much time at it). So your 500X engineer knows a 5000X engineer and he wrote as much code as 999 other engineers combined? (That would make him a 999X engineer, FWIW) A 500X engineer (per your measurements) would have to write 500 lines of code every day without fail, while all 500 other engineers in the entire company could only average 1 line of code per day. And the 5000X engineer they know would have to write 5000 lines of code per day while everyone else was only limited to 1 line of code per day. Not just one day, but every single day for six straight months. And all of their managers would have to somehow not notice this disastrous situation for the duration of the project. Come on. I think you've been fed some exaggerations.

Nasrudith 5y ago
The multipliers are all relative and seldom in simple metrics such as lines of code. If you wanted to inflate the numbers in a technically truthful way stick in a complete novice capable of preparing (so they are not negative) but not prepared for a complex field so their multiplier will be low. Use them as your 1X and even burnt out and demotivated employees who don't stand out could wind up performing 50x relative to them.
wittycardio 5y ago
You don't measure code by the number of lines written, you measure it by amount of productive value. Early engineers at Google were easily 500x ( keep adding more zeros if you want ) more valuable to google than a random swe today
- ncmncm 5y ago
  If you thought this was about lines of code, you were not paying attention.
Jensson 5y ago
For any positive real number X and employed engineer A with positive productivity, I can find an employed engineer B where productivity of A is more than X times the productivity of B. Proof: Pick B to be an engineer with productivity 0. 0 * X = 0 for all X. Productivity of A is defined to be positive, so is greater than 0. Hence productivity of A is greater than X times the productivity of B.
- JBiserkov 5y ago
  And then there's people with negative productivity.
ncmncm 5y ago
The person who told me about this was the person who counted up the code at the end of the project. And, yes, it was 250 from each, not 500 from each parent company. (Memory is funny that way.) I do not doubt that the numbers were rounded for simplicity. It is meaningless to talk about a 499x engineer. As was explained to me, this engineer assigned two-week work units. If the work was not ready at the end of two weeks, he wrote it himself over the weekend. So, a fair bit of code was written that did not make it into the final product.
- pseudalopex 5y ago
  > If the work was not ready at the end of two weeks, he wrote it himself over the weekend. Using no code or knowledge from the past 2 weeks?
  - ncmncm 5y ago
    That would have taken longer.
    - pseudalopex 5y ago
      Using it or not using it would have taken longer?
      - ncmncm 5y ago
        Trying to use somebody else's code that does not solve the problem generally takes longer than writing it yourself.
        newaccount74 5y ago
        But looking at someone elses code first generally makes you faster even if you end up not using any of it.
        pseudalopex 5y ago
        Solving a problem isn't all or nothing.
iratewizard 5y ago
I remember a day when one of my engineer's full days of work was one line of code. Not all lines of code are made equal
- ncmncm 5y ago
  And, not all projects are death marches. It is generally hard to measure value, which is one of Dan Luu's points. Counting lines of code rarely produces a very good answer, but sometimes that is the best you have. Company revenue can be meaningful. When a contribution that makes the difference between $X million revenue and $0, against 250 years worth of engineers' salaries, it is hard to quibble. 500x is as good a number as you can get.
- sneak 5y ago
  https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...
fitzn 5y ago
Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates
- tremon 5y ago
  It's a nice aphorism, but it's a very bad analogy. Before the build of an aircraft is started, the target weight of the assembled product is (roughly) known. Therefore, in the process of building an aircraft, the assembled weight at least goes up from 0 to $target -- in an erratic fashion, but it's still a continuous measurement. I have never seen a program design specification that even attempted to quantify the lines of code of the end product, let alone be accurate.
  - fitzn 5y ago
    The initial comment was related to attribution for "who built" some piece of software based on lines of code. The analogous argument would then be assigning attribution for the built aircraft to whoever produced the heaviest components. Given that that would be illogical, I think the analogy is apt.
- mostertoaster 5y ago
  And I bet an in progress airplane that weighs a 1000lbs is further along than an airplane that weighs 1.
  - bdavis__ 5y ago
    Note this applies to the manufacturing,not the design. It is actually a wonderful analogy with software: * to a first order, cost of the materials in an airplane are proportional to the weight * at design time, the weight of the aircraft is minimized. thus, political and management forces cannot change it. just like software, each subsection that is bolted on has different weights; but if you average it out it is a good measure of progress. and cost.
  - ecnahc515 5y ago
    And if I build a paper/balsa wood airplane that's 1 pound and can carry a mouse? It all depends on what the actual "airplane" (product) that's being built is.
moralestapia 5y ago
By measuring productivity on lines of code written you show just how inexperienced and naive are. Are you HR, by chance? Have you ever coded something in your life?
- deleted 5y ago
  [deleted]

Nasrudith 5y ago

The multipliers are all relative and seldom in simple metrics such as lines of code. If you wanted to inflate the numbers in a technically truthful way stick in a complete novice capable of preparing (so they are not negative) but not prepared for a complex field so their multiplier will be low. Use them as your 1X and even burnt out and demotivated employees who don't stand out could wind up performing 50x relative to them.

wittycardio 5y ago

You don't measure code by the number of lines written, you measure it by amount of productive value. Early engineers at Google were easily 500x ( keep adding more zeros if you want ) more valuable to google than a random swe today

ncmncm 5y ago
If you thought this was about lines of code, you were not paying attention.

Jensson 5y ago

For any positive real number X and employed engineer A with positive productivity, I can find an employed engineer B where productivity of A is more than X times the productivity of B. Proof: Pick B to be an engineer with productivity 0. 0 * X = 0 for all X. Productivity of A is defined to be positive, so is greater than 0. Hence productivity of A is greater than X times the productivity of B.

JBiserkov 5y ago
And then there's people with negative productivity.

ncmncm 5y ago

The person who told me about this was the person who counted up the code at the end of the project. And, yes, it was 250 from each, not 500 from each parent company. (Memory is funny that way.) I do not doubt that the numbers were rounded for simplicity. It is meaningless to talk about a 499x engineer. As was explained to me, this engineer assigned two-week work units. If the work was not ready at the end of two weeks, he wrote it himself over the weekend. So, a fair bit of code was written that did not make it into the final product.

pseudalopex 5y ago
> If the work was not ready at the end of two weeks, he wrote it himself over the weekend. Using no code or knowledge from the past 2 weeks?
- ncmncm 5y ago
  That would have taken longer.
  - pseudalopex 5y ago
    Using it or not using it would have taken longer?
    - ncmncm 5y ago
      Trying to use somebody else's code that does not solve the problem generally takes longer than writing it yourself.
      - newaccount74 5y ago
        But looking at someone elses code first generally makes you faster even if you end up not using any of it.
      - pseudalopex 5y ago
        Solving a problem isn't all or nothing.

iratewizard 5y ago

I remember a day when one of my engineer's full days of work was one line of code. Not all lines of code are made equal

ncmncm 5y ago
And, not all projects are death marches. It is generally hard to measure value, which is one of Dan Luu's points. Counting lines of code rarely produces a very good answer, but sometimes that is the best you have. Company revenue can be meaningful. When a contribution that makes the difference between $X million revenue and $0, against 250 years worth of engineers' salaries, it is hard to quibble. 500x is as good a number as you can get.
sneak 5y ago
https://www.folklore.org/StoryView.py?story=Negative_2000_Lines_Of_Code.txt https://www.folklore.org/StoryView.py?story=Negative_2000_Li...

fitzn 5y ago

Measuring programming progress by lines of code is like measuring aircraft building progress by weight. - Bill Gates

tremon 5y ago
It's a nice aphorism, but it's a very bad analogy. Before the build of an aircraft is started, the target weight of the assembled product is (roughly) known. Therefore, in the process of building an aircraft, the assembled weight at least goes up from 0 to $target -- in an erratic fashion, but it's still a continuous measurement. I have never seen a program design specification that even attempted to quantify the lines of code of the end product, let alone be accurate.
- fitzn 5y ago
  The initial comment was related to attribution for "who built" some piece of software based on lines of code. The analogous argument would then be assigning attribution for the built aircraft to whoever produced the heaviest components. Given that that would be illogical, I think the analogy is apt.
mostertoaster 5y ago
And I bet an in progress airplane that weighs a 1000lbs is further along than an airplane that weighs 1.
- bdavis__ 5y ago
  Note this applies to the manufacturing,not the design. It is actually a wonderful analogy with software: * to a first order, cost of the materials in an airplane are proportional to the weight * at design time, the weight of the aircraft is minimized. thus, political and management forces cannot change it. just like software, each subsection that is bolted on has different weights; but if you average it out it is a good measure of progress. and cost.
- ecnahc515 5y ago
  And if I build a paper/balsa wood airplane that's 1 pound and can carry a mouse? It all depends on what the actual "airplane" (product) that's being built is.

moralestapia 5y ago

By measuring productivity on lines of code written you show just how inexperienced and naive are. Are you HR, by chance? Have you ever coded something in your life?

deleted 5y ago
[deleted]