Not only are there 10x engineers, 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).
The measurement happened as a result of a joint venture between Siemens AG and Ericsson called Ellemtel. Each company sent 250 [edit: not 500] engineers. It was a six month project, the classic death march: if it did not deliver on time, the parent companies would not be paid.
At the end of the project, half the code delivered was his. Had he not been on the project, it would not have been completed on time, so no product would have been delivered. [Edit: Thus, it is not really the line count that makes him a 500x engineer.]
> 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.
What were you trying to say? You realize a Boeing 747 weighs over 400,000 lbs. And a tiny Cessna 172 weighs ~1500 lbs.
If the planes have the same wingspan, it's likely they're in the same class, and weight is a perfectly reasonable measurement of completion percentage.
A 450-gram partly completed airplane probably has a wingspan of about 1 to 3 meters. If you have a partly completed plane whose wingspan is of about 1 to 3 meters, and it weighs 450 kg, it will never fly. You need to redesign it. Otherwise you have a rocket, not a plane (and there's no guarantee that it's a working rocket).
Maybe, in exceptional cases like the Gossamer Condor, a 450-gram partly completed plane might have a larger wingspan, like 30 meters. With enough thrust and wingspan, you can definitely get a plane weighing 450 kg to fly (or even one weighing much more, like your Boeing 747 example). But if your Gossamer Condor competitor is partly completed and weighs 450 kg, again, you are going to have to redesign it, because a bicyclist will not provide enough thrust to keep it airborne.
If your Boeing 747 assembly is running behind schedule, you probably cannot catch up by adding more ballast to the wings, or prioritizing ballast over riveting, even though lead or DU weights are quick to install, and rivets do not weigh very much. X-ray inspection doesn't add any weight to the airplane at all, but it's the only way to find certain cracks. If your Boeing 747 weighs 500 tonnes, that does not mean that it's a super-complete plane. It won't be able to take off.
So, no, weight is not a perfectly reasonable measurement of aircraft completion percentage.
sure, because they are measuring progress towards completion, rather then the ability to fly
i.e. if a finished plane weights 10,000 lbs all put together, then a in-construction plane currently at 1000 lbs is clearly further along towards completion then one at 1 lbs
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.
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.
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.
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.
That's a ridiculously wasteful way of managing work. I too can be a 10000000x engineer if I never let others actually merge their code and just write it myself instead.
If you hired engineers like they hired them before coding interviews combined with a decade of the dead sea effect I can easily see a team of 500 barely getting anything done at all. Big organizations are often grossly mismanaged like this which is why smaller organizations can beat them.
mismanaged, yes. But also risk-adverse and encumbered with process. At a big corp you may need 5 or more sign offs on a single merge. I probably spend a good 40% of my time herding cats and babysitting the merge pipeline. There is a lot of overhead you simply won't find in a startup.
It was a way that delivered product on deadline, for exactly that project. Every project has specific needs. If you code to some other project's needs, you do the wrong thing.
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.
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.
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.
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
LoC is a terrible metric - did they count the lines other engineers removed?
I was half of a very productive duo on a greenfield project subsystem - a project I joined midway: my partner wrote a lot of code, I estimate ~70% of final lines in the code base were his. What the LoC count won't tell you is all the refactoring, deletion, tests and error handling code I had to add, because his code only worked for the happy path. Can you say he was being 2x more productive than I was? I say no, because he was breaking the nightly build at least once a week before I joined, blocking the rest of the team, this ended when I added pre-commit tests.
When the numbers are large enough, the details don't matter much. Maybe he is really only a 250x engineer? A 100x engineer? It doesn't change the fact that without him no product would have been delivered.
> It doesn't change the fact that without him no product would have been delivered.
I agree. I'm only arguing that there are times when engineers who enable "10x/100x" engineering don't get the visibility they deserve, sometimes until after they quit.
This hits close to home for me as I witnessed my partner being showered with praise for being "super productive" based on LoC alone, code which wasn't close to being production-ready. If you don't care about code quality, and want to be seen by management/people outside of your team as a 10x engineer with minimal effort: you can follow the same playbook.
Agreed. It is rare that you can get objectively meaningful numbers. So, while it is convenient that half the code delivered was his, that is not the meaningful measure.
When I was in school, the standard for engineer productivity was 10 lines of tested code per day, averaged. Maybe we do better today, with fewer footguns and faster compilers. But we expect more meaningful results from a line of code, too.
This really isn't my experience with super productive engineers. Usually they're solving high level technical problems for the company that most employees wouldn't touch with a ten foot pole. It isn't the raw LOC they produce but their ability to translate complex technical problems into elegant solutions for everyone else to take advantage of.
I'm not saying it doesn't exist. I did say 'maybe' after all.
I am also implying the likelihood of it being that, rather than from a particular perspective an organizational detriment looks like a personal positive (somewhat akin to the 'heroic' team constantly responding to pages in production for their services; not like that lazy team that only works 8 hours a day and never gets paged), seems low. As mentioned, when one person seems to be doing all the work, yeah, it might be they're just amazing, or it might be that the project is badly managed, and so the work can't actually be distributed well. Both can also be true.
I too have seen -10x engineers. Interestingly, others in the company also saw them as +10x. Someone who was the silo for a notoriously difficult part of the system was viewed by management as amazing (after all, he just went and got things done! They could focus their attention elsewhere!). When I then had to dig in, with actual production requirements, I found nothing really worked, nothing was designed well, nothing was documented, and the person was impossible to work with.
Assuming you can objectively measure someone like this, either by LoC or delivery times, this is the wrong way to approach any project.
Having a 10x engineer(or even worse, a 500x engineer in this alleged case) is a huge risk for the company, should the engineer want to leave or if they are incapacitated in a tragic event, the company is severely handicapped, ideally a so-called 500x engineer should spend less time writing the actual code and instead mentoring/managing others to scale up their knowledge, should the company do this right, they might not deliver on time, but they'll have a much wider array of experts when something breaks or for the next projects, reduces overall company risk and it's more profitable in the long run.
Yet, they in fact delivered and got paid, and (pay attention!) would not have delivered and not got paid, otherwise. Risk is speculation about the future. Here we have full benefit of hindsight, and the choice taken was manifestly correct, despite all counterfactual speculation.
The measurement happened as a result of a joint venture between Siemens AG and Ericsson called Ellemtel. Each company sent 250 [edit: not 500] engineers. It was a six month project, the classic death march: if it did not deliver on time, the parent companies would not be paid.
At the end of the project, half the code delivered was his. Had he not been on the project, it would not have been completed on time, so no product would have been delivered. [Edit: Thus, it is not really the line count that makes him a 500x engineer.]