But some things i think you won't be able to replace --
You won't be able to replace speed on short-term projects. Lots of people means lots of communication overhead, which really kills fast responsive speed. If you value time to answer, you'd prefer a small team of really smart people instead of a large team of average people.
You won't be able to replace the insights. Tasks and knowledge are distributed amongst many individuals in bite-size chunks, so you miss out on insights you only get when someone holds everything in their head at once.
You won't be able to have a small team / small company culture anymore. You have to be large, standardized, bureaucratic, catering to the least common denominator. And then make up for it with volume.
I imagine within the tech world there are tasks that are ill defined and a small subset of engineers can solve, but a typical engineer may not have the background to solve it.
You actually hit this nail quite on the head with the example. The "10x engineers" get a lot of their "10x"-ness from creativity - most I've met are cartoonists, painters, musicians, writers, cooks - artists in general that love software as a way of expressing themselves and earning good money. The beautiful bits of code you get after are usually there because the starting point is "create it" not "implement existing solution/pattern".
I used to do design/graphix/ux work... that always interested me. Programming pays better, and I have a talent for it. I have spent time learning patterns, etc, but not through a formal education. I tend to just see a good way forward... creating discoverable code along the way. I find a lot of the time, the formal patterns tend to just make things more complicated than they need to be.
Just my own take on things. I'm kind of lazy in a good way. I have spurts where I will do a crazy amount in a short time, and those where I'm closer to coasting. Like many/most creative types, it varies.
The math is not that simple. The output of a Junior engineer is much different from that of a Senior engineer. You can hire any number of Junior engineers you want, and they won't have the vision and seasoned experience of a Senior engineer for producing higher quality code with less technical debt.
Even among Senior engineers there are different grades of experience/competence/capability.
central theme is that "adding manpower to a late software project makes it later."
Some engineers are just slow. I don't think it's much correlated with experience. If your goal was never to be a super productive programmer, I don't think you'll ever become one.
This might also be why there is this spectre of agism in the industry. Everyone knows there's greybeards out there that would eat your lunch and get paid the big bucks, but at the same time older programmers have hard times interviewing. At that age most of the really great programmers have probably already been fished out of the pond.
I will say, my recent stint of interviews over the past 6 weeks or so has been pretty painful. Everyone seems to be going through 6+ interview stages. The reality, even then, I'm not sure they're getting a great signal:noise outcome. Some of the tests are for things that will never be used for those jobs on any given day.
I do miss my 20's when an interview was maybe an hour and a half on an afternoon, and an offer shortly after.
They often seem to have the idea that it's more or less grunt work. Yeah, if a truck will haul 10 tonnes in one go, you'll get the same time if you hire an army of people, each carrying 10 kg on their backs, give or take economies of scale.
Another consideration is how much time we can afford for the solution to be wrong and need to be tweaked. For anything that has to work the first time, you want one (two, really) of your more sober and likely expensive engineers on the case, even if they aren't your fastest.
You may or may be able to replace your 10x engineer for this kind of work, but you're likely to be hamstrung by your interview processes.
Within a team, I think 'greatness' comes in all manner of different forms, all of which are needed. The person who holds the whole software model in their head, and can rattle off the precise changes required to implement a new feature. The person who has an encyclopedic knowledge of all the technologies, and often spotted sat next to another engineer helping them through an issue. The person who mid-way through implementation spots a flaw or an improvement that can be make to the process and comes back offering options for improvement. Of course it's great to have the person who comes back after 2 weeks having written more code than the rest put together - but.. well monoculture is always bad. Wouldn't want a team of them.
Any suggestions? (Short of let people do it).
This goes for clarity, difficulty and size of the task. Don't make someone bad at filling the details do an unclear task. Don't make someone unskilled do a clear yet difficult task. Don't make someone with no track record work on a task for too many days without supervision. Etc.
Unfortunately, people not meeting standards you would will always be a thing unless you're leading people more skilled in the area of expertise. Which brings it's own set of issues.
Delegating is knowing that you need to let go and ingest the fact that they are there to help. Mistakes happen and will happen. But that is part of learning for you and them. If they are not learning that is a different issue. Do not worry about it. You will learn what you can put them on better. But once they learn something they can turn around and help you learn. They can take care of it and you do not have to worry. Delegation is trust. Learning to trust is learning to 'let go' and being open to being 'hurt'. But also being willing to forgive and forget.
What seems to work is where areas of the product are assigned to specific teams - the overly-attached dev can at least see what's happening, provide guidance, without having to do the work, point to wiki that needs updating etc. Over time they'll build trust and can back away a bit.
What doesn't work is if work is given to a different team who just do their own thing and the 'parent dev' only finds what's happened to their baby on the commit/demo. Even if they've done a great job, it ruffles feathers.
Unless you can change that trait, it's going to be a hell of a bumpy road with no payoff.
I start my comment with an intent to indicate that these people are not what is meant when people say 10x. (maybe it's what some people think of when lambasting "10x" developers).
If you think you're a 10x engineer: you're not, you wouldn't see yourself as better, you'd see yourself as passionate.
As a >5x engineer I generally build out the initial design/development of a project and then hand it off to a team member to maintain. I get involved only when there is a new significant feature that needs to be added.
If competitors are working on the same feature and manage to roll it out of the door first, that spells trouble.
First version of Twitter was an almost complete re-write because of performance issues. But since their concept was dead simple, they had to get market shares fast else someone else was going to be there first.
It's hard to tell if it's arrogance or reluctance to admit some people are more valuable than others and just allow them to get to a point they prefer to leave than stay.
Domain knowledge, institutional knowledge, whatever you wanna call it, takes time to acquire and these kinds of companies are equally reluctant/arrogant to spend enough to hire properly. That's not enough to kill them mind you, not right away anyway, so they are destined to be mediocre at best I suppose.
If you are up or out as a manager, then any changes you didn't make right at the beginning of your tenure are going to unravel under the watch of your replacement. You not only don't have to reflect on them, but lots of people nominate someone else as the person who needs to fix it/take the blame. If there's a better recipe for willful ignorance, I don't know what it is, and I'm pretty sure I wouldn't want to.
Stating that a developer is worth 10 times what other developers are worth goes way beyond saying that some people are more valuable than others.
We're not talking about junior/medior/senior distinctions. We're talking about 10x. The myths. The lone gunman who is supposedly so good that is able to replace entire teams and still outproduce them.
Edit: I just noticed that you said the same yourself. Great minds...
Not having a backup solution is probably the single biggest shortcoming of the lone gunman in practice. The second is that the code is often not laid out or structured so that a team can work on it.
Hypothesis: the "10x" developer does not actually have 10x the output of a single average developer, but rather the same output as 10 average developers working together (and having much of their productivity eaten up by coordination overhead).
One of the aspects of having a chief programmer (and there's another HN article making the rounds on heroes for projects) is that they're able to conceptualize/structure/design an entire application or module.
A chief programmer, doing a "this is how we're doing it" and with all the parts in their head and working to that end will have better overall "idea to deploy" performance than someone who is given the task of "do X" and may have to come back to it again to reconcile their implementation of X with the design of the system and its goals.
The way to resolve that is to get everyone who is working on it on the same page for the design... and that takes meetings leading to the issues with adding more people to a project will make it later.
The original author always knows not to push buttons in this order. Two people who are communicating badly will find a way to do so sooner or later, and if the system doesn't slap you on the wrist for doing so, it's gonna be a bad day.
On the plus side, systems with these sorts of guard rails are better opportunities for self-directed mid-level developers to pull themselves up to a senior role. One man bands are notoriously awful at affordances for discoverability.
I think I do better than most but any time I want to shed a responsibility I always have to first add more docs and a handful of extra exceptions and/or exception handlers to the code to make sure the new person doesn't immediately have a bad experience and toss it back to me. I call it sweetening the pot but others might use a different description.
If we believe that the talent within a field follows the power law, as suggested by this study (http://www.hermanaguinis.com/PPsych2012.pdf) it means that only 20% people in the field are high-perfomers, and something like less than 5% exceptionally high performers. When you look it from the perspective of scaling an organization it means that getting these people to your company will be very hard. 80% of companies are hiring within the "average or below average" section. The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.
There was originally a section the article that tried to highlight "statistics", but I eventually left it out, because I did not find a good place for it:
"Statistically speaking, it is much easier to create a "10x engineer" by creating an organization, where most people perform poorly than actually hire and retain someone, who really is 10x better at software engineering than an average person."
In hindsight, I think there are a few things that could have been emphasized more, so the thrust of the blog post would have been clearer:
- The title could have been better frased around the topic.
- The context is companies that are growing fast and need to scale.
- You likely have a company full of close-to-average people.
Is there a source for this claim?
How likely are they to move exactly, and what motivates the non-movers to stay?
Motivations differ based on what the person values. The top motivations I've experienced are:
- Money
- Following intrinsic motivation and being able to grow professionally
- Friendships and the feeling of belonging
- Stability and not taking any risks
The people in the last two categories tend to change jobs more slowly in my experience, but most still do it at some point.
I'm not aware of any reliable studies on the subject from the field of software engineering. If someone knows one, I would be more than interested in reading one.
Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.
I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.
Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.
The dynamic you describe tends to get stronger, when consultancies grow. The voices & competence of the technical people becomes less important when it comes to the business and efficiencies in utilization and the company brand start to matter more. The consultancy I worked at was not an incumbent, but an underdog competing with the big players, so the actual execution mattered more, when trying to win bigger customers. Even in consultancies, there are operational effiencies you get from having competent people. Mainly from having less middle management & account managers.
However, there things are useful for the consultancy's business only to a limited extend. You only need to be slightly better than the average consultancy and you're OK. So there is a point, when you either need to be great at sales or thought-leadering, or a consultancy can no longer increase your salary or provide your with work you find interesting.
For "underdog" consultancies, i've always felt that they win by
1) sending their A team where an incumbent would be sending in their C team. That would make sense, as the incumbent's A team is on a more important client, whereas this small client "is" the underdog's important client.
2) carving out niches and specialties. So you serve less clients and projects, but also build up a reputation. You kind of become an incumbent of sorts, just for that niche.
As for product-minded engineers, there is often more freedom at a smaller a consultancy than in (many) product companies. You can switch projects every 3-18 months, select a new technology you want to learn, have big ownership on the helping the customer building the product, etc. To some people this is ofc a downside and a lot depends on the kind of client/project you're working in. Much of this also is lost, when the consultancy starts taking on bigger projects with bigger clients that already have much of these things set in stone.
The one that made the decision to change it, and actually ported the code, easily wins the 10x badge when we consider the high support cost of that brittle piece of JS code in production.
> institutional knowledge is lost.
Exactly! Say a dev rewrote the brittle piece of JS to resilient JS, and did this REALLY fast. Great, you may have a 10x'er on your team! But in this case the knowledge is merely with one guy, he has the experience and discipline to write resilient JS: something rarely found in human beings. In this case the 10x'er may be a 10x coder, but not a 10x architect/techlead/CTO.
Hence I dont like to depend on human's experience and discipline, but prefer to fix it with Real Good Tech and Tooling(TM).
Do you think the developers who rewrote everything in Dart or CoffeeScript a few years ago were actual 10x productive for the business in the long run?
The integer solution is not great, but is mathematically consistent despite what many believe (it’s true in most proof assistants, for example).
Maybe time to study some of that "hipster stuff".
I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).
I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away.
A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewrite.
If you do the rewrite as a learning exercise or CV building, great for you! But probably not for the business.
Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.
JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.
Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.
Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).
But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.
Bottom line: Converting runtime exceptions to logical errors is a very bad trade.
I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.
I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.
This is the common definition.
Defining runtime errors as just being exceptions is clearly absurd - that would mean languages like C or assembler cannot have runtime errors!
How this relates to 10x or not I don't know - I'm not sure the discussion is a productive one without further context.
It might be that for some tasks, Elm really does provide a huge benefit in productivity. In that case, it's probably fair to call a developer that selects and uses the tool correctly a 10x developer - provided they are able to evolve the culture of their company so that others can take advantage of it.
For other tasks, or in other contexts, Elm might be a hinderance. If it's lacking an indispensable library, or if the company culture is not ready to accept it as a core language, it won't help anyone to rewrite in Elm.
As always, one of the key things that makes a good (even 10x) developer is the ability to select the right tool, and to wield it gracefully.
Pretty cool!
Same way rewriting your code in Rust doesn't make you a 10x developer for removing memory safety issues.
A 10x more productive developer is more productive within an ecosystem against others who are also in that same ecosystem. It's not fair to compare a C developer to a Rust developer in terms of developer skill. But maybe productivity you could. Like how Python is more productive than C++ but you don't call the Python developer a 10x developer.
I guess what I'm asking is if there is any actual data on this so we can look at actual statistics or if it is all just a meaningless blogspam topic.
Performance is relative, so if the norm is 0.4x, that's the actual "1x" base to just 10x programmers by, even if it's below what a 0.4x programmer could potentially achieve if they really tried.
In other words, if most devs are underperforming due to complacency, lack of motivation, etc., that should also factor in in the 10x programmer calculation.
So, 10x doesn't have to be "10x as good when both are 100% motivated" just "10x as effective" is enough (even if it's because they are more motivated and not actually more intelligent, knowlegeable etc).
>There is also a significant variation in how the same person performs across multiple tasks.
Not only that, sometimes one individual can engineer things 10X better than at other times.
>Do these two engineers have the same experience with the technology at hand?
No, one has 10x the experience.
>How familiar are they with the system they're working on?
Very, one is just 10X more familiar.
>Do they have the same ability to make decisions on the go?
No, one is a 10X better decision maker.
>How easily can they get help?
Both easily, but one of the two only needs help 10X less often.
But practically does it really matter?
Even if we knew the case, one can't just e.g. whip 0.4x into 1x, so a 2x remains a very valuable 2/0.4 jump.
This is pure speculation, which is why actual data would be useful. Is a measured 0.4x performer that way for innate reasons or is that something which some combination of training and mentoring, better tools, streamlined environments, etc. can help with? — or is the way that's measured even valid? I've seen a few cases where someone got flack for being slow until wider perspective showed that they were the only one solving the customer's real problem because it turned out that what they were doing was more complicated than it looked and/or the other guys were “solving” it in ways that required lots of ongoing maintenance.
For this or that individual (as per your example of "a few cases"), maybe.
For the majority do you think there will be something that hasn't been tried until now, what with all 2000 methodologies of management, team structure, company culture, development methodologies, tooling, agile, waterfall, and what have you, that will suddenly make a difference?
0.1x developer might be a 10x developer that has given up because the build or management is fundamentally broken. Working more will just lead to burnout.
a 0.1x developer might be someone who at some point was very talented but now has no clue, but enough savvy to stay on as a lead/architect/senior
a 0.1x developer might not be qualified, but was hired because the company paid well below market rate.
Many reasons... A 10x is motivated, intelligent, and in the right place at the right time.
Office environment was a factor in performance.
There are some programmers who are worse than nothing happening. So a 10x looks better by working accords the averages of all the 1x, -1x, etc.
That article starts out with...
> We've known since the early sixties, but have never come to grips with the implications that there are net negative producing programmers (NNPPs) on almost all projects, who insert enough spoilage to exceed the value of their production. So, it is important to make the bold statement: Taking a poor performer off the team can often be more productive than adding a good one. [6, p. 208] Although important, it is difficult to deal with the NNPP. Most development managers do not handle negative aspects of their programming staff well. This paper discusses how to recognize NNPPs, and remedial actions necessary for project success.
> Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]
Source 21 is: Shneiderman, Ben Software Psychology: Human Factors in Computer and Information Systems (Cambridge, MA: Winthrop, 1980)
https://www.amazon.com/Software-psychology-computer-informat...
Many companies do have an individual contributor track, and that's a big factor in where I choose to work, but way too many companies seem to think it's all kinda the same thing.
(To be clear: none of this is neglecting the importance of, or talent involved in, managing people. Bringing out people's potential requires tremendous skill, which I don't have, and that's why I won't do it.)
This can be a problem when there is only one high-performer.
You hire all high-performers so this is not what happens.
What I have met are 3x engineers who protect their own job security so severely that they make everyone else a third as effective.
3 * (1 / 1/3) = 9
Meanwhile I'm a 3x engineer who makes everyone else twice as effective. Management sees me as a 1.5x engineer, when my actual factor depends on how many coworkers I have.
What would the Rolling Stones look like if someone had said, "Our organization shouldn't be resting on the shoulders of Mick Jagger"? What would Google look like if someone had said "Our organization shouldn't be resting on the shoulders of Jeff and Sanjay"? What would CSAIL look like if someone had said "Our organization shouldn't be resting on the shoulders of Minsky"? They'd look like mediocre failures.
"How are you going to replace Jagger if he quits the Stones?" is not really the right question. You have to accept that the Stones without Jagger, or Bell Labs without Thompson, just would not be the same. To a very great extent the productivity of a creative organization depends on its ability to attract and retain high performers, because it's inevitable that it rests on their shoulders. Denial won't change that.
If you want your organization to succeed in a creative field, the right question to ask is, "How can we hire people like Ken Thompson, and how can we keep them from wanting to leave?"
When I left my last job, part of what I was doing was replaced by a team that built up to 5 engineers last I checked. They're doing it more intensely (although, I don't think with better results), and they've got to have a lot more communication than when I did it (I was trusted to do cowboy deploys to an isolated system, they've got to deal with code reviews and just making each other aware of what they're doing because 5 people in a small system means overlapping work). And, I did a bunch of other stuff too which AFAIK didn't really get picked up, but hopefully they've been lucky and not had weird TLS problems or other 'select is broken' experiences lately.
But it means I'm expected to be available constantly. I'm not a one-man team but I tend to be the first point of contact for people outside our Eng team. It gets a bit much sometimes.
Some people like to be present and suck up.
But some people really do just work hard, smart and have deep passion for what they're doing- and importantly: pride, which makes the quality of the content great too.
Some of the best engineers I know "visit" bits of code or infrastructure and afterwards it's a pleasure to use and rarely if ever has weird bugs, and if they do have bugs they're easy to root out.
What I'm trying to say is: high performers exist. But your organisation shouldn't be resting on the shoulders of those people.
People leave. If your 10x (or 3x or 5x) engineer quits: are you really going to hire 3,5 or 10 people to replace them? Unlikely. And even if you do, institutional knowledge is lost.
It's not a myth they exist, but you shouldn't depend on them.