4 ms·

I know 10x programmers exist cause I am one. I guess you'll have to take my word for it. For years I worked as a contract consultant. I'd usually only get ca

I know 10x programmers exist cause I am one. I guess you'll have to take my word for it. For years I worked as a contract consultant. I'd usually only get called in when projects were in crisis. I'd get into town, solve the problem, explain the problem and get out of town. I've worked in more than 20 workplaces so far in this way. But... It requires incredible focus and being constantly in crisis mode led me to burn out more than once. So now I work as a 1 or 2x and just take it easier and no one complains. You could say that I'm retired from my 10x life. I do sometimes fall back into the 10x mode, cos honestly the rush was exciting and it fed my ego, but I'm trying to no let my ego lead me down the path to burnout anymore.

ablatt89 4y ago
10x engineers unfortunately seem to never make it up the management chain, as they are threats to management and management just wants them to output things. Ironically 10x engineers can do architecting, project planning, and run sprints without managers and do it better, but will never be even offered a low level management position. Bonuses might be good but long term career prospects for any company seem pretty low if there's intent to "move up", unless maybe for a startup or making their own business.
- acedTrex 4y ago
  This is where a good IC track at companies that have it are a thing
- nawgz 4y ago
  Is this really true? I joined a small team in 2017 and carried them to success by building many applications at high speed. Now my team has tripled in size since then, and I have had multiple promotions and have around 5 reports on average I find it unlikely that I'm the only person who knows the simple tactic "I will quit if you can't meet this demand", so do you have any more materials to back this up? Or is it simply a feeling (don't get me wrong, clearly that's what I'm operating off too in this arena)
- firsttimebigboy 4y ago
  This is rational though. Why would you take someone who's a 10x at their current job and move them to a different job with a completely different set of skill requirements where they might not even be a 1x, and almost certainly won't be a 10x. It's a negative for the developer if they wanted to move into management, but I don't think it has anything to do with management feeling threatened.
- femto113 4y ago
  I have tried moving up the management chain (PM/TPM/Architect/C*). The biggest challenge I found is that generally I was still the most productive engineer available to apply to most problems, so I still spent time writing code (the alternative was like watching a fire burn out of control while holding a fire extinguisher). In some orgs (particularly bigger enterprises) that hit up against a wall of expectations for what people in my role could/should do. Eventually I settled on consulting as better fit--I still do stuff across the full spectrum, but as an outsider I'm not expected to fit into a particular box.
deleted 4y ago
[deleted]
MuffinFlavored 4y ago
What does something like this pay? I've been on both sides of this. I've been the hero, and then months later I've heard people say I was the issue. Obviously I don't know you and I'm not going to tell you to "be humble" or "you might be wrong".
- gerbilly 4y ago
  Oh it payed good! But it cost me plenty in burnouts too. Don't worry about asking me to be humble, it's _taught_ me to be humble, believe me. I also understand what you say about alternating between being the hero and being the problem. There is a tightrope to be walked so that you leave your client with code that works for them. I mean some tiny little kernel of code that only you understand isn't going to serve them in the long run. I'm not claiming to have always gotten that balance right.
