12 ms·

I strive to be a 0.1x Engineer (2016)

126 points by dgs_sgd 4y ago

paulryanrogers 4y ago
Having worked on my share of kitchen-sink SAAS I'd say it's hard to cut back on features when table stakes are always raising. Clients often want a buffet of different things. 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.
jmathai 4y ago
FTA: this is the TL;DR and there's a lot of truth in it. 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.
- chrismarlow9 4y ago
  But then what will I put on my resume and how will I answer all those behavior questions in STAR format so I can pile a bunch of new tech into my next job and then rinse and repeat?
  - deleted 4y ago
    [deleted]
- fuzzfactor 4y ago
  True dat. 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.
bvirb 4y ago
This is also usually the twist of the what makes a 10x engineer articles I've seen: "hey we don't actually need this, ticket closed" -- but all day.
dang 4y ago
Discussed at the time: Why I Strive to be a 0.1x Engineer - https://news.ycombinator.com/item?id=10978841 https://news.ycombinator.com/item?id=10978841 - Jan 2016 (272 comments)
labrador 4y ago
When he describes what he does he's describing a 10x engineer. 10x doesn't mean you write 10x more code, it means you deliver 10x more problem solutions
- devmor 4y ago
  Unfortunately even the most prolific and very successful CEOs and management in our industry often fail to understand this. 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.
  - shepherdjerred 4y ago
    > an arbitrary lines of code minimum, despite meeting all of their requirements. There's no way this is true right? Why would anyone care about LoC for a coding challenge?
    - bitL 4y ago
      Some "old school" management styles measure LoC and make hiring/firing decisions based on that. Really.
      - tartoran 4y ago
        Someone should enlighten them that less LOC is good in solving a problem, granted that the code is also more maintenable due to smaller surface area and no bad shortcuts were taken. Yes, it’s hard for management types to get that, perhaps because most of them want the problems entrenchability creates, and that for their own … benefits.
        grangerg 4y ago
        Perhaps tell them the story of the 10x carpenter. Obviously, the one who uses the most wood wins! ;) If told right, they should easily figure out why LoC is a horrible metric.
hoosieree 4y ago
I just pair programmed with a student to help them get their code working. The first thing I did was delete unused variables and non-critical code that was distracting from the core algorithm. 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.
- kqr 4y ago
  Deleting stuff, compiling often, and proper indentation -- things beginners don't think they should waste time on, but which actually would solve most of their problems.
  - ColonelPhantom 4y ago
    Especially as compiling often and proper indentation are often taken care of by running a linter and an autoformatter. I'll add "learning how to use a debugger", though.
    - kqr 4y ago
      In my interactions with beginners, adding more tools has never helped them learn faster. That goes for linters, autoformatters, debuggers, and version control. 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.)
      - hoosieree 4y ago
        It's good to have a teacher who can recognize the moment when print-debugging is no longer sufficient and a real debugger will solve the problem immediately. 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.
jongjong 4y ago
To "strive to be a 0.1x engineer" means that whenever you are presented with an option, you intentionally choose the worst option; the one which requires the most work, solves the problem in an inefficient way, doesn't align with the direction of the project and which will require constant maintenance and will need to be rewritten within a year or 2. 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.
- curmudgeon22 4y ago
  That's not the definition from the article. They talk about knowing when to say no to a project, the concept of identifying value and trying to do valuable things.
- bitexploder 4y ago
  I always enjoy the various ways people mythologize the 10x developer. Everyone has their own apocrypha about what makes a 10x developer and how they behave and it is all so different. 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.
  - 4y ago
