It's a nice write up, but the methodology is based on productivity as measured against coding, debugging, and execution speeds - which does really capture how much more impact a good engineer can bring.
The reason is that the impact can't me measured because we can't foresee the inventiveness of a brilliant engineer - if we could foresee then we are that brilliant engineer and are inventing ourselves. For the same reason the act of predicting scientific research is impossible because that would be the very product of research.
There's no upper bound on what a brilliant engineers can do, I've known people that you could not replace with 1000 mediocre engineers working for 10 years and they would't produce the same innovation, creativity and automation.
I came here to say this. Because programming is a very high leverage activity, what matters much more than coding speed is the quality of judgement. And that can vary much more than 10x. And the funny thing is the market largely ignores this for programmers, but recognizes it for CEOs. Why are there no rockstar developers pulling in ten million a year? They do exist, but exclusively because they founded a company. I think this doesn't exist in programming because programmers aren't given the freedom to exercise that judgement. Instead they're largely treated like replaceable cogs executing on the vision of other people.
I think it's because programmers generally operate within a framework that guides and controls them and that becomes the limiting factor. It's like having a car that goes 10 times as fast as others but you're driving in the city, so all the traffic gets synchronized at the traffic lights.
Those two comments perfectly describe the issue IMO. That also means that activating good developers to be 10x people means they need to be given leverage and freedom to automate, innovate and be creative. And maybe also ownership of the product they create - e.g. shares or simply a special kind of recognition.
I also see the problem with 10x developers - they are by definition irreplaceable which is impossible to manage properly. But for startups which have a small head-count, this may be needed.
I think the leadership component is very relevant here. A project manager / leader needs to be able to a) identify developers who could be 10x developers, b) develop their characters (some developers may be lazy or undisciplined or have anxieties that hold them back, so this needs to be solved first), c) recognize good technical skills and realistic self-evaluation (a developer that always wants a rewrite because he's certain that he will do it better than everyone before him vs. someone who tries to find a more reasonable way that may involve a rewrite).
Overall, this is a very difficult task. If you let developers that have undeveloped characters manage themselves, they'll create a huge mess. And personal development is generally a very difficult task and not something that a leader can control for most parts.
I'd say we do see that. It's the business model of Sand Hill Road - find talented 10x Devs and shower them with VC money. It seems to work often enough that there are many funds all searching for such people.
Why are programmers not treated like CEOs in terms of pay levels?
I believe it’s mainly attributable to the capitalist hierarchy we live in. Those in and around the ownership of companies make the most money. In large part because of the leverage that the labor/employees provide. As the world has opened up with free trade, businesses have scaled and this has increased further with the internet and computers.
Those selling services to business owners i.e. M&A bankers (glorified real estate agents for businesses), M&A bankers and CEOs have all become richer and better compensated as business owners have gotten richer.
It’s all about power, position and where you sit in the hierarchy that dictates how much you get paid and not necessarily the value you bring to the table.
Having said all of this, I’m still a capitalist and I’m trying to play the game...ex-software developer turned investment professional...
> Why are programmers not treated like CEOs in terms of pay levels?
Because of scope of impact. The scope of impact of a CEO is the entirety of a company. A bad CEO can destroy a company, a good CEO can make the company financially successful and desirable to work at. A regular engineer, or even a lead/staff engineer is mostly scoped to their own product, and have little ability to impact the future of the greater company.
Why do military generals get credit when it's their soldiers who actually participate in combat and risk their lives? Because the decisions of a general have a much higher scope of impact.
You could argue that being the soldier (or engineer) is harder than being the general (or ceo), but that doesn't change the fact that having the best engineer won't save a struggling company, while a good CEO can.
So, companies (wisely) pay a pretty penny to have a good CEO, because it's worth it.
Yes, precisely. Now if you have a really brilliant engineer who could found a 100 million plus company, but they're working for you by some twist of fate instead - if you treat them like a code monkey they're going to hate it, and you're wasting their potential. This is what e.g. Google does. On the other hand if you empower them and get the fuck out the way, they may well surprise you.
> but they're working for you by some twist of fate instead - if you treat them like a code monkey they're going to hate it, and you're wasting their potential.
Well no one is forced to work anywhere, especially if they don't like it. Fact of the matter is that there is more support for entrepreneurs today than ever before, especially in tech. Electric scooters are getting $100 million funding rounds. There is more than enough support for this brilliant engineer to create his successful company.
The CEO's job is primarily to raise money, keep investors happy, promote the brand, and set strategic goals.
There is almost no overlap between this skillset and the developer skillset.
It's partly about talent - in varying proportions - and partly about hierarchy. You have to be able to talk to other people high up in the hierarchy as an equal, and you need to display the correct social and personal signals to do that effectively.
I don't think it's his description that got him downvoted. Rather it is his statement in the end where he "sold out" and became complicit in a system that a lot of people hate.
I sold out because as a software engineer I was making GBP 23.5k a year plus over time. I had a great review and was the “star performer” on my project. They were hiring people with my skill set for 28k so I asked multiple times for a pay rise and got turned down.
I lived in the London area and housing is expensive. Around here financial services pay more and I wanted to be able to buy a house. I left for job that paying 57% more for less hours.
Some of the people I've encountered over the years who were praised for their speed and "productivity" dragged down the project (and/or the rest of the team) by introducing more bugs (and risk) than anyone else. Upfront perception of "productivity" masks the long-term cost, in so many cases.
IMO the true "10X" developer is the one who boosts the rest of the team through mentorship and leadership -- the polar opposite of the "lone keyboard warrior" frequently portrayed as godlike and outweighing any other team member.
Getting a given task done fast does not make you a 10x developer.
It's 10x over time, not 10x for a given task.
There's the fast way of doing something, copy and paste some similar code, tweak it with your goals in mind and you're golden.
You also copied every single bug in the code you replicated, and further polluted the base of the software, which is already a steaming heap of unmaintainable garbage because the impetus is for speed over quality, and tacitly encourages developers to do what you just did.
Or you could refactor. You look at what needs to be done and how the current API limits your ability to implement it.
Update the API to integrate the required features, and refactor if the gradual build up of changes has rendered it unwieldy.
Quickly and cleanly implement the new requirements against the improved API.
You just spent a day and a half implementing something that could've been done in two to four hours, ignoring whatever manager was wondering why it was taking you so long - but the next time you need to make a similar change you'll be done with dev in half an hour.
And when that happens the code you write will be clean, simple and unlikely to introduce new bugs.
This is the danger of the '10x programmer'. The person 'gets shit done' fast and furious, but at the expense of the wider system which happens to be the team around them.
To the outside (managers etc) they look like they're a 10x programmer, but in reality they leave a trail of destruction and a mess that others have to clean up after them.
I have no doubt that 10x programmers do exist, but I'm not sure I've worked directly with one yet.
I think there are different flavors of 10x. The people that I've worked with that I would consider to be of the 10x variety weren't the kind of 'trail of destruction' type that some people tend to talk about.
I worked with a guy, great engineer, great guy, deep domain knowledge and a very solid understanding all the way through the stack. He was a great mentor and only barked when he was absolutely too slammed to help, which was rare. The thing that always amazed me is not only did he consult on all the really difficult stuff and ship it, but frequently you would come back to code you wrote recently and it would look nicer, cleaner and just a little more polished. He'd been in there leaving not a trail of destruction, but a trail of cleaning.
Now, I have also heard of the trail of destruction kind too. They're more like -10x though. They just pump it out really fast, but super low quality. IMO that's a bad kind of 10x to be. It's 10x the recklessness. A truly great engineer is one that can help the team and the company avoid writing as much code as possible. As such I don't consider the 'trail of destruction' 10xers to be 10xers, but rather really fast cowboys.
Indeed. I worked on a team which was "given" a couple of contractors to help us "catch up" to where management thought we should be. They were both useless. Between finding something they could do without damaging stuff, fixing what thay had damaged anyway, trying to maintain the morale of the rest of the team and explaining to management why we would be better off without them... I was easily more than 10x more productive than they were. But the team was in a hellish mess.
I think true -1x devs are also rare like 10x devs. To be -1x everything you "contribute" has to be a net negative. They are out there, but I think they're also rare.
I don't think so at all. It's really, really easy to slow down a team. The most common -1x behavior I've encountered is committing code that breaks something else, poorly executed "refactoring", misunderstanding the requirements of a task, and asking too many questions.
I've worked with -1x developers and have been one myself. I'm sure lots of other people here have committed these infractions at some point or another. But consistent offenders end up working on low-importance silo projects.
We all do that stuff from time to time, but I rarely find someone who is consistently that bad in everything they do. I have seen them, but my point is they are also rare.
True 10X developers are really good at picking the right tool for the job. They know the OS and standard library of their language very well. They also know patterns for how to apply technology to problems and have read a lot of other people's code. This knowledge translates into up front productivity but also less bugs as things tend to get done right and the correct technology is picked.
I've seen a lot of code bases and it's never the super experienced, incredible developers introducing tech debt and bugs, it's the poor to middling developers.
"There's no upper bound on what a brilliant engineers can do, I've known people that you could not replace with 1000 mediocre engineers working for 10 years and they would't produce the same innovation, creativity and automation."
You say that, but is your brilliant programmer going to produce the same output at each of Microsoft, Google, or Xerox?
It is a matter of how you use them like anything. If you do your attribuitation wrong you will get nonsense anything.
If you have a 10,000 horsepower engine pumping water into a very hot large sieve vs a 1 horse power one into a sealed container the 1 Horsepower one and then judge the engines by the water gathered at the end.
Agreed. How do you compare a software project that succeeds with another that fails? Isn't the successful project infinite(X)-ly better? Therefore isn't the programmer who doesn't fail actually immeasurably better than the one who does fail?
If most software projects fail (ests: 55% to 90%), isn't the 10x programmer really just someone who consistently avoids failure? If so, a label like '10x' seems to measure concrete skills that don't really matter, yet fails to measure those abstract skills that really do.
The reason is that the impact can't me measured because we can't foresee the inventiveness of a brilliant engineer - if we could foresee then we are that brilliant engineer and are inventing ourselves. For the same reason the act of predicting scientific research is impossible because that would be the very product of research.
There's no upper bound on what a brilliant engineers can do, I've known people that you could not replace with 1000 mediocre engineers working for 10 years and they would't produce the same innovation, creativity and automation.