10 ms·

I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X en

by ble 4y ago

I usually think of an at-work "politician" as somehow taking advantage of relationships or social forces. What you describe sounds more to me like the ""10X engineer"" (with extra scare quotes for good measure). Many people have been skeptical of the idea of the 10X engineer. One take is that if your normal engineers are less than 1/10th as productive as another engineer and all of them are merely human beings, there might be some common organizational problems that your normal engineers are all being stymied by. Another take is that your 10X engineers can only achieve their high level of productivity through taking on more technical debt than others understand or would tolerate, leaving messes behind for the eventual maintainers to fix.

deleted 4y ago
[deleted]
eurasiantiger 4y ago
Or maybe they just type faster.
bioemerl 4y ago
In the workforce - the real answer is that the 1x engineers really really aren't operating at full capacity. You assume all parties give it their all. They rarely do. Get through college Do what you have to in other to get the job. Do what you have to in order to keep the job. 10x people do some very basic things. They care. They read about code. They have side projects. They improve their skills because doing so is fun. In a company that hires "the best" and pays very well you shouldn't see a 1x 10x divide, assuming they hire well. In those that don't, those that only want work done and don't particularly care? That's where the dichotomy presents itself. There is nothing inherently wrong with either group. Work gets paid, you don't have to be a magical 10x engineer to be worth the salary. And there's no shame in coding as a job instead of as a hobby.
- CobrastanJorji 4y ago
  "Hiring well" or hiring "the best" isn't a panacea. People change. Before I had kids, I was working hard, working late nights, and some of my work was all-consuming. After, I've definitely had periods where my main focus was on showing up to meetings and making sure I got at least pretty okay on my performance reviews, while actually focusing on, y'know, not work. If the company doesn't punish people for becoming half as productive, a lot of the folks are going to become half as productive, even if they were "the best" at some point. Especially true when morale at a company drops. Canceling projects, being assigned to boring projects (the next year will focus on Sarbanes Oxley compliance, guys!), having your company or work dragged through the news, it adds up, and people get detached.
  - Karrot_Kream 4y ago
    I don't think there's anything wrong being this 1x engineer. In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance.
    - throwaway09223 4y ago
      > In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance. Sometimes, sure. But often (especially later in a career) overperforming people operate a bit more like senior partners. They have jr staff / understudies to handle crank turning. They can give direction and set things on a solid path without necessarily putting in a ton of hours. In a healthy org, this is the "architect" role. Or sometimes the "solver," or some combination thereof. I'm sure you're familiar with the adage about the guy who charges $10k to mark the problem, $1 for the time and $9,999 for knowing where to make the mark.
    - raffraffraff 4y ago
      If these 10x engineers really exist, they're rare. Building an engineering department with this type of employee isn't sustainable. In 20+ years I've only worked with maybe 2 genuine examples of the good 10x engineer, and far more examples of the bad "10x engineer" who flies around quickly reimplementing patterns that they implemented at other companies, whether they're suitable or not. Once the low-hanging fruit is all gone and only the hard stuff (and hubris) remains, they leave. Usually, after getting pissy because other engineers have inherited their crap have started pushing back and questioning their design choices. I've inherited systems built by people like this and it's not pleasant. You also better be willing to hire constantly if you want a few more 10xers in your back pocket. If hiring a regular "good engineer" is hard, then hiring one of these is harder. You need to find them, convince them to interview, present them with an interesting challenge, have a great interview process that separates wheat from the chaff. And finally, pay them a ton and don't let them burn themselves out Oh, and admit that replacing a 10x engineer is going to be basically impossible, not just because it's hard to hire them, but because each one that leaves your takes far more experience and knowledge with them when they go (than the 1x engineer). If the 10x moniker was really accurate, it would be like losing a team of 10. Sometimes it's better to have a reliable team of 6 engineers in at least 2 timezones who get along well, sync up once a week and have a really good lead/manager. This is sustainable, easier to hire, onboard, retain. And less detrimental if you lose one.