satvikpendem 4y ago
Those here talking about what the author is saying is actually a 10x engineer are missing that he's criticizing the meme of a 10x engineer [0] over an actually 10x more productive engineer. 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. [0] https://knowyourmeme.com/memes/10x-engineer https://knowyourmeme.com/memes/10x-engineer
- soganess 4y ago
  Software folk taking the 10x thing seriously is akin to PC gamers unironically calling themselves the "PC master race". I have a hard time taking that conversation seriously.
  - PedroBatista 4y ago
    The tragic thing is: Most of this industry takes the concept of the 10x, 100x developer very seriously. 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.
    - mattkrause 4y ago
      A fun comparison is that Usain Bolt, who literally wins gold medals, is not even a 10x runner: a tenth of his world-record speed 100m works out to a brisk walk.
      - eloff 4y ago
        That's no leverage in running. There's a lot of leverage in software engineering. That's what allows such a wide diversity of productivity.
        xeromal 4y ago
throwawayoaky 4y ago
real talk though how do you make money at a shop that says no? we just gonna sit around with our hands in our robes and nod?
- throwawayoaky 4y ago
  to offer an alterative: write all the code you want and throw it away. Don't get attached to the work of your hands. The code is the water; feel the problem, move towards the value.
fatneckbeardz 4y ago
hee hee 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-down/id1455379351?i=1000555532510 https://podcasts.apple.com/us/podcast/episode-1-six-levels-d... )
faangiq 4y ago
Failing to the top is a very important skill to learn.
1letterunixname 4y ago
I feel like a 0.1x engineer most days.
deleted 4y ago
[deleted]
rvense 4y ago
What's the difference between a 0.1x engineer and a 10x engineer? Their manager.
- Jensson 4y ago
  What if both are solo developers?
  - rvense 4y ago
    Some developers are good managers, some are bad managers.
qikInNdOutReply 4y ago
My dream was always to be hired into obscure government bureaucracy and automate the data entry job away, while hiding it. After that, you basically exist in a free incubator. 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.
- enriquto 4y ago
  Have you ever heard about the entire concept of academia? It is more or less like that.
  - littlestymaar 4y ago
    Maybe used to be like that (or maybe it's just prejudice against researchers), but from what I'm hearing it's pretty far from the truth today. 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.
    - comfypotato 4y ago
      It sounds like you’ve been heavily influenced by the tone regarding academia here on HN. It’s one of the nuances of HN that people “hate academia” here. (Admittedly CS has a strange relationship with academia in that the pay discrepancy is so outrageous between industry.) 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.
coding123 4y ago
So here's a weird question. Are 0.1x developers getting paid the $400k, 500k salaries or is that just 10x'ers?
- Demonsult 4y ago
  I've been doing this for more than 25 years and the income gains for being productive are miniscule. Strategizing your job hops carefully is what gets you the 1/2 million.
  - badpun 4y ago
    There's probably an economic opportunity for a tech company which only hires true 10x-ers, and pays them $500k-$1m.
trashtester 4y ago
> “the top tier of engineers that are 10x more productive than the average” 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.
- froddd 4y ago
  Given the rather arbitrary nature of ‘10x’ I’m not sure this kind of precision is relevant here
  - BerislavLopac 4y ago
    Not to mention that we actually have no idea which unit comes to the other side of that equation, after "x".
  - Attrecomet 4y ago
    Might as well try to keep score in Calvinball
gyulai 4y ago
> Let’s not build that feature. > 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. [1] https://dilbert.com/search_results?terms=Mordac https://dilbert.com/search_results?terms=Mordac
- philderbeast 4y ago
  Saying no is just as important as saying yes. 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.
- Cthulhu_ 4y ago
  I mean it's a bit absolutist but that's to make a point; it's like the antithesis to Jim Carrey's Yes Man. A lot of developers are over-eager, simply looking for opportunities to work extra hours, pull an all-nighter, and show off to their peers. A lot of companies are over-eager to keep cramming features into their product, to keep pumping up those numbers, to build and release more and more services and products. 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.
  - gyulai 4y ago
    When I say "sounds like hell" I'm not necessarily looking at it from the point of view of what's economical, but rather from the point of view of job satisfaction. 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. [1] https://a.co/d/38NbxtG https://a.co/d/38NbxtG
citizenpaul 4y ago
Man that applying the 0.1x part really reminds me of being in mgmt. I felt like my job was more like chief disappointer and garbage tosser of ideas. People forget that its easy to sit and spit out 100 ideas at a session. The hard part is throwing away the stuff that is good but just doesn't need to happen for various reasons.

126 points by dgs_sgd 4y ago

Having worked on my share of kitchen-sink SAAS I'd say it's hard to cut back on features when table stakes are always raising. Clients often want a buffet of different things. 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.

jmathai 4y ago

FTA: this is the TL;DR and there's a lot of truth in it. 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.

chrismarlow9 4y ago
But then what will I put on my resume and how will I answer all those behavior questions in STAR format so I can pile a bunch of new tech into my next job and then rinse and repeat?
- deleted 4y ago
  [deleted]
fuzzfactor 4y ago
True dat. 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.

bvirb 4y ago

This is also usually the twist of the what makes a 10x engineer articles I've seen: "hey we don't actually need this, ticket closed" -- but all day.

dang 4y ago

Discussed at the time: Why I Strive to be a 0.1x Engineer - https://news.ycombinator.com/item?id=10978841 https://news.ycombinator.com/item?id=10978841 - Jan 2016 (272 comments)

labrador 4y ago

When he describes what he does he's describing a 10x engineer. 10x doesn't mean you write 10x more code, it means you deliver 10x more problem solutions

devmor 4y ago
Unfortunately even the most prolific and very successful CEOs and management in our industry often fail to understand this. 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.
- shepherdjerred 4y ago
  > an arbitrary lines of code minimum, despite meeting all of their requirements. There's no way this is true right? Why would anyone care about LoC for a coding challenge?
  - bitL 4y ago
    Some "old school" management styles measure LoC and make hiring/firing decisions based on that. Really.
    - tartoran 4y ago
      Someone should enlighten them that less LOC is good in solving a problem, granted that the code is also more maintenable due to smaller surface area and no bad shortcuts were taken. Yes, it’s hard for management types to get that, perhaps because most of them want the problems entrenchability creates, and that for their own … benefits.
      - grangerg 4y ago
        Perhaps tell them the story of the 10x carpenter. Obviously, the one who uses the most wood wins! ;) If told right, they should easily figure out why LoC is a horrible metric.

