I know "10x engineers" exist; some people are fakes and put forward things that look like they have high impact but are actually a bit shoddy.
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.
If we're taking about is just output on a larger macro scale, then yes, hiring enough people will replace 10x engineers.
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.
Just to give a concrete example: no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck. Throwing 1000 engineers won’t solve the problem.
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.
>no amount of software engineers can be hired to produce comparable work of an expert cartoonist except by dumb luck.
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 generally consider myself a 5x coder... I usually spend about 1/3 the day reading/learning and another 1/3 experimenting... only about 1/3 of a typical day will I be on-task, and usually still outpace my peers. This last 2-week cycle, I literally did all the assigned work, and refactored a few things that annoyed me in one caffeine fueled night.
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.
I think its important to understand there are also relatively high floors to getting certain things done well. If the engineer is too junior or simply not good enough, its not that you will get there slower, its that you may not get there at all. Or you get there slowly and with a very buggy or unmaintainable mess. Some engineers can even go backwards in that sense, attempting to optimize the wrong solution and spending months on something that in honesty can't actually be completed.
I've had junior engineers outperforming senior engineers, even counting the hours I had to spend correcting and guiding.
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 think it depends... where I am now (third from last day), I'm one of the younger devs at 46yo. which is wild to me... about 2/4 of those here older than me have little interest in taking on new approaches or techniques. The other 1/4 absolutely work to stay current. Some are coasting to retirement, others of us don't ever plan to stop.
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.
It's crazy, I wonder if it actually works and they actually get a higher percentage of good coders. I just do a face to face, then a take home assignment, then another face to face where we discuss the take home, and then I immediately make the decision. I skip the take home if they've got impressive GitHub accounts or other clear public displays of skill.
The issue I seem to often see, for some reason, is that people who have a say in hiring often don't realize themselves that the great engineer did something quickly thanks to an insight, or, more generally speaking, thanks to being very good, or being able to turn the problem on its head, as opposed to pure brute force.
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.
There is a flip side to that as well I think. One 10x developer can be more productive than 10 developers, but often 10 10x developers cannot be as productive as 100 developers. Certain things just don't "scale out" with the sort of creative advantages that highly productive engineers use.
Overly complex code is more difficult to modify than elegant simple code. A 10x developer will produce simple elegant code. That is one reason why they are a 10x developer. Ten 10x developers will create a much more simple solution than 100 standard developers. Standard developers usually create a mess. That is what always happens, we have all seen it. So 10 10x will be much more productive than 100 standard developers.
Speed an accuracy are on different dimensions that are somewhat independent.
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.
I've worked with a few developers who are great - people who get bored of waiting so just build it themselves one evening whilst everybody's arguing over funding/recruiting the team we thought was needed.
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.
Oof, sadly this sounds like me... It's hard to delegate, and even harder to trust that it's done correctly. I know this will be my undoing someday, it also drives me insane because it puts extra pressure on myself...
Start small and practice. Evaluate how people react to the task size and experiment from there. E.g. don't make someone annoyed by tasks way under their stature grow at the same rate as someone who struggles to deliver.
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.
Realize that others are at other points in their lives. That just because the code does not look the exact way you would write it does not mean it is not bad/wrong. There is always one more refactor to do. There is always more bug. Worry about what you can do. Help others when they need it (not when you want to, this is tricky to not become the knowitall guy).
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.
I'm not a developer, so maybe not the best person to ask.
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.
On the flipside, I've met "10x engineers" who always prioritized working on highly visible and strategic new features, and excelled at shipping them as fast as possible, even if it meant racking up massive technical debt. By doing this, they effectively did produce 10x as much in the eyes of management, and got promoted and rewarded in kind. The technical debt they racked up then got paid by everyone else that had to go in and make their prototype maintainable while they were already off to the next high-profile project. Not only did they not have to stay and cover the cheques they wrote, they also managed to lower the effectiveness of everyone else, lowering the baseline they got compared against, so they could be 10x instead of just 5x.
> On the flipside, I've met "10x engineers" who always prioritized working on highly visible and strategic new features, and excelled at shipping them as fast as possible, even if it meant racking up massive technical debt.
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.
I have the opposite issue here. I have an engineer still writing VB6 code and we have 20 man years of his technical debt we have to live with. He never learned anything new and he has a hammer and everything is a nail.
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.
Though, the order of events might be backwards there sometimes.
The director has a highly visible and strategic new feature they need executed, so they'll handpick the best engineers to work on the project. The engineers complete the project as fast as possible because that was the point of the project, to get the team that could produce a MVP fastest. And the technical debt and productionizing of the project is something that can be done by a less specialized pool of developers, who also are given way less tight time constraints.
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.
That’s right, the mythical 10x-er who does greenfield work, uses the latest tech, who not only never maintains their masterpieces but moves on to other pastures causing other devs loss of productivity and captive to their mazes..
> It's not a myth they exist, but you shouldn't depend on them.
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.
One of the hard lessons I've learned in software is that force of will can make any development or management process work for a little over 12 months before the cracks really start to show. By then people (and by people I mean folks who don't think the way I do) have cemented that process in their heads as working and they want to ignore the data that says it doesn't.
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.
> 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.
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.
MapReduce. Leveraging lower level abstractions incipient in the early Google datacenter (distributed FS, distributed process executor) and providing a simple but expressive programming model for distributed large scale batch computations. A significant amount of effort went into documenting and exemplifying the usage of the programming model for a large number of use-cases. Chosen to serve thousands of use-cases all across a fast growing company. Developed by 2 people. A fantastic example of '10[00]x engineering', and yet I can't imagine something more antithetic to the 'lone gunman' strawman.
A really good developer can and will absolutely outpace a couple small teams of developers. The shortcomings is the domain knowledge is locked in one head. You gain and lose a lot depending on how many people are involved and how much you have to communicate.
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.
As the MapReduce example shows, the domain knowledge is not necessarily locked in one head in cases like this. I haven't heard complaints from Googlers about how Jeff and Sanjay write unmaintainable code, either. My own non-Google experience is that extremely productive programmers tend to write code that's more readable, not less readable.
Are we sure they're not actually the exact same problem?
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).
That is a good point... and gets back to the chief programmer of the MMM surgical team.
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.
Yea funnily enough I just added a comment along these lines about restaurants in a different story. Just because an engineer is 10x better in some sense that another one, it doesn't meant that 10 of the lower quality engineers will make up for it, just as eating 10 times at McDonald's isn't going to be as much fun as eating once at a great restaurant (for most people)
I'm a good cook, but compared to Wolfgang Puck, I make shit on a shingle look brilliant. You could hire 100's of me and not get a decent restaurant. After so many decades as a programmer, there are enormous gaps between programmers in their ability to deliver quality. Calling something 10x is not a measurable quantity, but watching quality delivery over and over gives you the impression; the number is arbitrary.
Yes, this is obviously just considering utility at a higher level of the hierarchy of needs, not pure subsistence. Otherwise everyone should just be slurping Soylent all the time I guess.
More people means more human error, which means that not only do you have to invest more in communication overhead, but you have to invest more in sanity checks to keep your state machine in bounds.
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.
Author here. There definitely are people, who perform better than others, even when the environment is not built to favor them and hinder others from performing well.
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.
”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.”
Is there a source for this claim?
How likely are they to move exactly, and what motivates the non-movers to stay?
This is based on my limited personal experience observing the careers of people I know, whom I could consider somehow exceptionally good at their craft. I co-led the CTO team of software consultancy with 350+ devs. In that role it was pretty clear that it was really hard to compete on salary and how interesting projects experts could be offered.
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.
I would probably consider consultancies very differently from product companies.
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.
In my experience the difference between good consultancies and average product companies is not very big. On average I've seen consultancies being able to attract more technically curious and product-minded engineers. The exception are the product companies that are somehow special in the market (e.g. can offer a significantly better pay, or do something very interesting in terms of scale or technologies).
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.
Interesting on that first point, that's not what i would have expected. So what are you seeing from these product-minded engineers that leads them to choose a consultancy over a product company?
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.
Both 1 & 2 are valid strategies for underdog consultancies. Consultancies that are very good at #2 may also have better ability to keep people, who are exceptionally good at some specific tech or domain, because they usually have higher rates and peers that are good at the same thing.
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.
If a brittle piece of JS (with high support cost due to runtime errors) is replaced with a piece of Elm, the runtime errors are gone.
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).
Someone who thinks all bugs will go away if the code is just rewritten in the hipster niche language de-jour, is probably a 0.1x developer. They may work hard but don't solve any real problems for the business and leave a mess to future maintainers who have to spend time debugging the forgotten hipster languages of yesteryear.
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?
You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular.
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 not knocking Elm at all, I think it is a very interesting language.
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.
It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.
No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug.
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.
Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors may crop up, it’s a worthwhile trade to many people.
To be fair, the grandparent said 'runtime errors', not 'bugs'. And it is a stated goal of the Elm language that runtime exceptions thrown from the compiled Javascript should be impossible. As far as I know, they have succeeded in that goal.
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.
I'm sure Elm is a great language, but thinking it eliminates runtime errors is ridiculous. Of course it might eliminate exceptions, but exceptions are not errors, rather they are (sometimes) signals than an error have happened.
The question is, why was these run time error not caught by unit tests? Probably because there wasn't any tests - which means the code likely have numerous logical errors. Static typing is great, but it will not prevent against logical errors. So without testing you will have bugs in any language you rewrite in.
This is wrong. Rewriting your code in Elm (or other niche language) doesn't make you a 10x developer.
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.
>Is it really that 10x performers exist, or that 0.4x performers are abundant so 2x performers look like 10x performers?
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).
> 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.
>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?
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?
I think there are plenty of things which make a difference — for example the training and mentoring I mentioned — but the methodology point touches on the problem that they're neither cheap nor easy and most places are unwilling to invest in them. Very few companies which “adopt” something like Agile manage to substantially transform their culture because that's hard and it's a lot easier to make an announcement, do Agilefall, and avoid hard conversations.
Having worked at really high quality startups, and low-quality companies, this is a real thing.
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.
The Survey cited in Peopleware says that it is a 10x difference between the best and the worst performers. The best performers were something like 2.5x the average performer, as measured by time to complete a specific coding task in the 70s.
Peopleware is 30 years old though. Back then very few decided to become programmers. Today when everyone flocks to the field chasing money and you have several orders of magnitude more programmers the ratio could be very different.
> 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)
Yeah, this is an important point when thinking about it from an organization perspective. I've been at places where they "only wanted to hire rockstars" which was beyond stupid. By definition 10x developers are rare and are going to have a lot of options when it comes to where they work. So if you depend on some member of the team carrying a hugely disproportionate
amount of the work, then you are in for a rude awakening when they jump ship.
The problem I have is they always want me to train someone as insurance for if I leave. It becomes a self fulfilling prophecy when you make me work and train mediocre people. I just want to build great things and be left alone.
This is something our industry needs to fix. I've turned down promotions so many times because they amounted to moving from coding to pastoral care. Which is bizarre - it's like a surgeon being offered a promotion to work in HR.
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.)
If you trained one or more operators who have already left for alternative employment, you could point out that there may now be other orgs making more money from your technology than your own employer is.
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.
You don't always have a choice: you cannot replace a person that can read with 10 people that cannot read. All of the very few "10x people" that I met had expertise far beyond their team mates had and they used it well.
People don't always leave, although they do die. Peter Norvig has been at Google since 02000. Jeff Dean has been at Google since 01999. Ken Thompson was at Bell Labs from 01966 to 02000, when he "retired" (but, really, Bell Labs no longer existed). Mick Jagger has been in the Rolling Stones since 01962. Marvin Minsky was at the AI Lab from its founding as Project MAC in 01963 until his death in 02016.
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?"
> 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.
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.
My employer considers me a 10x developer. It's not a title I'd choose for myself. I'm the only software engineer to be on a bonus scheme, which is great.
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.
Make sure your enployer isn’t just stroking your ego to make you work long hours and take on more responsibility. Make sure you get the compensation you think you deserve not future promises..
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.