I strive to be a 0.1x Engineer (2016)
benjiweber.co.uk
benjiweber.co.uk
Imagine the software you can write, if freed from societies expectations of sweat, tears and busy work. Not to be rich, just to be technical excellent, productive and at peace.
I wonder why this has not yet happened with open source. If a sufficient enough part of the public uses your software, the state offers you a maintainer role. Nothing big, but enough to life on and do work.
Before you get a tenured position, you're basically stuck in the publish-or-perish rat race and when you eventually get a tenure, you now have an enormous responsibility towards the younger non-tenured reseachers of your department, who will eventually lose their job if the department isn't “productive” enough, so unless you're a complete insensitive assh*le, you'll still be under pressure.
Some people love academia. My PhD mentor is as happy as a pig in mud in his academic role. He only has to teach every other semester, and his course/lecture plans are solidified such that all he has to do is recite his notes beside slides and answer questions. He has to schlep to the classroom two days out of the week in these semesters, but his classes are back-to-back so that even those days are spent mostly where he likes. All of the rest of his time is spent happily “doing research” in a domain in which he’s a world expert. Publishing is a specialized sausage-production manufacturing domain, but if you enjoy the subject matter like he does (and I do) it can be a low-effort byproduct of effectively playing with code and ideas.
At my research university, even associate professors (not sure about the details of what’s tenure track) don’t have to teach that much. There are actually “teaching professors” here who’s sole responsibility is teaching without research pressure, and they still only teach two classes per semester (admittedly, those classes might have 300 students).
I was deeply inspired by these lifestyles, but it turns out not working for a boss doesn’t fit my personality. I’m too much in need for social validation. Work and suffering are a religion where I live. Programming makes me mostly anxious and I need to be surrounded with colleagues to get comforted. Consumerism is also a religion. I have a hard time being surrounded with people who are able to indulge in consumption while I’m not.
I can relate to the vicariously living through reading part of your message, I love coming across people who share their alternative lifestyle!
The fact that the most successful ideas&products weren't born in such places might cast a shadow on the attractiveness of this perspective. I think that without a challenege the mind is at risk of atrophy.
You need to be able to let the subconcious do its thing, for which it needs peace, quiet and freedom from stress. Difficult to do the step back otherwise.
The stress returns, when things then get traction, so i guess the truth is - alternation between stress free "creative" periods and stressy "realization" periods?
No idea what the optimal sinus is.
This idea that x person worked a little harder than the rest and therefore he is successful is laughable. There is a range, say 5% or 15% or even 50% ‘worked more than the rest’, ok so what? Do you think you are within 5% or 50% of working x hours more per day before you become the next tech billionaire? You are not. It’s not that easy.
Oh and then there are the struggling artists of the renaissance which all came from the illiterate peasantry struggling to feed themselves.
And the media common folk of today, who come up because they struggle therefore they act, and everyone we see in TV was a nobody before their first big role and just worked really hard right?
Or the government families which somehow if you are the son of a governor your chance of being in government and a high ranking official far outweighs any other factor.
Or if your parents are rich chances of you being rich far outweigh anything else…
But no, alas I’ll let everyone know we gotta push just a little harder and we’ll all be rich.
Struggle breeds stress, which intern breeds health issues. If we didn’t struggle the world would not end, innovation would not stop, WALL-E is just a cartoon.
Einstein was able to always study and Sergei Brin was able to work like a maniac precisely because they were able to remove the restrictions of paid technical labour that drains your brain before you even get to the interesting stuff.
Programming is no different. Other developers code in their free time. If your low energy maybe you need to fix that part?
Struggle implies unsuccessful efforts. These men were not bound to busy work, crying for help. They had comfortable settings and could focus on what mattered to them. OP wants just that.
Arguing that "get out of comfort zone, grind, struggle" is the way to advance society is disingenuous at best.
A full time phycisist already tends to work a lot of overtime hours to get anything done, while already doing that as their main fulltime job activity, so with 100% certainty Einstein grinded like a madman in afterwork hours to do his actual research. This is also why he quit that patent office job as soon as he was able to.
Not to criticize your approach. genuine 0.1x programmers allow 10x (aka 1x) programmers to exist and get a lot of money doing a normal job.
You should not conflate focus and effort with physical busy work. Grind means literally to wear down physically. Theoretical physicists don't 'grind' by any stretch of the imagination.
People should absolutely be allowed to be comfortable, free of immediate concerns with acquiring resources to survive. As OP puts it, 'freed from societies expectations of sweat, tears and busy work'
Arguing against this right is drinking the elite's cool aid. If you don't profit from exploiting the working class, you shouldn't see a problem with setting them free.
> I think that without a challenege the mind is at risk of atrophy.
Not everyone needs external challenge of "afford rent". Some people are entirely fine with picking their own goal and striving for it, without their survival at stake.
It was quite satisfying and made me realize that I should be doing this for a living. I quit that company for way better pay as a software developer. I don't know if I'll be able to find such a job again, but I really enjoyed it.
I never hid the scripts. The automation was out in the open and everybody in the team was making use of them.
I quit because I didn't receive pay raise and wouldn't have in that position(EDIT: They wanted to promote me to team lead(people management), but it is something I'm not interested in). Plus with the skills I've gained I managed to get a better paying job.
It's nice to do good work and not pollute it with the usual growth strategies, to tell advertisers to sod off, and to obsess over details of your choosing.
This completely changed how I work. If it's sunny outside, I'll forget about work and go ride my bike. But I'll also take a day during my vacation to implement an idea because it's just can't wait.
I don't know how other people work, but I found my perfect way of working. I've never been so productive before.
It didn't happen because people already do it for free, so why overpay?
In a way, it's more of a joke article responding to a joke meme that has some good points over actually being a fully serious article criticizing actual 10x more productive engineers.
Just talk to a manager and slide that into the conversation, I bet 9 out of 10 will recite the gospel unironically. I am guessing these numbers aren't that better for software developers.
Because all this can easily be mixed with job performance and effectiveness which are obviously real things.
Much greater leverage can be found in the ability to innovate, to have the undestanding needed to quickly select a good approach to solve some problem and the social skills needed to lead a team or company in a direction where they can (to re-use the term) leverage such new innovations in ways that generate maximum value.
For instance, if you have a team that uses RESTful java microservices on k8s for EVERYTHING, many compute heavy or IO heavy tasks may require massive clusters to run a data processing pipeline.
If you're the engineers that identifies this as inefficient, finds way to build the pipeline using a more suitable tech stack, and introduce this stack to your company, you could the infrastructure cost of a company by millions per year. That's kind of comparing the use of cargo ships to mules for transporting goods.
And if the tech you introduce also enable 10 other devs to develop 3x faster, this alone would make your effort as valuable as having at least 20 more such engineers. (20x).
People obviously differ in abilities, but those differences are massively exaggerated by the environment. The best engineer at Twitter probably isn't getting much done this month. Conversely, a few people who were solidly average at their last job are probably rocking it because they've landed in a place where the work is a good match for their skills, the path forward is obvious and feels secure, and they're getting the needed support from their colleagues.
Since the "10x engineer" is defined relative to other engineers, the right comparison is probably more like "other runners" than all people, which of course narrows that gap even more.
[0] https://jamanetwork.com/journals/jama/fullarticle/644554 summarizes some studies in Table 1.
A walk around Central Park is about 6 miles, for comparison. Throw in a museum or two and you're mostly there.
Innovations and inventions, even in a very small and local context, may easily generate >10x more value than the output of a stereotypical "code monkey" who at best delivers according to a well written documentation.
It's more than 100x really, because of you took one of those guys who can't grok for loops and asked him to create esbuild, they will never be able to do it.
There's a lot of leverage in software engineering, and a lot of room for difference between people.
I've met plenty of devs who are better at relieving technical debt than fulfilling business requirements.
Who is measuring the productivity?
"Productivity" could be defined as the value (typically monetary value) that the value of the company is generating (before salaries) based on the contribution of that resource(engineer in this case), per unit time. Future income should be calculated using a present-day-value approach.
The productivity of a single engineer could be defined as the reduction in company value generation from removing that person from the company (assuming the company is large enough to have multiple people available in each role). Rank order this, and you can define the 10x as those whose removal would cost the company (before salaries) >10x more than the removal of the median contributor.
Note that this definition is based on productivity within a given company. A single person could be a 10x engineer in one company, and a 1x engineer in another. Some companies require engineers with very deep understanding of compter science, maths, statistics or physics. Others benefit from engineers that are domain experts within their business domain, and yet again other companies may primarily need engineers who understand and can work with people of all backgrounds.
I don’t think anybody can dispute that 10x programmers exist, Bellard, DJB and Carmack being uncontroversial examples.
What’s controversial is the distribution. Are 10x programmers bound to become famous through their outsized contributions, such that their number is very few? Or are there a large enough number of 10x programmers working in obscurity such that you might have one on your team?
You assume the median is competent.
There are quite a few engineers/devs out there that produces negative net value, when taking into account management overhead and other resources consumed (even when ignoring their salary). Some of these are just in the wrong place, they don't have the talent, skills or motivation to work well with their team, and but might be "competent" in another team.
Even at the median level, output may often lack creativity and inspiration, and add relative little value. The functions they do may be easy to oursource, replace by standardized software or could be built by better developers much more quickly and with higher quality.
I think in most companies who do software development, at least half of net value is generated by the top 5-10% or so developers. (Making them 10x engineers compared to the median). These are the ones that drive new ideas and approaches successfully (instead of chasing cargo cults for no benefit), they are the one that write the code that other developers imitate and build on top of, and they are the ones that contribute to team engagement and cooperation. (Or at least 2/3 above.)
As for the number being 10x the average developer, that's much lower, since the top 10% pulls the average up quite far from the median. I would guess 0.1%-1% is 10x the average, depending on company.
These would be the ones that are able to identify and solve problems others are not even aware exist (or have given up on), the ones that understand the business they're in better than most product managers, and actively drive development of killer apps/features that others didn't even consider. Often they're entrepeneurs or leaders as much as developers.
Echoing what others have written. The median programmer is a not a "competent programmer". The median programmer is pretty bad.
EDIT: Or to be precise, "competence" depends on how you measure it. The "median programmer" is certainly competent at many tasks.
But there are plenty of programming/engineering challenges that the median programmer is completely unqualified to perform.
The idea of a 0.1x developer, 1x developer, and 10x developer sitting frozen in amber beside each other, ungrowing and unchanging, never responding to their work environment, always at fault or worthy of praise for any differences in personal productivity, is ridiculous.
You said that there's a 10x difference between the best and worst member of your team, in response to a post saying that the concept of 10x developers is hard to take seriously. I assumed this meant you thought calling the best member a 10x developer was a good idea, which is what I disagree with.
Are you saying that calling people 10x developers is not a good idea, but there's still a 10x or greater difference between the productivity of the highest performers and lowest performers within a single team when observed over a couple of years? I agree, but that argument's a very strange one in the context of the post it was responding to.
There are people who can attack new problems or develop completely novel solutions, and those who are capable of solving problems that that might not technically be new, but they require deep knowledge of several disciplines.
And there are people who are simply incapable of doing those things. They might be adequate programmers, able to work productively on existing projects and variations of solved problems, fine tune them, solve difficult bugs, make them work real nice. But it's not the same thing, and it's easy to see when you have worked with the former types.
And compared to those, every engineers that produce >0 value is an infinite-x, making this quite trivial.
There are problems where the average or even majority of engineers would create exactly zero value over time.
When I said infinite is impossible, I meant in absolute terms, not relative to somebody else.
n-x-engineer means that: productivity_of_n-x_engineer / productivity_of_reference_engineer >= n (assuming the reference isn't negative)
etc
So, I'm arguing that the numerator cannot be infinite, so if n is infinite, the denominator has to be 0. In that case _everyone_ with positive productivity would be infinite-x, making the term kind of trivial.
I'm not arguing that such a situation cannot occur for some role, it can certainly happen that a company fills 50% of more of engineering positions with completely unproductive people.
And if, as you seem to do, measure this per problem, not per employee, it is really common. There are a lot of technical problems that only a small percentage of engineers can solve. Even then, though, even less gifted engineers may find some other technical solution that addresses the same business problem well enough to provide more than zero productivity.
Sorry if this wasn't obvious....
The whole thread is about relative terms, including when I said infinite-x. And the context is clearly about certain worthwhile problems, nobody talks about a 10x engineer as someone able to make a trivial phone apps or web pages 10x faster than than average.
Relative means numerator/denominator. My first reply was simply breaking that down into parts, aruing that the numerator could not be infinite, and that the denominator being zero is not a very interesting case.
> nobody talks about a 10x engineer as someone able to make a trivial phone apps or web pages 10x faster than than average.
Actually, that's precisely what I think a lot of people who hear the term interpret it as. Especially from those who reject that the 10x engineer exists.
And there are quite a lot of engineers out there that believe that all any software engineer is doing, is to follow detailed instructions/specifications for some product, whether that is to make trivial web page or improve how gcc optimized code on a new cpu architecture.
While in fact, the most productive engineers out there do NOT follow such specifications from others, but rather develop something revolutionary based on their own ideas. You're not likely to find 10000-x or better software developers that don't do it like that (I would argue that people like Linus Torvalds or Elon Musk would rate at around the million-x level, but not infinite-x )
And what I was talking about are very complex or new problems, and here are absolutely infinite-x people. Things where the average engineer will create exactly zero value on over time. I don't know about Musk, but Linus is of course one of them. Task someone to write a scalable distributed version control system before 2005, and the average engineer will be incapable of doing that.
If you wanted to talk about something else entirely like working on simpler things, fine.
I mean I work in Data Science and do quite a lot of programming but I'd assumed my abilities would be far below that of any Software Engineer.
I can't believe anyone would get hired who couldn't do fizzbuzz etc.
But I'm 99% sure the enterprises are aware of this. They want the good developers, but realize they have to deal with bad ones too, and are willing to pay the cost and accept the risk it brings.
I mean outside of that it's fairly normal that a team will have a healthy mix of seniors (who do the meetings) and juniors (who do the work), but you'd still expect a baseline of quality and a technical interview there.
Remember "Unicorn Devs"? "Framework Evangelist"? "Superstar Developer?"
In a few years "10x dev" will fall out of use, and we will have the next term du jour. My money is on "Astronaut Dev".
A couple years ago I was rejected from a 3rd round interview for a very large company that should have known better for the primary reason that my "coding challenge" exercise didn't meet an arbitrary lines of code minimum, despite meeting all of their requirements.
And of course we have the recent example of a certain chief Twit firing engineers based on LoC.
There's no way this is true right? Why would anyone care about LoC for a coding challenge?
Obviously, the one who uses the most wood wins! ;) If told right, they should easily figure out why LoC is a horrible metric.
Is there any evidence of this claim that isn't yellow press and random gossip on Twitter?
This concept often hurts people’s egos, who search for some counterbalance.
After removing most of their print statements, it was obvious what the program was doing at run-time.
It's much harder to delete your own code than someone else's, especially when you're unsure of what's important.
I'll add "learning how to use a debugger", though.
Manual formatting and printf debugging goes a long way, and takes only foundational understanding of the problem, not the manual for another tool.
(Don't get me wrong: I love those tools. For a person who already knows them, they're a productivity multiplier. But a complete beginner usually doesn't have that knowledge.)
Introducing debuggers too early leads to lots of "why do we need this? I can just print..."
It's a catch-22 though, because ideally you'd learn the debugger in an intro course, but intro course problems can usually be debugged with simple print statements.
Why I Strive to be a 0.1x Engineer - https://news.ycombinator.com/item?id=10978841 - Jan 2016 (272 comments)
10x developers tend to code really slowly, much more slowly than 1x and 0.1x developers (especially when working on the critical parts of the project). What makes them 10x is that once they've written some code, it solves the problem in a near optimal way, it aligns well with the direction of the project (it's easy to build upon), it doesn't require much or any maintenance and it doesn't need to be rewritten for a very long time (e.g. 5 years or more provided that there is no crazy startup pivot on the business side).
This also highlights an important point that not all companies need 10x developers. If the company wants to build a large but straight forward project (a lot of work but without any significant technical challenges), you may not need a 10x developer; you may be better off just hiring a bunch of juniors who can put together a disposable MVP quickly. 10x devs are good when you have a sufficiently complex project; which I would argue are most projects, but not all.
A 2x developer is like a sprinter. A 10x developer is more like a marathon runner.
Maybe there are a few out there, but mostly, they are myths constructed from stories that are constantly retold and changed until no one really knows exactly what makes a 10x developer, but are convinced they can intuit it when they see it :)
Source: read the comments here. I caught at least 4 different explanations of what a 10x developer really is or does.
"Every programmer will be given more difficult assignments until they are a 0.4X programmer."
> Let’s not add this functionality.
> Let’s not build that product yet.
> Let’s not build/deploy that development tool.
> Let’s not adopt this new technology.
> Let’s not keep maintaining this feature.
> Let’s not automate this.
Working alongside (or even worse: under) an individual who sees it as his job to just say "no" to everything sounds like hell.
It also reminds me a bit of the Dilbert character "Mordac, the preventer of information services" alternately also called "Mordac, the refuser.
There is no value in reinventing the wheel, and not doing so gives you time to do other things that will give you value so someone should always be asking the question of if something should be done.
The nuanced point of view is of course in the middle; don't pick up more work or responsibilities without knowing the full story, without having done due diligence, homework, looking at alternatives, etc.
Like: If a decision is made not to automate something, someone is going to have to do that boring repetitive work that could have been automated. The person making that decision not to automate is usually not the same person having to do that work. -- The former will usually be some kind of manager or owner, while the latter will usually be some kind of IC-level engineer or bookkeeper or something like that.
If a decision is made not to build that feature that a lot of customers requested, someone is going to have to explain to customers on a regular basis why they can't have their wish (usually some kind of sales person or customer service representative or something like that).
That's where the sadistic element of the Mordac character comes in.
There's a related problem that is discussed at length in the book "Peopleware" [1]: Often, from a strictly economical standpoint, you might be in a situation where you'd say "quality level x is the quality level that the market is willing to pay for, while any higher quality level is uneconomical". You might then be tempted to ask your employees to dial down the quality level of their work and produce worse work than they're capable of. -- The book argues that this is almost always a bad idea because of the demotivating effect. You'll get lower productivity and won't realize the cost-advantage you were hoping for in your purely economic analysis. Or to put it differently: Dialling up the quality-level in your product from the level you economically need/want to the level your employees are capable of will often pay for itself through increased productivity through increased motivation.
So, if you ask your employees to be 0.1x employees, you will truly get 0.1x employees. But the result won't be that you'll accomplish more with less, but rather that you'll do less and accomplish less due to lesser productivity.
You did read the little sentences under the big bullet points, right? It's "first, let's see if it's smarter to not do the work at all, before we commit to automating", not "don't automate the boring stuff"
This is because of a lifetime of managers telling me things like "before we do this thing that you want to do, please first conduct a fact-finding mission to consider the possibility that we don't actually need to do it". My mental bullshit filter turns that into just "no".
That's because the fact-finding thing only has two possible outcomes: I come back with evidence to support their no-position in which case: great job on that fact-finding. Or I come back with evidence to support my yes-position, in which case, guess what, there's something wrong with my fact-finding. Then they decide "no" based on their preconceived notion, plus they get to look very reasonable and evidence-driven. -- Conversely, a "yes" always looks very different. It's always "yes" from the start.
Apart from this, I'm of the opinion that one crucial job of a team lead/manager is protecting their team and, their product.
One way to do this is saying "no" to feature requests, being mindful of which hype to follow and balancing the value and the cost of doing so, etc.
IMHO its not actually that hard to figure out what to work on if you talk to enough people. There is often some "L6" (the person six levels down in operations) who already knows what needs to be worked on but nobody has ever asked them ( https://podcasts.apple.com/us/podcast/episode-1-six-levels-d... )
Given the cost of maintaining everything we build, it would
literally be better for us to do 10% the work and sit around
doing nothing for the rest of our time, if we could figure
out the right 10% to work on.It works like this in scientific research too, except the worthwhile stuff is only 1%, not the full 10%, so that's another order of magnitude worse X.
So basically if you develop for 100 days, only one of the daily milestones will actually be useful, and it may or may not happen much earlier than when all 100 days have passed. Also you may or may not realize which 1% it is right away either.
But once you've got it, that's the critical 1% that allows you to go forward the very next day.
And the next day is what really counts, otherwise zero progress toward the larger goals.
Even after a large goal has been reached, you might still get the feeling that you wasted a whole lot of days along the line there. Knowing that if you just had, and recognized, the key milestone the very first day of the project, you would be as much as 99 days ahead by comparison.
Now, doing the math, if you work one tenth as much it will take 1000 days to accomplish the same thing instead.
These orders of magnitude are killing me, you must avoid even conceptualizing the possibility that 999 days could be wasted now.
Which is OK, for some things I do that too.
Other things I like to be a lot more than 99 days ahead on.
Always have.
If you over specialize there isn't much moat. Which is fine for small shops. Though it does limit market size and growth potential.
Which isn't to say don't trim the fat. Just measure twice before cutting.
10x engineers are not 10x the average, they're 10x the median. And they probably know the difference.
I would guess that 1-5% of engineers are 10x the median, while less than 0.1% or so are 10x the average.
Their manager.