Hacker News Reader

Comment by gerbilly | Hacker News Reader

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.

View on HN

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.

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)

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.

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.

This is where a good IC track at companies that have it are a thing

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.

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.

so my bag at the moment is software is a form of literacy. And that implies that (for now) some people can read and write and some cannot.

Most business / software problems revolve around the problem of getting a person who understands the problem to explain it and work with the person who can write software.

Your example is fascinating- and suggests that it works better when one person understands both parts :-)

Literacy is a good way of putting it.

Another example I can give is when a client had some process represented by a graph, with boxes and arrows, but the structure of it was really ad hoc. It was _mostly_ a DAG except with some extra back edges they'd added to solve specific problems.

I suggested modifications to their structure, their algorithms and their DB storage for this thing so that it _did_ become a DAG, being careful to explain how to keep their functionality working.

After that the graph could be topologically sorted, and the upside was that instead of loading the whole graph at once as they were doing, we could load a single topological 'level' at a time.

Added an index for topological level in the DB and we were able to make it efficient.

They did have to do some work on the calling side, because they used to load it all at once, and now they had to load it in pieces, but we gained an order of magnitude or more in load time, so it was deemed worth the effort.

I am fascinated by the psychology of this as much as anything.

Any organisation is a meta-brain, and has emotion running throughout.

Your two examples seem to come after the wheels have fallen off and the magnitude of the problem is evident to all. And they call in a consultant who might see a DAG or (more often I suspect) might see opportunities to sell 120 off shore developers and a rewrite using IBM/Java

But anyway, if you had walked in a year previously with exactly the same plan would you have gotten any traction? A maths heavy white paper explaining why your ideas are the same as theirs but better would have met enormous emotional headwinds.

Maybe our scientific revolution over the past few hundred years is a blip. That does worry me. If better solutions are avoided because of emotional reactions, it costs us all.

Sorry this is starting a lot of thoughts and I should cover them more carefully. thanks for the insight and congratulations- soujds like a fun career !

> if you had walked in a year previously with exactly the same plan would you have gotten any traction?

Nope, most of the time it wouldn't and my experience bears that out ("Let's not boil the ocean...").

Thinking simple, and avoiding premature optimisation, are so often the right thing that we can forget that they don't always work.

Teams and people often prefer to learn the hard way. Mind you _I_ haven't built any companies or startups, and my up approach probably would lend itself to do that either.

There's an adage, by Fred Brooks: "Plan to throw one [implementation] away." I come in when they are ready to throw one away, but aren't sure what to replace it with yet.

As far as it being fun, sort of. First of all I have a more 'normal' job now, second of all it's a rush, and an ego boost, but ultimately exhausting.

>>> I come in when they are ready to throw one away, but aren't sure what to replace it with yet.

Perfect - yes.

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".

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.

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.

> 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.

Reply on news.ycombinator.com