lifeisstillgood 4y ago
So, I am interested in your specific examples, and they may counter what I am about to say. So simplistically, we can plot most companies on a boring 2x2 grid management v technical. With bad management (say culture, communication, inspiration as a catch all for management) and bad technical in the bottom left and great management and great technical t the top. And if you take a person from the top right and put them in the bottom left they will by comparison look awesome. But no-one on HN is going to say I am a 10x coder because I say - review SQL stmts and add appropriate indexing - run a profiler over the code base to optimise for hot spots - stop half the pointless reporting meetings so people can actually work - add in test suites (or do the rest of the Joel 12 tests) But those things will have outsized results, as will fixing product management etc. Just playing a standard game will have outsized results in some quadrants.
- gerbilly 4y ago
  Ok one specific example. I'd say the 10x part isn't about productivity but insight into the problem. Most people solve the problem as given, but the times when I've been 10x I managed to change the definition of the problem to something simpler, and easier to solve. Here's an example: At one company they had a 'financial calculator,' i.e. a program to help visualise how some financial math played out over time and it was giving incorrect results. When I looked at the code I saw that it had been written by composing a lot of those functions you see on actual financial calculators, (1/V, PV, PMT, etc...). This may have seemed simpler to approach it this way, but because there were so many compositions and there was a root finding algorithm involved, it quickly got out of hand. I started from the problem definition, defined a recurrence relation for what we are trying to calculate, found a closed form formula for the recurrence relation. This part was the hard part. Now those 3000 lines of FV1P(XYZ(ABC())) turned into like 20 lines of simple math, _and_ the formula could now be solved for the other variables, so no more root finding. I just solved for the other variables, wrote functions for them and that was it. It ended up being faster, correct, numerically more stable, and the code was smaller. I wrote up a white-paper on how the math worked, included a proof and that was it. It took two weeks. The value to the customer was that this bug in this one part of their 'suite' of applications was holding up a sale to major prospective customer of their's. So fixing this had an outsized valued compared to the severity of the bug.
deleted 4y ago
[deleted]
oxfordmale 4y ago
10 times programmers don't exist. Maybe a 2 or a 3 time engineer at most. That doesn't take away from your valuable contributions to the projects you have worked on. However, as you describe, you get brought in to solve a specific problem. You don't have to worry about compliance training, town halls, sucking up to managers and the other endless time sinks you have as a permanent employee. The reason ten times programmers don't exist, as programming is hardly ever just about spitting out lines of code. More often than not you have to spend time clarifying fuzzy requirements, getting cross team alignment on requirements or spend significant time on getting your code peee reviewed and build on less than efficient CI/CD systems. The myth of the ten times engineers is propagated by management. Senior management love to claim they hire the top 5% of the market, something that is statistically impossible.
- gerbilly 4y ago
  > 10 times programmers don't exist. Maybe not, but I _can_ say that for me the problems I unstuck for customers _were_ about programming, not requirements gathering or process. It usually was some small kernel of a larger codebase that was ill thought out (usually under-engineered, or solved with a naive approach that wouldn't scale/perform) and hadn't been thought out right. The solution usually involved recasting the entire approach and solving it some other way. You are right that I didn't have to deal with town halls, or scrums or any of that, and that was definitely part of the upside. But what I _did_ have to deal with as a 'fixer' was that I never know what specific skills would be required at this particular customer site. It required thinking on your feet and was frankly exhilarating to pull of.

ablatt89 4y ago

10x engineers unfortunately seem to never make it up the management chain, as they are threats to management and management just wants them to output things. Ironically 10x engineers can do architecting, project planning, and run sprints without managers and do it better, but will never be even offered a low level management position. Bonuses might be good but long term career prospects for any company seem pretty low if there's intent to "move up", unless maybe for a startup or making their own business.

acedTrex 4y ago
This is where a good IC track at companies that have it are a thing
nawgz 4y ago
Is this really true? I joined a small team in 2017 and carried them to success by building many applications at high speed. Now my team has tripled in size since then, and I have had multiple promotions and have around 5 reports on average I find it unlikely that I'm the only person who knows the simple tactic "I will quit if you can't meet this demand", so do you have any more materials to back this up? Or is it simply a feeling (don't get me wrong, clearly that's what I'm operating off too in this arena)
firsttimebigboy 4y ago
This is rational though. Why would you take someone who's a 10x at their current job and move them to a different job with a completely different set of skill requirements where they might not even be a 1x, and almost certainly won't be a 10x. It's a negative for the developer if they wanted to move into management, but I don't think it has anything to do with management feeling threatened.
femto113 4y ago
I have tried moving up the management chain (PM/TPM/Architect/C*). The biggest challenge I found is that generally I was still the most productive engineer available to apply to most problems, so I still spent time writing code (the alternative was like watching a fire burn out of control while holding a fire extinguisher). In some orgs (particularly bigger enterprises) that hit up against a wall of expectations for what people in my role could/should do. Eventually I settled on consulting as better fit--I still do stuff across the full spectrum, but as an outsider I'm not expected to fit into a particular box.