hoosieree 4y ago

I just pair programmed with a student to help them get their code working. The first thing I did was delete unused variables and non-critical code that was distracting from the core algorithm. 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.

kqr 4y ago
Deleting stuff, compiling often, and proper indentation -- things beginners don't think they should waste time on, but which actually would solve most of their problems.
- ColonelPhantom 4y ago
  Especially as compiling often and proper indentation are often taken care of by running a linter and an autoformatter. I'll add "learning how to use a debugger", though.
  - kqr 4y ago
    In my interactions with beginners, adding more tools has never helped them learn faster. That goes for linters, autoformatters, debuggers, and version control. 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.)
    - hoosieree 4y ago
      It's good to have a teacher who can recognize the moment when print-debugging is no longer sufficient and a real debugger will solve the problem immediately. 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.

jongjong 4y ago

To "strive to be a 0.1x engineer" means that whenever you are presented with an option, you intentionally choose the worst option; the one which requires the most work, solves the problem in an inefficient way, doesn't align with the direction of the project and which will require constant maintenance and will need to be rewritten within a year or 2. 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.

curmudgeon22 4y ago
That's not the definition from the article. They talk about knowing when to say no to a project, the concept of identifying value and trying to do valuable things.
bitexploder 4y ago
I always enjoy the various ways people mythologize the 10x developer. Everyone has their own apocrypha about what makes a 10x developer and how they behave and it is all so different. 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.
- 4y ago

satvikpendem 4y ago

Those here talking about what the author is saying is actually a 10x engineer are missing that he's criticizing the meme of a 10x engineer [0] over an actually 10x more productive engineer. 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. [0] https://knowyourmeme.com/memes/10x-engineer https://knowyourmeme.com/memes/10x-engineer