- 29athrowaway 4y ago
  More often than not, it's people that care about how to create abstractions that amplify their productivity. That is only possible if they can spend some time building abstract stuff that cannot be explained to non-technical stakeholders, which is not possible with sweatshop engineering methodologies like Scrum, or when you promote the smiling bozos that completed their 5 person-minutes Agile crash course to management.
  - Olreich 4y ago
    Abstraction is not a panacea. It's often the root cause of significant technical debt. Abstracting as late as possible is often the best course of action, as it give you more information about how to abstract from the initial implementation.
    - janstice 4y ago
      Improper abstraction does usually lead to significant technical debt, but if you are lucky you can bank your short-term successes and leave the tech debt to someone else.
    - 29athrowaway 4y ago
      Yes, that's why it takes effort to learn how to properly create abstractions that solve more problems than they cause.
      - pksebben 4y ago
        I would add to this; that a certain amount of bad abstractions are preferable to underdoing it. The learning from failure (when there's sufficient investment in the outcome) is far more valuable than avoiding inefficiency. Learning better ways is a process - so long as you remain robust in the face of failure and grow from it.
    - kodah 4y ago
      Most people think it's the people that are special or underperforming, but my view is probably a bit more contrarian. I think that some environments work in such a way that only a few can succeed while others make success possible in a network effect or on more manageable scale. I don't think that environments that produce the former really mean to; rather I think it's the leaders that are unable to craft incentive systems, pool resources, or effectively communicate that end up creating these kinds of ecosystems. It's really a fundamental misunderstanding of the people part of the job, which turns out to usually be the hardest.
jedberg 4y ago
I've seen 10x engineers. They do exist. However I've never seen them in isolation. It's more like teams of 10x engineers. I've seen teams of people who just get 10x more work done than equivalent teams elsewhere, usually because they consist of a bunch of amazing engineers and are enabled by management to get things done.
- adra 4y ago
  I'd generally agree to this. The most recent job I've worked at have amazing management buy-in and empowerment by management to just "get things done fast" that ends up working amazingly well because the freedom we've been given translates to great results. This is a little catch-22 in getting started though. A great team held back by management hesitation can demotivate and cause attrition. Management buy-in for ineffective teams will run faster by bypassing many org hurdles fall over by their own inability to execute solutions that pass the test of time. It seems like these rare "10x" teams are hard to form in companies that can't consistently attract and retain very talented ICs
- urthor 4y ago
  Motivated + enabled. 110%. I will say. In terms of man hours, often those teams take a multiple of effort from people around the company to support. They just, consume a lot of time and attention. From various business analysts, vice presidents reviewing their output, etc etc.
- Olreich 4y ago
  I think that's because a good amount of 1x engineers could be 10x engineers if given the right kinds of support. When leadership makes sure they have that support, they become 10x engineers. If you only ever see clusters of 10x engineers, it's more likely to be about the factors around them than the engineers themselves.
  - jedberg 4y ago
    I think it's both. You get a 10x engineer and a good environment and they bring in other 10x engineers who want to work with them.
tzone 4y ago
If you have never seen a 10x engineer you either have never worked with truly talented people or you haven’t worked on actual hard problems. There aren’t just 10 or 100x engineers , there are even infinityX engineers when you work on actual hard problems because some of those can only be solved by handful of people.
- Aeolun 4y ago
  > some of those can only be solved by handful of people Ultimately it can probably be solved by other people, but it’d take multiple years. I think the 10x is not so much because those engineers are particularly fast, it’s just that anyone else working in the domain is 10x slower. Like if I tried to build a compiler, I’d quickly become known as a 0.1x engineer.
- zmj 4y ago
  This reminds me of an old essay: https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/ https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n... The thesis is that the "10x engineers" don't output a linear multiple of the same kind of work their peers do. Instead, they implement solutions that their peers wouldn't or couldn't over any length of time. This matches my experience.
  - 29athrowaway 4y ago
    The 10x engineer identifies common subproblems across different problems, and then creates a layer of reusable code which becomes a library. Then uses this library to write code 10x faster. The 10x engineer tries to standardize problems and solve them en-masse. The 1x engineer sees every problem as a different problem that requires a different solution. The 10x engineer talks about abstractions, the 1x engineer talks about concrete implementations. The 10x engineer believes in investing in productivity. The 1x engineer wants a visible solution right now. The 1x engineer never has time because they're too busy making themselves less productive by owning more and more code to maintain. The 10x engineer is always looking for code to remove and refactor, and making the solution as small as possible. The 10x engineer will talk about programming language features and libraries that promote reusability, the 1x engineer only talks about tangible stuff. The 1x engineer talks about their car and weekend, the 10x engineer talks about technology.
onlyrealcuzzo 4y ago
> What you describe sounds more to me like the ""10X engineer"" I think 10X engineer is supposed to imply the average engineer - maybe at the person's level? We all know there are plenty of engineers who do negative work, and plenty who do almost nothing. So depending on how you think of it - it might not be that impressive.
maxrev17 4y ago
The 10x is a transition from knowing how to solve problems quickly and efficiently, to being burned out because too much of the solving problems quickly and efficiently. Like a bright burning filament bulb lol. OK I'm probably exaggerating but I have encountered this.
darepublic 4y ago
No it's more like at some organizations the culture is very apathetic and the mean dev there has very low throughput. So you can be "10x" merely by caring to the level a professional should. And ironically in those situations it's the low throughput devs creating all the tech debt, with their copy pasta and infinite one off solutions.
torial 4y ago
The scare quote 10x engineer I'd consider a faux 10x engineer. I have seen them -- and working through their code is not pleasant. But I've also seen people who just operate as such a high level that their code is top notch from the get go, they think clearly about the problem and then have a clear solution. Those are the real 10x (or whatever multiplier you want to use).
hintymad 4y ago
> Many people have been skeptical of the idea of the 10X engineer. O Nah, of course 10x engineers exist. A 10X engineer saw that hundreds of engineers were writing MPI code to process data and struggled with error handling and therefore came up with a map-reduce framework and its underlying infra. The same infra also helped bootstrap a whole industry. In this case, we are talking about 10^6X engineer. Another 10X engineer got fed up with MapReduce's abstraction and decided to borrow more concepts from functional programming and also invented a little data structure called RDD. This is a 10^5X engineer. A 10X engineer saw that his org build ad-hoc solutions to provision hardware and therefore decided to build an abstraction layer called EC2. Oops! That's another 10^6X engineer. A 10X engineer was not happy that writing GPGPU code was slow and error prone so he decided to worked out a library called CUDA. That's another 10^4X engineer, no? A 10X engineer was fed up with people implementing all kinds of broken consensus protocol and coded out a little practical implementation of Paxos called Chubby. All of a sudden the world of engineers woke up to the idea that consensus can be centrally managed and can be robust. That's a 10^4X engineer, right? A 10X engineer hates that his org write ad-hoc and crappy code on Zookeeper, so he packaged his wisdom into a little library called Curator with two clean concepts: framework and Recipes, and thousands of engineers' life just got immensely better. That's at least a 10^3X engineer, right? A 10X engineer was not sure why it takes an artist years to write quality compilers, be it frontend or backend, so he decided to come up with this little framework called llvm. That's a 10^5X engineer, right? Oh man, I think I can write a book about the examples...
- boppo1 4y ago
  Were each of these really achievements by a single engineer, or a team? One guy wrote CUDA?
  - hintymad 4y ago
    Ian Buck wrote the initial version, right? I'm sure multiple teams polished the aforementioned software. It's just that it was this one or two engineers came up with the idea, built the the first working version that the other fellow engineers thought impossible or too expensive or unworthy to build, and the rest was the history.
ergocoder 4y ago
> Many people have been skeptical of the idea of the 10X engineer. Why is 10x anything such a skeptical concept? We see it everywhere. We see it in quality, impact, and effort. Linus wrote git in days, and it was way better SVN. Messi is probably 100x better in terms of stats and skills and 100000x better in terms of earning when comparing to an average soccer player Apple's iPod is 10x better than Zune and makes 100000x more money. A great entrepreneur is probably 10000x better (more impact more money) than a good one. It is not strange that one engineer would be 10x of the other engineer in certain aspects.
- justinjlynn 4y ago
  > Linus wrote git in days, and it was way better SVN. Linus designed and coded some data structures, and some basic utilities to manipulate and store them, in just a few days - based on a fundamentally better model and as a replacement for an existing product they could no longer use. Designing and developing git into a usable product and system took a whole lot longer and involved thousands of people. The examples you cite are all similarly flawed gross simplifications or mischaracterisations. I urge you to reconsider your reasoning.
  - ergocoder 4y ago
    Instead of being pedantic, it would be better to describe how the examples are flawed, so we could have had a discussion. But you think "nah let's be pedantic". I urge you to reconsider not being pedantic next time And what Linus initially wrote was definitely a usable product. The product has evolved more since then, but that doesn't mean the initial version doesn't work. Actually most of the original code still exists. Back to the original point, this is the example of a >10x engineer (by impact, coding speed, innovation) who conceived, wrote a popular software in days, grew the community, and grew it to the insane popularity today. Only a handful of engineers in the world could ever achieve this kind of things.
    - justinjlynn 4y ago
      I'm going to ignore the personal attack and get right to the point. If you redefine '10X' to involve impact, speed, or innovation, then you're going to invite external factors of chance (popularity, adoption, etc) and the work of others in building the tools the individual engineer uses - albeit perhaps more effectively than others. Further, they did not 'write' a 'popular software' in days - it was an early prototype that took years to gain the momentum it has now, as I was saying. Trying to credit Linus for all of git is very much like trying to say that the author of a book on which a critically acclaimed movie is based is an amazing filmmaker. You simply can't credit single people for the work done by more than one person. Nuclear though they may have been to the work being there, their impact is far less than you would suggest. There are >10X teams and times and there are engineers who fit particular >10X teams and who are more likely to fit others, but there are no lone >10X engineers.
closeparen 4y ago
A 10x engineer writes code, and a lot of it. We can debate the quality, but the 10x part is about concrete output. Political Staff+ engineers live in meetings, documents, presentations, standards, etc. with little if any of their own output.
atoav 4y ago
I know that the idea of the 10x engineer is somewhat eyebrow raising, yet in most fields I ever have been in there where those people who would get shit done n times as fast/efficient or throughly as others, all while yielding better results — be it Camera or Light people on the film set, programmers, designers and architects, writers. The differenciator rarely was the pure skill at the profession, but an ability to mentally plan ahead and maybe even see the final "thing" in their head. So instead of going try and error or just using what worked last time those people tended to be able to see the clear outlines of the whole thing in their head before they do it, which has the benefit of not having to do things you know will not satisfy. Couple that with a willingness to not waste your time and then you get someone who looks magically efficient to people who "just do their job". In my eyes those people are not inhumanly good, it is just that most other people are quite average both in their skill and in their motivations. And even if you are average and just do your job you can easily compare against those people by investing persistence and time.
mirekrusin 4y ago
It's easy to get 10x engineer - just hire 9x shitty ones and you're done.

by ble 4y ago

deleted 4y ago

[deleted]

eurasiantiger 4y ago

Or maybe they just type faster.

bioemerl 4y ago

In the workforce - the real answer is that the 1x engineers really really aren't operating at full capacity. You assume all parties give it their all. They rarely do. Get through college Do what you have to in other to get the job. Do what you have to in order to keep the job. 10x people do some very basic things. They care. They read about code. They have side projects. They improve their skills because doing so is fun. In a company that hires "the best" and pays very well you shouldn't see a 1x 10x divide, assuming they hire well. In those that don't, those that only want work done and don't particularly care? That's where the dichotomy presents itself. There is nothing inherently wrong with either group. Work gets paid, you don't have to be a magical 10x engineer to be worth the salary. And there's no shame in coding as a job instead of as a hobby.

CobrastanJorji 4y ago
"Hiring well" or hiring "the best" isn't a panacea. People change. Before I had kids, I was working hard, working late nights, and some of my work was all-consuming. After, I've definitely had periods where my main focus was on showing up to meetings and making sure I got at least pretty okay on my performance reviews, while actually focusing on, y'know, not work. If the company doesn't punish people for becoming half as productive, a lot of the folks are going to become half as productive, even if they were "the best" at some point. Especially true when morale at a company drops. Canceling projects, being assigned to boring projects (the next year will focus on Sarbanes Oxley compliance, guys!), having your company or work dragged through the news, it adds up, and people get detached.
- Karrot_Kream 4y ago
  I don't think there's anything wrong being this 1x engineer. In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance.
  - throwaway09223 4y ago
    > In fact, the 10x engineer is probably only being paid a touch more for doing a lot more work and having a lot worse work-life balance. Sometimes, sure. But often (especially later in a career) overperforming people operate a bit more like senior partners. They have jr staff / understudies to handle crank turning. They can give direction and set things on a solid path without necessarily putting in a ton of hours. In a healthy org, this is the "architect" role. Or sometimes the "solver," or some combination thereof. I'm sure you're familiar with the adage about the guy who charges $10k to mark the problem, $1 for the time and $9,999 for knowing where to make the mark.
  - raffraffraff 4y ago
    If these 10x engineers really exist, they're rare. Building an engineering department with this type of employee isn't sustainable. In 20+ years I've only worked with maybe 2 genuine examples of the good 10x engineer, and far more examples of the bad "10x engineer" who flies around quickly reimplementing patterns that they implemented at other companies, whether they're suitable or not. Once the low-hanging fruit is all gone and only the hard stuff (and hubris) remains, they leave. Usually, after getting pissy because other engineers have inherited their crap have started pushing back and questioning their design choices. I've inherited systems built by people like this and it's not pleasant. You also better be willing to hire constantly if you want a few more 10xers in your back pocket. If hiring a regular "good engineer" is hard, then hiring one of these is harder. You need to find them, convince them to interview, present them with an interesting challenge, have a great interview process that separates wheat from the chaff. And finally, pay them a ton and don't let them burn themselves out Oh, and admit that replacing a 10x engineer is going to be basically impossible, not just because it's hard to hire them, but because each one that leaves your takes far more experience and knowledge with them when they go (than the 1x engineer). If the 10x moniker was really accurate, it would be like losing a team of 10. Sometimes it's better to have a reliable team of 6 engineers in at least 2 timezones who get along well, sync up once a week and have a really good lead/manager. This is sustainable, easier to hire, onboard, retain. And less detrimental if you lose one.
29athrowaway 4y ago
More often than not, it's people that care about how to create abstractions that amplify their productivity. That is only possible if they can spend some time building abstract stuff that cannot be explained to non-technical stakeholders, which is not possible with sweatshop engineering methodologies like Scrum, or when you promote the smiling bozos that completed their 5 person-minutes Agile crash course to management.
- Olreich 4y ago
  Abstraction is not a panacea. It's often the root cause of significant technical debt. Abstracting as late as possible is often the best course of action, as it give you more information about how to abstract from the initial implementation.
  - janstice 4y ago
    Improper abstraction does usually lead to significant technical debt, but if you are lucky you can bank your short-term successes and leave the tech debt to someone else.
  - 29athrowaway 4y ago
    Yes, that's why it takes effort to learn how to properly create abstractions that solve more problems than they cause.
    - pksebben 4y ago
      I would add to this; that a certain amount of bad abstractions are preferable to underdoing it. The learning from failure (when there's sufficient investment in the outcome) is far more valuable than avoiding inefficiency. Learning better ways is a process - so long as you remain robust in the face of failure and grow from it.
  - kodah 4y ago
    Most people think it's the people that are special or underperforming, but my view is probably a bit more contrarian. I think that some environments work in such a way that only a few can succeed while others make success possible in a network effect or on more manageable scale. I don't think that environments that produce the former really mean to; rather I think it's the leaders that are unable to craft incentive systems, pool resources, or effectively communicate that end up creating these kinds of ecosystems. It's really a fundamental misunderstanding of the people part of the job, which turns out to usually be the hardest.

jedberg 4y ago

I've seen 10x engineers. They do exist. However I've never seen them in isolation. It's more like teams of 10x engineers. I've seen teams of people who just get 10x more work done than equivalent teams elsewhere, usually because they consist of a bunch of amazing engineers and are enabled by management to get things done.

adra 4y ago
I'd generally agree to this. The most recent job I've worked at have amazing management buy-in and empowerment by management to just "get things done fast" that ends up working amazingly well because the freedom we've been given translates to great results. This is a little catch-22 in getting started though. A great team held back by management hesitation can demotivate and cause attrition. Management buy-in for ineffective teams will run faster by bypassing many org hurdles fall over by their own inability to execute solutions that pass the test of time. It seems like these rare "10x" teams are hard to form in companies that can't consistently attract and retain very talented ICs
urthor 4y ago
Motivated + enabled. 110%. I will say. In terms of man hours, often those teams take a multiple of effort from people around the company to support. They just, consume a lot of time and attention. From various business analysts, vice presidents reviewing their output, etc etc.
Olreich 4y ago
I think that's because a good amount of 1x engineers could be 10x engineers if given the right kinds of support. When leadership makes sure they have that support, they become 10x engineers. If you only ever see clusters of 10x engineers, it's more likely to be about the factors around them than the engineers themselves.
- jedberg 4y ago
  I think it's both. You get a 10x engineer and a good environment and they bring in other 10x engineers who want to work with them.

tzone 4y ago

If you have never seen a 10x engineer you either have never worked with truly talented people or you haven’t worked on actual hard problems. There aren’t just 10 or 100x engineers , there are even infinityX engineers when you work on actual hard problems because some of those can only be solved by handful of people.

Aeolun 4y ago
> some of those can only be solved by handful of people Ultimately it can probably be solved by other people, but it’d take multiple years. I think the 10x is not so much because those engineers are particularly fast, it’s just that anyone else working in the domain is 10x slower. Like if I tried to build a compiler, I’d quickly become known as a 0.1x engineer.
zmj 4y ago
This reminds me of an old essay: https://www.joelonsoftware.com/2005/07/25/hitting-the-high-notes/ https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n... The thesis is that the "10x engineers" don't output a linear multiple of the same kind of work their peers do. Instead, they implement solutions that their peers wouldn't or couldn't over any length of time. This matches my experience.
- 29athrowaway 4y ago
  The 10x engineer identifies common subproblems across different problems, and then creates a layer of reusable code which becomes a library. Then uses this library to write code 10x faster. The 10x engineer tries to standardize problems and solve them en-masse. The 1x engineer sees every problem as a different problem that requires a different solution. The 10x engineer talks about abstractions, the 1x engineer talks about concrete implementations. The 10x engineer believes in investing in productivity. The 1x engineer wants a visible solution right now. The 1x engineer never has time because they're too busy making themselves less productive by owning more and more code to maintain. The 10x engineer is always looking for code to remove and refactor, and making the solution as small as possible. The 10x engineer will talk about programming language features and libraries that promote reusability, the 1x engineer only talks about tangible stuff. The 1x engineer talks about their car and weekend, the 10x engineer talks about technology.

onlyrealcuzzo 4y ago

> What you describe sounds more to me like the ""10X engineer"" I think 10X engineer is supposed to imply the average engineer - maybe at the person's level? We all know there are plenty of engineers who do negative work, and plenty who do almost nothing. So depending on how you think of it - it might not be that impressive.

maxrev17 4y ago

The 10x is a transition from knowing how to solve problems quickly and efficiently, to being burned out because too much of the solving problems quickly and efficiently. Like a bright burning filament bulb lol. OK I'm probably exaggerating but I have encountered this.

darepublic 4y ago

No it's more like at some organizations the culture is very apathetic and the mean dev there has very low throughput. So you can be "10x" merely by caring to the level a professional should. And ironically in those situations it's the low throughput devs creating all the tech debt, with their copy pasta and infinite one off solutions.

torial 4y ago

The scare quote 10x engineer I'd consider a faux 10x engineer. I have seen them -- and working through their code is not pleasant. But I've also seen people who just operate as such a high level that their code is top notch from the get go, they think clearly about the problem and then have a clear solution. Those are the real 10x (or whatever multiplier you want to use).

hintymad 4y ago

> Many people have been skeptical of the idea of the 10X engineer. O Nah, of course 10x engineers exist. A 10X engineer saw that hundreds of engineers were writing MPI code to process data and struggled with error handling and therefore came up with a map-reduce framework and its underlying infra. The same infra also helped bootstrap a whole industry. In this case, we are talking about 10^6X engineer. Another 10X engineer got fed up with MapReduce's abstraction and decided to borrow more concepts from functional programming and also invented a little data structure called RDD. This is a 10^5X engineer. A 10X engineer saw that his org build ad-hoc solutions to provision hardware and therefore decided to build an abstraction layer called EC2. Oops! That's another 10^6X engineer. A 10X engineer was not happy that writing GPGPU code was slow and error prone so he decided to worked out a library called CUDA. That's another 10^4X engineer, no? A 10X engineer was fed up with people implementing all kinds of broken consensus protocol and coded out a little practical implementation of Paxos called Chubby. All of a sudden the world of engineers woke up to the idea that consensus can be centrally managed and can be robust. That's a 10^4X engineer, right? A 10X engineer hates that his org write ad-hoc and crappy code on Zookeeper, so he packaged his wisdom into a little library called Curator with two clean concepts: framework and Recipes, and thousands of engineers' life just got immensely better. That's at least a 10^3X engineer, right? A 10X engineer was not sure why it takes an artist years to write quality compilers, be it frontend or backend, so he decided to come up with this little framework called llvm. That's a 10^5X engineer, right? Oh man, I think I can write a book about the examples...

boppo1 4y ago
Were each of these really achievements by a single engineer, or a team? One guy wrote CUDA?
- hintymad 4y ago
  Ian Buck wrote the initial version, right? I'm sure multiple teams polished the aforementioned software. It's just that it was this one or two engineers came up with the idea, built the the first working version that the other fellow engineers thought impossible or too expensive or unworthy to build, and the rest was the history.

ergocoder 4y ago

> Many people have been skeptical of the idea of the 10X engineer. Why is 10x anything such a skeptical concept? We see it everywhere. We see it in quality, impact, and effort. Linus wrote git in days, and it was way better SVN. Messi is probably 100x better in terms of stats and skills and 100000x better in terms of earning when comparing to an average soccer player Apple's iPod is 10x better than Zune and makes 100000x more money. A great entrepreneur is probably 10000x better (more impact more money) than a good one. It is not strange that one engineer would be 10x of the other engineer in certain aspects.

justinjlynn 4y ago
> Linus wrote git in days, and it was way better SVN. Linus designed and coded some data structures, and some basic utilities to manipulate and store them, in just a few days - based on a fundamentally better model and as a replacement for an existing product they could no longer use. Designing and developing git into a usable product and system took a whole lot longer and involved thousands of people. The examples you cite are all similarly flawed gross simplifications or mischaracterisations. I urge you to reconsider your reasoning.
- ergocoder 4y ago
  Instead of being pedantic, it would be better to describe how the examples are flawed, so we could have had a discussion. But you think "nah let's be pedantic". I urge you to reconsider not being pedantic next time And what Linus initially wrote was definitely a usable product. The product has evolved more since then, but that doesn't mean the initial version doesn't work. Actually most of the original code still exists. Back to the original point, this is the example of a >10x engineer (by impact, coding speed, innovation) who conceived, wrote a popular software in days, grew the community, and grew it to the insane popularity today. Only a handful of engineers in the world could ever achieve this kind of things.
  - justinjlynn 4y ago
    I'm going to ignore the personal attack and get right to the point. If you redefine '10X' to involve impact, speed, or innovation, then you're going to invite external factors of chance (popularity, adoption, etc) and the work of others in building the tools the individual engineer uses - albeit perhaps more effectively than others. Further, they did not 'write' a 'popular software' in days - it was an early prototype that took years to gain the momentum it has now, as I was saying. Trying to credit Linus for all of git is very much like trying to say that the author of a book on which a critically acclaimed movie is based is an amazing filmmaker. You simply can't credit single people for the work done by more than one person. Nuclear though they may have been to the work being there, their impact is far less than you would suggest. There are >10X teams and times and there are engineers who fit particular >10X teams and who are more likely to fit others, but there are no lone >10X engineers.

closeparen 4y ago

A 10x engineer writes code, and a lot of it. We can debate the quality, but the 10x part is about concrete output. Political Staff+ engineers live in meetings, documents, presentations, standards, etc. with little if any of their own output.

atoav 4y ago

I know that the idea of the 10x engineer is somewhat eyebrow raising, yet in most fields I ever have been in there where those people who would get shit done n times as fast/efficient or throughly as others, all while yielding better results — be it Camera or Light people on the film set, programmers, designers and architects, writers. The differenciator rarely was the pure skill at the profession, but an ability to mentally plan ahead and maybe even see the final "thing" in their head. So instead of going try and error or just using what worked last time those people tended to be able to see the clear outlines of the whole thing in their head before they do it, which has the benefit of not having to do things you know will not satisfy. Couple that with a willingness to not waste your time and then you get someone who looks magically efficient to people who "just do their job". In my eyes those people are not inhumanly good, it is just that most other people are quite average both in their skill and in their motivations. And even if you are average and just do your job you can easily compare against those people by investing persistence and time.

mirekrusin 4y ago

It's easy to get 10x engineer - just hire 9x shitty ones and you're done.