4 ms·

Of course they do. Have you literally never run into a problem that the average developer can not solve, but a expert can solve? That is infinity times more pro

by Veserv 4mo ago

Of course they do. Have you literally never run into a problem that the average developer can not solve, but a expert can solve? That is infinity times more productive. Even assuming that maybe the average developer could come to learn how to solve the problem you can easily see the gap between taking months to learn how to solve a problem versus already knowing how to solve it on short notice being over 10x. Large productivity differences are mostly a function of differences in capability than differences of speed in solving rote problems easily within their capabilitys.

godelski 4mo ago
> Have you literally never run into a problem that the average developer can not solve, but a expert can solve? In what time frame? > Even assuming that maybe the average developer could come to learn ... already knowing how to solve it on short notice being over 10x. 10x? I'm not convinced. 10x is a pretty big increase, as illustrated above. Clearly I understand the gap, I explicitly mentioned it. I mentioned a month's work is quite valuable. I'm not the one diminishing that value, you are. I can totally buy instances of 10x improvement, but that's not what we're talking about and not how anyone is using the term. Everyone is talking about sustained output. No one gives a shit if you're 100x for five minutes but 0.5x the rest of the time. Your critique isn't wrong, per say, but it is a non sequitur to the conversation. I doubt even a staff level engineer is even a 10x above the junior. Will the staff level engineer write better code and faster? Hell yeah they will! But will it take a junior 10 years to write the same software a staff level does in a year? Maybe. But if it does I'm not convinced they're even trying, so not a fair comparison. 10 years is a lot of time. A lot of time to learn, refactor, or even build the damn thing from scratch a few dozen times. Seriously, 10x improvements are actually wild. But why dismiss a 10% gain as if it's nothing? Why is the smaller number bad? Is the need for the number to go up so strong that we don't care how divorced from reality it is?
- Jensson 4mo ago
  > I doubt even a staff level engineer is even a 10x above the junior Its not about staff vs junior, its about smart vs dumb programmers. You don't get smarter with time, you just gain more experience.
- johnsmith1840 4mo ago
  I believe in a 10x because it's everywhere. It doesn't mean more work it often means creativity. For example when I was an EE I worked at a company that had spent nearly 8 months, 50k on consultants, and easily 3 peoples full time for a lot of effort plus the testing side. I swapped that 800$ board out for essentially a lightbulb. Did identical work <50$ and was more reliable. That simple change was easily a 10x improvement if not more because the logistics of that one board was absurd. I'm proud of that EE work but code is identical. I would never call myself a 10x developer but I've wiped entire code bases more than once. Maybe I have "10x" moments? But to say this isn't a real phenomenon means you're in a super structured and political enviroment.
  - pmontra 4mo ago
    I probably had that kind of 10x moment yesterday. I spent 2.5 hours analysing a feature request and I eventually advised my customer to think very carefully about it: it might solve a problem but the implementation time is going to be long, even with an AI, because of actual development and the time we will spend in testing it. Furthermore the new infrastructure will have recurring costs higher than what it saves. My advice is not to proceed. 2.5 hours vs 25 or more. 10x.
    - godelski 4mo ago
      > 2.5 hours vs 25 or more. 10x. My point is that these 10x moments aren't sustained. When we're talking about a "10xer" we're talking about someone over a longer period of time. For "in the moment"s and short term projects, 10xers certainly exist. There's definitely things I can do in a week that would take juniors more than 10. But for bigger projects? Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years? I'd really doubt the latter and the amount of things I can do in a month that a junior can't do in 10 are a whole lot smaller than what I can do in a week that they can't do in 10
      - johnsmith1840 4mo ago
        You can but not the way you're saying. Once was part of a team where a mid level guy spent a year building/heavy maintenance of some catastrophe of a solution. They literally had the end users copy and pasting hundreds of commands from a generated excel sheet of a command per core (shudders). I spent ~2wks on a different architecture that was a massive improvement we abandoned their code base. He quit like 4 months later to join some faang. Granted that 2wks of work was on top of a distributed cloud infra that took me 6 months to build. So yes, a skilled dev might skip entire months of work someone else would make. What you seem to be describing is a companies skilled engineer designs something and passes down the spec. The guy making the spec is the 10x guy. For large projects it's even more pronounced. The article literally described someone who wasn't skilled they simply knew how to smooze the MBA's and a company with poor engineering leadership.
