It also exists in a much more banal state lower down the ladder. I have friends who landed in the low end of the developer market. They literally cannot do most of the work I do. They don't understand DB isolation levels, they don't have the skills to design systems around eventual consistency, they are not familiar with basic distributed system problems like clock drift, etc. I'm not even an infrastructure engineer, this is just stuff I and my coworkers need to get through our days to ship product code.
Could my friends do this stuff? If they applied themselves, sure! But they're not going to. It's also not enough to learn on the job. We occasionally hire someone who doesn't actually have the skillset and they usually flounder.
Just to confirm, does that person code all day there? (real question)
Next to that is a constant overhead of talks with leadership and supporting other engineering efforts throughout the company through things like doc review, chats, pairing, etc.
What he doesn't generally do is "productionize" features - code is generally exploratory in nature or fixes a serious bug (or class of bugs).
I have seen engineers at companies 1/1000 the size of Google generate $4 million in differentiated costs savings (definitely would not have happened without them). It seems plausible to me that someone could generate 10x that at Google.
Hmm, does come up every now and then.
> eventual consistency
Have seen these event-based maintenance nightmares, trying to steer clear wherever I can.
> clock drift
Never met a developer who would at least hear about some other developer for whom that would possibly ever matter.
I know a dude who got a nice package from a pizza company to be CTO + lead programmer. I think he has a few people under him, but the bigger deal was that he could get a percentage of the $ saved.
He worked all day and night to get LLMs to take orders, in a month 40% of their orders are taken through the LLM. For a company with 100s of stores, this is a huge cost saving.
Guy knows how to program, he knows technology, and he knew the domain from a previous job.
You and I and probably half of HN could do the job of "CEO of a mid-size tech company." We don't, not because of lack of ability, but because we don't tick those culture/personality/background checkboxes.
You're not going to leetcode-grind or PhD your way into a $10M software engineering job.
> The CEO is in his position because he has the "right" pedigree and the "right" network, went to the "right" school, talks the "right" way, has the "right" ivy league mannerisms, goes to the "right" polo clubs.
None of this is true. The CEO is either significantly compensated because it’s her company (majority ownership) or because the board likes the direction the ship is being steered and wants to make sure she doesn’t leave to steer another ship.
> You and I and probably half of HN could do the job of "CEO of a mid-size tech company." We don't, not because of lack of ability, but because we don't tick those culture/personality/background checkboxes.
What is it you think the CEO does? Half of HN absolutely could not run a 2000 employee firm they are intimately familiar with, let alone an arbitrary one.
> You're not going to leetcode-grind or PhD
Leetcode no, phd yes. The fact that you put them side by side pretty strongly indicates you don’t know what compensation is tied to.Leetcode skills provide limited value to a company. A PhD with a track record of leading ML publications absolutely can put you up there.
Compensation is about what value they think they can get out of you and how much competition there is for you.
Don’t sit around telling yourself execs have trivial jobs. It just makes you look ignorant. Spend some time looking at what each brings to the table for that specific company. Barring nepotism or corruption, there is usually something significant there.
I'd take that deal in a heartbeat. I think I (and most other decent engineers) can probably point to tens (or hundreds) of millions of dollars in savings generated over the course of a single career.
As far as I can tell, it gets frittered away by empire-builders who take that $ and spin up new teams for nonsense. Kicking back a % to the engineers who harvested all the savings seems like a much better model.
> I'd take that deal in a heartbeat.
Same! That would be a very exciting and lucrative role. Unfortunately it's basically the opposite of what the industry does today. I think we've all seen the six-figures per month AWS bills to power infrastructure for a workload that could be comfortably hosted on a Raspberry Pi.
If the industry ever goes back to caring about efficiency and cost, sign me up.
At the high end of the white collar market you're paid to deliver impact and your pay is determined by the quantity of the impact and how differentiated it is (no big bonuses for the guy who presses the "print a million dollars" button).
Sounds like the skills aren't very differentiated. IME it's quite rare for a business to miss differentiation in business impact in an order of magnitude.
Going to your earlier question, the candidate in question has many skills but is not overly specialized. He commands that price because he can point at the right place in the stack and say "There's $10 million in savings here" when everyone else misses it or "Changing the architecture in this way lets us ship 6 months faster" and he is able to do this repeatedly.
"Knowledge worker productivity is the biggest of the 21st century management challenges." - Peter Drucker (the founder of modern management)
You don't necessarily need to quantify that exactly. If you've worked on a team with people like that, then you know it. Their managers know it too.
To your main point, the size of the markets is drastically different. There is only so much room for headline rockstars and entertainers, but there's way more room for talented technologists. Having "rockstars" in the engineering world doesn't really reduce the size of the pie for others.
If you can't prove your superior productivity, you are not going to get paid for it. Which is going to incentivize you to optimize for your company's promotion rubric instead, if you don't get fed up first. This leads to the lamented "promotion-driven design".
Or you can ditch the middle man and take your talents straight to the market, through consulting or incorporation.
Or it could just be somebody that happened to have a crucial bit of domain knowledge.
Or the original composition of the team could have included some negative-contributors.
one guy for two days = 2
240/2 = 120
It's not necessarily that he's that much better technically, but he's got the right drive, focus, and business acumen, and isn't bound by methodology or legacy.
The real problem with software development is that a lot of developers are too removed from the business to deliver something practical with value in the right places.
The person who understands and can solve your problems effectively is more valuable than a clueless person who cannot. It doesn't matter how many hours they spend in the office. What matters is technical knowledge on the sometimes confusing topics that arise at work.
We can take or reject projects, so if you are a bad predicter of use/time to completion, you are going to do worse.
Or I'm a manager. I help my engineers get work done. Let's consider the happy case and assume we can measure our team's revenue. How much of that revenue is attributable to the manager's superior skill, and how much to the rockstars under him/her? What would an experiment look like; the engineers manage themselves, or we compare with the previous manager?
No company that I know goes this far. In their defense, it is a challenge. An open problem, even.
You wouldn't run an A/B test to quantify your impact, but you could pretty easily do before/after metrics (or just collect them on the way during a graduated rollout) for any feature you're rolling out. It should be straightforward to quantify productivity benefit for a large initiative.
> How much of that revenue is attributable to the manager's superior skill
The output of a manager is the output of their team. We can't A/B test managers (or at least, we probably shouldn't), but we can look at a cohort of managers and see how well their teams are generating business impact. Combined with other data (e.g., upward feedback surveys, level-skip 1on1s, retention metrics, etc.), we can measure the impact of a manager.
People say that but it makes no sense. That means the same manager would have a different "output" going from one team to another. Are you going to cut his/her salary if he leaves a big, successful team to help fix a flailing team because it has less output?
I get it: doing it this way is easy. My ideal is marginal attributable revenue or profit. How much better are you than the next person? We can haggle over the marginal part but I'm not conceding on attribution. Otherwise you're mooching off other people's work. Why are we paying you the big bucks? Show me what you did.
I think it works fine if we add on the concept that a good manager operates on a different timescale. The on-boarding timeline for a first-line EM can be months at some companies.
In your example, the manager moving over should be given a compensation package based on the expected value he's going to get out of the flailing team once he works his magic. (And, indeed, this is exactly the kind of package often given to externally-hired CEOs brought in for turnarounds.)
> Otherwise you're mooching off other people's work. [...] Show me what you did.
But that's just it. The manager's skill is improved utilization of resources. The leader's skill is improved direction of resource utilization. By definition, those skills are expressed on the canvas of the team they lead.
Or, more simply: A leader without followers isn't actually a leader at all!
And, indeed, we see that in the real world too: A successful executive in one company goes elsewhere, doesn't fit in with the new company's culture, and performs terribly. It's a tale as old as time.
It helps that we are often saving ~400 hours/yr spending ~80 hours or less.
We can also see it in overtime hours being eliminated, and the (real) engineers are making more complex designs but the size of the team hasn't changed.(30% more complex in 2.5 years, same team size) They also havent replaced engineers that left the team.
Basically: We save enough hours that it is obvious. There are added benefits like not having humans do manual checks, so less prone to errors. (Although I argue that our bugs are equally as dangerous)
Making sure those $ saved didn’t screw things up somehow is the hard part to measure.
And - this is going to blow your mind - but sometimes you can actually make things more efficient by spending more money. Cutting costs can be the exact opposite of the right thing to do.
So while I am jealous that your productivity can be measured so simply, I’m dubious about how many programmers’ contributions can be so easily reduced to a simple metric.