deleted 4y ago

[deleted]

MuffinFlavored 4y ago

What does something like this pay? I've been on both sides of this. I've been the hero, and then months later I've heard people say I was the issue. Obviously I don't know you and I'm not going to tell you to "be humble" or "you might be wrong".

gerbilly 4y ago
Oh it payed good! But it cost me plenty in burnouts too. Don't worry about asking me to be humble, it's _taught_ me to be humble, believe me. I also understand what you say about alternating between being the hero and being the problem. There is a tightrope to be walked so that you leave your client with code that works for them. I mean some tiny little kernel of code that only you understand isn't going to serve them in the long run. I'm not claiming to have always gotten that balance right.

lifeisstillgood 4y ago

So, I am interested in your specific examples, and they may counter what I am about to say. So simplistically, we can plot most companies on a boring 2x2 grid management v technical. With bad management (say culture, communication, inspiration as a catch all for management) and bad technical in the bottom left and great management and great technical t the top. And if you take a person from the top right and put them in the bottom left they will by comparison look awesome. But no-one on HN is going to say I am a 10x coder because I say - review SQL stmts and add appropriate indexing - run a profiler over the code base to optimise for hot spots - stop half the pointless reporting meetings so people can actually work - add in test suites (or do the rest of the Joel 12 tests) But those things will have outsized results, as will fixing product management etc. Just playing a standard game will have outsized results in some quadrants.

gerbilly 4y ago
Ok one specific example. I'd say the 10x part isn't about productivity but insight into the problem. Most people solve the problem as given, but the times when I've been 10x I managed to change the definition of the problem to something simpler, and easier to solve. Here's an example: At one company they had a 'financial calculator,' i.e. a program to help visualise how some financial math played out over time and it was giving incorrect results. When I looked at the code I saw that it had been written by composing a lot of those functions you see on actual financial calculators, (1/V, PV, PMT, etc...). This may have seemed simpler to approach it this way, but because there were so many compositions and there was a root finding algorithm involved, it quickly got out of hand. I started from the problem definition, defined a recurrence relation for what we are trying to calculate, found a closed form formula for the recurrence relation. This part was the hard part. Now those 3000 lines of FV1P(XYZ(ABC())) turned into like 20 lines of simple math, _and_ the formula could now be solved for the other variables, so no more root finding. I just solved for the other variables, wrote functions for them and that was it. It ended up being faster, correct, numerically more stable, and the code was smaller. I wrote up a white-paper on how the math worked, included a proof and that was it. It took two weeks. The value to the customer was that this bug in this one part of their 'suite' of applications was holding up a sale to major prospective customer of their's. So fixing this had an outsized valued compared to the severity of the bug.

deleted 4y ago

[deleted]

oxfordmale 4y ago

10 times programmers don't exist. Maybe a 2 or a 3 time engineer at most. That doesn't take away from your valuable contributions to the projects you have worked on. However, as you describe, you get brought in to solve a specific problem. You don't have to worry about compliance training, town halls, sucking up to managers and the other endless time sinks you have as a permanent employee. The reason ten times programmers don't exist, as programming is hardly ever just about spitting out lines of code. More often than not you have to spend time clarifying fuzzy requirements, getting cross team alignment on requirements or spend significant time on getting your code peee reviewed and build on less than efficient CI/CD systems. The myth of the ten times engineers is propagated by management. Senior management love to claim they hire the top 5% of the market, something that is statistically impossible.

gerbilly 4y ago
> 10 times programmers don't exist. Maybe not, but I _can_ say that for me the problems I unstuck for customers _were_ about programming, not requirements gathering or process. It usually was some small kernel of a larger codebase that was ill thought out (usually under-engineered, or solved with a naive approach that wouldn't scale/perform) and hadn't been thought out right. The solution usually involved recasting the entire approach and solving it some other way. You are right that I didn't have to deal with town halls, or scrums or any of that, and that was definitely part of the upside. But what I _did_ have to deal with as a 'fixer' was that I never know what specific skills would be required at this particular customer site. It required thinking on your feet and was frankly exhilarating to pull of.