soganess 4y ago
Software folk taking the 10x thing seriously is akin to PC gamers unironically calling themselves the "PC master race". I have a hard time taking that conversation seriously.
- PedroBatista 4y ago
  The tragic thing is: Most of this industry takes the concept of the 10x, 100x developer very seriously. 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.
  - mattkrause 4y ago
    A fun comparison is that Usain Bolt, who literally wins gold medals, is not even a 10x runner: a tenth of his world-record speed 100m works out to a brisk walk.
    - eloff 4y ago
      That's no leverage in running. There's a lot of leverage in software engineering. That's what allows such a wide diversity of productivity.
      - xeromal 4y ago

throwawayoaky 4y ago

real talk though how do you make money at a shop that says no? we just gonna sit around with our hands in our robes and nod?

throwawayoaky 4y ago
to offer an alterative: write all the code you want and throw it away. Don't get attached to the work of your hands. The code is the water; feel the problem, move towards the value.

fatneckbeardz 4y ago

hee hee 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-down/id1455379351?i=1000555532510 https://podcasts.apple.com/us/podcast/episode-1-six-levels-d... )

faangiq 4y ago

Failing to the top is a very important skill to learn.

1letterunixname 4y ago

I feel like a 0.1x engineer most days.

deleted 4y ago

[deleted]

rvense 4y ago

What's the difference between a 0.1x engineer and a 10x engineer? Their manager.

Jensson 4y ago
What if both are solo developers?
- rvense 4y ago
  Some developers are good managers, some are bad managers.

qikInNdOutReply 4y ago

My dream was always to be hired into obscure government bureaucracy and automate the data entry job away, while hiding it. After that, you basically exist in a free incubator. 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.

enriquto 4y ago
Have you ever heard about the entire concept of academia? It is more or less like that.
- littlestymaar 4y ago
  Maybe used to be like that (or maybe it's just prejudice against researchers), but from what I'm hearing it's pretty far from the truth today. 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.
  - comfypotato 4y ago
    It sounds like you’ve been heavily influenced by the tone regarding academia here on HN. It’s one of the nuances of HN that people “hate academia” here. (Admittedly CS has a strange relationship with academia in that the pay discrepancy is so outrageous between industry.) 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.

coding123 4y ago

So here's a weird question. Are 0.1x developers getting paid the $400k, 500k salaries or is that just 10x'ers?

Demonsult 4y ago
I've been doing this for more than 25 years and the income gains for being productive are miniscule. Strategizing your job hops carefully is what gets you the 1/2 million.
- badpun 4y ago
  There's probably an economic opportunity for a tech company which only hires true 10x-ers, and pays them $500k-$1m.

trashtester 4y ago

> “the top tier of engineers that are 10x more productive than the average” 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.

froddd 4y ago
Given the rather arbitrary nature of ‘10x’ I’m not sure this kind of precision is relevant here
- BerislavLopac 4y ago
  Not to mention that we actually have no idea which unit comes to the other side of that equation, after "x".
- Attrecomet 4y ago
  Might as well try to keep score in Calvinball

gyulai 4y ago

> Let’s not build that feature. > 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. [1] https://dilbert.com/search_results?terms=Mordac https://dilbert.com/search_results?terms=Mordac

philderbeast 4y ago
Saying no is just as important as saying yes. 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.
Cthulhu_ 4y ago
I mean it's a bit absolutist but that's to make a point; it's like the antithesis to Jim Carrey's Yes Man. A lot of developers are over-eager, simply looking for opportunities to work extra hours, pull an all-nighter, and show off to their peers. A lot of companies are over-eager to keep cramming features into their product, to keep pumping up those numbers, to build and release more and more services and products. 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.
- gyulai 4y ago
  When I say "sounds like hell" I'm not necessarily looking at it from the point of view of what's economical, but rather from the point of view of job satisfaction. 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. [1] https://a.co/d/38NbxtG https://a.co/d/38NbxtG

citizenpaul 4y ago

Man that applying the 0.1x part really reminds me of being in mgmt. I felt like my job was more like chief disappointer and garbage tosser of ideas. People forget that its easy to sit and spit out 100 ideas at a session. The hard part is throwing away the stuff that is good but just doesn't need to happen for various reasons.