Dan Luu also elsewhere makes the argument that most of the impactful engineering work done in large companies is performed by a small percentage of the engineering group.
“most of the impactful engineering work done in large companies is performed by a small percentage of the engineering group.”
That is probably true. But we shouldn’t forget that these people can do these things often because they are supported by a large number of people who do the mundane tasks that need to be done.
I’m a cynic but I wish that were true. In my past experience it has usually been the opposite, the bulk of engineers are making unnecessary tools, re-inventing wheels, and designing systems that shouldn’t exist and serve as roadblocks to the minority of engineers who are miraculously getting things done in spite of all that.
The biggest cost of bloat comes from people being nice, it is emotionally hard to replace/rewrite code when the author is still there and not disliked by the team. Basically it sucks to make people redundant, so we try not to, and that makes it look like people aren't redundant even when they are.
For example, lets say you give a project to a competent engineer, he writes a clean and maintainable solution quickly alone. But if you schedule it to him together with another engineer of similar status but much less competent, then the other engineer will take a part of the project and basically block it since the competent engineer is unlikely to to take that fight, and instead just lets the project stall.
You don't get promoted for pointing out incompetence, there is a reason managers hires consultants to do that for them. This made me wonder, are there software consultants who act like management consultants and mostly go in and fire a lot of people? I don't think management consultants would do a good job of firing the right software people, they would need to be engineers.
Yes, but it’s done on a project basis. Kill the project, move the good people to a new project, release the others. Later, resume/restart the project.
It’s really hard to be surgical about this because who wants to be the good engineer that has to pick up the barely functioning pieces of code left behind. Who wants to reward a solid engineer with a big refactor job on an already late/failing project? The optics aren’t great. I’m not saying it never works, but as a general rule, deferring the project is often a better option.
> Dan Luu also elsewhere makes the argument that most of the impactful engineering work done in large companies is performed by a small percentage of the engineering group.
The keyword "impactful engineering" needs some clarification though.
It does not mean there's a 100x guy walking around the office while everyone is slacking off.
A specific proof of concept hacked together by a guy in a week might eventually become the company's flagship product. That's impact. However, the thing needs to be rewritten from scratch to become production ready or even deployable, and that takes far more work that does not fit the definition of "impactful".
I personally know a principal engineer of a FANG which single-handedly wrote the proof of concepts of more than a few projects that thousands of users use every single day. From his own words following one of his recent presentations, "this needs to be rewritten from scratch as this would get me rejected from our job interviews".
The 100x impact isn’t usually with proofs of concept, it’s with surgery. 1,000 lawyers would likely never identify and execute the life-saving graft, all while avoiding side effects that eventually kill the patient.
A surgical ten lines of code across 5 services can absolutely create billions of dollars out of thin air. The combination of technical, political and domain expertise required for such changes is relatively rare.
(I mean political in the purest, non-controversial sense, i.e. the communication skills to answer objections and acquire group consensus on the required change.)
I disagree for the following reason: without the proof of concept, the change in production would probably never come about. You can't really separate the impact of the proof of concept from that of the production change because they don't exist independently.
That seems consistent. If there's a 1% chance of a meaningful improvement, and 99 out of 100 changes do not meaningfully improve things, than the challenge is knowing beforehand what the most impactful engineering work is going to be.
Meta-question: does the cognizance, cohesion and awareness that goes into identifying that 1% emerge from the 99% quotient of inefficient aimless wandering, or somewhere else?
Meta-meta-question: assuming that it does, how does the line get described (let alone drawn) dividing "this work contributes to identifying the 1%" from "this is a waste of time"?
(Insert something about gradient descent and local vs global maximums here)
I'll call this a genuine question, I could definitely use some refinement of my own optimization of this problem space (and not wind up in micro-optimized dead ends etc).
And on the other side of that coin, if one were to espouse the same opinion in the context of anything even tangentially safety related and the average HNer's head would explode and they would rage click the wrongthink button.
It's all a numbers game. The median member of your kernel team, the median fire extinguisher, the median link to a sales web page, the median joist in a floor, all will do nothing of note. But if you distribute the resources properly they will hopefully be where they are needed to generate a positive ROI that pays for the overall system. If you zoom in too much or too little it all looks silly.
You need a bench. Some of the brilliant folks who are great at pushing through problems are awful and maintenance and sustainment. I worked for a bit in a SWAT engineering team tasked with addressing crisis problems or emergency response. If you don’t have people you’re developing on the bench, you won’t be able to respond to those types of things and will get bogged down with tech debt.
I was a faux “10x” person because I had license to break the rules to get shit done - because the value of what we were doing was higher than the cost of cleaning up the mess. (Not because of any brilliance on my or the teams part) We did two years worth of work in a month, but it’s still being refactored 3 years later.
What extra steps? It's literally a Pareto-type rule. He's also probably right, but not because only a small fraction of a company's engineers are any good. It's more that a lot of engineering work is done for reasons that are more speculative than people realize.