yallpendantools 4mo ago
I think the myth/claim of a 10x developer is true but only relative to said rockstar engineer's immediate environment. Put simply, the 10x developer is a 10x because they've spent ~10x more time immersed in the problem domain than the average developer. What they do is more sleight-of-hand than Tony Stark engineering his way out of a terrorist cell. If 10x engineer takes a weekend to solve a problem that has stumped the team for a month, it's because he's collected the necessary context to solve the problem over the course of their long career; doesn't mean the answer didn't need to be synthesized, but they already had the raw materials in their cupboard. They have a giants' shoulder to stand on because they bothered climbing. They didn't derive anything from first principles; no one prototyped an Iron Man suit from scrap contraband. The implication being anyone can be a 10x engineer in the right environment. --- Allow me to carry my own throne with an anecdote, believe what you will: once upon a time, Engineering Manager had the brilliant idea to create a modular system for our main product, the pitch being that we can outsource feature development to contractors while keeping team costs down as we only need to maintain a lean modular system. They tested the idea on a couple of easy scope projects which were successful. Then came the big test. Three projects outsourced to a team of four contractors. These projects were far more complex than the first two: lots of state management and integration with other systems. In due time deadline neared and the contractors had a very pretty UI that just needed to be wired in. I got pulled in to see the projects home. It was supposed to be easy if not for the Pareto Principle. Relationship with the contractors soon soured as they bailed, showing us that they've technically already accomplished the project on their billable hours spreadsheet. We, the regular team, just needed to deploy the code they turned in but the deployment is none of their concern apparently. That's when I had to roll-up my sleeves, got dirty with their spaghetti code. The way I see it, the contractors fell on the part where they had to integrate with other systems because said systems were legacy, i.e., created before the idea of the Lean Modular Main System. Honestly, even I didn't know exactly how to work with them but, crucially, I knew how to get answers when the going got tough. I knew how to quickly figure out what I didn't know because as a regular employee I knew things beyond first principles. In the end, two out of the three projects deployed. They were only a couple weeks late. IIRC the third one only failed because it really ran out of time budget. Upper Management was not happy but Engineering Manager stuck out his neck for me, for which I am genuinely grateful. I didn't get exactly the coveted 10x wording out of him but he pointed out that I released 2/3 whereas a team of four couldn't even release one. That's not entirely accurate of course. I could code you up a decent web frontend but I could not, for the life of me, get all those pretty UI animations to work even if it's my only way out of a terrorist cell.
jghn 4mo ago
> a problem that the average developer can not solve, but a expert can solve? Yes these exist. The rate at which they exist is grossly exaggerated. Every company likes to think that their problems are special snowflakes. Nothing could be further from the truth. In these discussions we try to solve for a 0.00001% problem by claiming it's common to encounter.

by Veserv 4mo ago

godelski 4mo ago

> Have you literally never run into a problem that the average developer can not solve, but a expert can solve? In what time frame? > Even assuming that maybe the average developer could come to learn ... already knowing how to solve it on short notice being over 10x. 10x? I'm not convinced. 10x is a pretty big increase, as illustrated above. Clearly I understand the gap, I explicitly mentioned it. I mentioned a month's work is quite valuable. I'm not the one diminishing that value, you are. I can totally buy instances of 10x improvement, but that's not what we're talking about and not how anyone is using the term. Everyone is talking about sustained output. No one gives a shit if you're 100x for five minutes but 0.5x the rest of the time. Your critique isn't wrong, per say, but it is a non sequitur to the conversation. I doubt even a staff level engineer is even a 10x above the junior. Will the staff level engineer write better code and faster? Hell yeah they will! But will it take a junior 10 years to write the same software a staff level does in a year? Maybe. But if it does I'm not convinced they're even trying, so not a fair comparison. 10 years is a lot of time. A lot of time to learn, refactor, or even build the damn thing from scratch a few dozen times. Seriously, 10x improvements are actually wild. But why dismiss a 10% gain as if it's nothing? Why is the smaller number bad? Is the need for the number to go up so strong that we don't care how divorced from reality it is?

Jensson 4mo ago
> I doubt even a staff level engineer is even a 10x above the junior Its not about staff vs junior, its about smart vs dumb programmers. You don't get smarter with time, you just gain more experience.
johnsmith1840 4mo ago
I believe in a 10x because it's everywhere. It doesn't mean more work it often means creativity. For example when I was an EE I worked at a company that had spent nearly 8 months, 50k on consultants, and easily 3 peoples full time for a lot of effort plus the testing side. I swapped that 800$ board out for essentially a lightbulb. Did identical work <50$ and was more reliable. That simple change was easily a 10x improvement if not more because the logistics of that one board was absurd. I'm proud of that EE work but code is identical. I would never call myself a 10x developer but I've wiped entire code bases more than once. Maybe I have "10x" moments? But to say this isn't a real phenomenon means you're in a super structured and political enviroment.
- pmontra 4mo ago
  I probably had that kind of 10x moment yesterday. I spent 2.5 hours analysing a feature request and I eventually advised my customer to think very carefully about it: it might solve a problem but the implementation time is going to be long, even with an AI, because of actual development and the time we will spend in testing it. Furthermore the new infrastructure will have recurring costs higher than what it saves. My advice is not to proceed. 2.5 hours vs 25 or more. 10x.
  - godelski 4mo ago
    > 2.5 hours vs 25 or more. 10x. My point is that these 10x moments aren't sustained. When we're talking about a "10xer" we're talking about someone over a longer period of time. For "in the moment"s and short term projects, 10xers certainly exist. There's definitely things I can do in a week that would take juniors more than 10. But for bigger projects? Can I do in a month what a junior cannot in 10 months? Can I do in 6mo what a junior cannot do in 5 years? I'd really doubt the latter and the amount of things I can do in a month that a junior can't do in 10 are a whole lot smaller than what I can do in a week that they can't do in 10
    - johnsmith1840 4mo ago
      You can but not the way you're saying. Once was part of a team where a mid level guy spent a year building/heavy maintenance of some catastrophe of a solution. They literally had the end users copy and pasting hundreds of commands from a generated excel sheet of a command per core (shudders). I spent ~2wks on a different architecture that was a massive improvement we abandoned their code base. He quit like 4 months later to join some faang. Granted that 2wks of work was on top of a distributed cloud infra that took me 6 months to build. So yes, a skilled dev might skip entire months of work someone else would make. What you seem to be describing is a companies skilled engineer designs something and passes down the spec. The guy making the spec is the 10x guy. For large projects it's even more pronounced. The article literally described someone who wasn't skilled they simply knew how to smooze the MBA's and a company with poor engineering leadership.

yallpendantools 4mo ago

I think the myth/claim of a 10x developer is true but only relative to said rockstar engineer's immediate environment. Put simply, the 10x developer is a 10x because they've spent ~10x more time immersed in the problem domain than the average developer. What they do is more sleight-of-hand than Tony Stark engineering his way out of a terrorist cell. If 10x engineer takes a weekend to solve a problem that has stumped the team for a month, it's because he's collected the necessary context to solve the problem over the course of their long career; doesn't mean the answer didn't need to be synthesized, but they already had the raw materials in their cupboard. They have a giants' shoulder to stand on because they bothered climbing. They didn't derive anything from first principles; no one prototyped an Iron Man suit from scrap contraband. The implication being anyone can be a 10x engineer in the right environment. --- Allow me to carry my own throne with an anecdote, believe what you will: once upon a time, Engineering Manager had the brilliant idea to create a modular system for our main product, the pitch being that we can outsource feature development to contractors while keeping team costs down as we only need to maintain a lean modular system. They tested the idea on a couple of easy scope projects which were successful. Then came the big test. Three projects outsourced to a team of four contractors. These projects were far more complex than the first two: lots of state management and integration with other systems. In due time deadline neared and the contractors had a very pretty UI that just needed to be wired in. I got pulled in to see the projects home. It was supposed to be easy if not for the Pareto Principle. Relationship with the contractors soon soured as they bailed, showing us that they've technically already accomplished the project on their billable hours spreadsheet. We, the regular team, just needed to deploy the code they turned in but the deployment is none of their concern apparently. That's when I had to roll-up my sleeves, got dirty with their spaghetti code. The way I see it, the contractors fell on the part where they had to integrate with other systems because said systems were legacy, i.e., created before the idea of the Lean Modular Main System. Honestly, even I didn't know exactly how to work with them but, crucially, I knew how to get answers when the going got tough. I knew how to quickly figure out what I didn't know because as a regular employee I knew things beyond first principles. In the end, two out of the three projects deployed. They were only a couple weeks late. IIRC the third one only failed because it really ran out of time budget. Upper Management was not happy but Engineering Manager stuck out his neck for me, for which I am genuinely grateful. I didn't get exactly the coveted 10x wording out of him but he pointed out that I released 2/3 whereas a team of four couldn't even release one. That's not entirely accurate of course. I could code you up a decent web frontend but I could not, for the life of me, get all those pretty UI animations to work even if it's my only way out of a terrorist cell.

jghn 4mo ago

> a problem that the average developer can not solve, but a expert can solve? Yes these exist. The rate at which they exist is grossly exaggerated. Every company likes to think that their problems are special snowflakes. Nothing could be further from the truth. In these discussions we try to solve for a 0.00001% problem by claiming it's common to encounter.