Hacker News Reader

Severe ADHD, uncontrolled for 30 years until recently.

I’ve been the 10x programmer several times in my career. Interesting positions that kept me hyper focused. Built out entire product lines, saved or made companies millions.

I’ve been 1x or much lower on uninteresting projects, or ones where I couldn’t get management to deal with blockers.

Some of these have been at same company. Just depended on the project.

Why do people take some idea and totally botch it?

Whole idea is taken out of context. There is nothing about "superhuman 10x dev" it was simple realization that IN ONE TEAM there are developers who are 10x faster to deliver tasks and there are slower devs.

Just like in university group assignment there are slackers and there is that one person who does the assignment.

Worst of all is that people start assigning "10x" to themselves or others or judge others as "0.1x" - which is meaningless out of very specific context.

My reading is that some hold a belief that the distribution of developer productivity/skill is not a Normal Distribution. Yes, in a normal distribution some on the right will be 10x those on the left. But as I read it, the “10x” advocates propose there is some sort of Guru Spike on the right hand side that’s specific enough to the realm of development to create a meme from it. I harbour skepticism that it’s anything but a normal distribution.

I think this nails it.

Programming, at least complex programming, is a gestalt of many skills ALL of which are probably a normal distribution (intelligence, focus, problem solving, political savvy, curiosity, experience, etc. etc.) How could it NOT have at least a 0.1x to 10x distribution?

To me the concept doesn't even have to mean that individual is outputting 10x amounts of code or closing 10x stories...

More so it means that there ideas, abstractions and frameworks result in substantially higher productivity for anyone working on the project than the average dev.

Beyond just the talent to do this successfully, you also have to give people the space and freedom to actually do 10x work... This tends to extend well beyond the narrow scoped requirements written in the current sprint of tickets.

Bingo. 10x is not about how fast someone codes. That is why there is confusion here. Of course someone cannot write code consistently 10x as fast or write 10x as much code. On a regular basis? That is nonsensical.

When talking about 10x devs (or 10x any type of employee), it is about Judgement. The decisions they make on what they work on, how they achieve it, and (probably most importantly) what they choose NOT to work on. Judgement is the deciding factor in whether someone has a 10x impact on the business over time. It absolutely is not how much code they write. As a matter of fact, removing code can be a 10x improvement as well.

I disagree that a regular 1x programmer is comparable to someone slacking off on a university group assignment. I prefer the sports analogy, where there are some stars with disproportional impact in the outcome of games, but who work with other also very hard-working, professional athletes. No one is slacking around, there is just some people that are better.

Also, I do think there are 10x programmers that are 10x in a myriad of contexts, not just one team.

I am not botching your idea, I just have a different perspective of what the term “10x” means.

You are not botching my idea but Fred Brooks idea:

*Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring perfor- mances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and per- formance. (I doubt if that is universally true.)*

Having five 3x programmers on a team is likely a more pleasant working situation than having one 10x and four 1x programmers - also, slightly more productive! I wonder which arrangment is harder to create?

    The one who is 10x at the expense of their colleagues [...]

    The one who is, at most, 1.5x or 2x but think they are (and 
    sell themselves to the leadership as) 10x [...]

Yes.

The root issue, of course, is that management essentially never has the time or chops to discern the quality (maintainability, readability, performance, correctness, etc) of the engineering work being delivered.

Management only understands timely delivery. Which is crucial, obviously! But considering only quality or timeliness at the expense of the other is of course a dark dark pattern.

Even when management are software engineers themselves, they typically just don't have the time to be elbow-deep in the code their reports are delivering. This is particularly true in fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks. And even if your manager does get it, their manager probably doesn't, their manager's manager doesn't, the stockholders don't, etc.

I don't know the answer to this. It seems to me almost impossible to avoid this in a commercial setting unless you have a tiny team (less than 10 engineers?) and the CEO/CTO is a top-notch engineer.

Talk me down off of this ledge. Tell me it's possible.

> Management only understands timely delivery.

as they should, because it's the only thing that matters to 99% of humans for any non-critical stuff (and honestly, even critical... even stuff that can kill humans, we are very good at saying "one chance of death in XXX is an acceptable risk" ; I'd wager that anything that is below the average death rate of car driving in a particular time / area is in general ok).

I'd rather learn a software that has bugs today than a perfect software in a year - by that time I've already organized my workflow around the bugs and already spent 1/30th of the time of my projected remaining future career around this software. I'm not going to re-learn yours even if it works better.

    as they should, because [timely delivery] is the 
    only thing that matters to 99% of humans for any 
    non-critical stuff

Right, but here's the thing. Tech debt is inseparable from timely delivery.

The tech debt you accrue today in the name of "shipping fast" hurts your ability to execute timely delivery in the future.

That's why management should care.

or is it ? some code is made to be long-lasting (and that's the one we "see" because of course it lasted long already) but the large majority is short-term projects which are only relevant for a few months / years and will never get reused afterwards.

Hah, yeah, I think we haven't a terminology difference here. I wouldn't even term "bad" code in short-lived projects to be "tech debt" in the first place.

I definitely agree you about the near irrelevance of tech debt in short lived projects.

     the large majority is short-term projects which

Is this really true? Really depends on where you work, I guess. It hasn't generally been my experience.

But it really depends on if you're working at e.g. an agency vs. working on long lived in house projects.

> fast moving fields like front-end development where you have lunatics running the asylum and standards and practices change every three weeks.

Hate to break it to everyone but its really not like this, unless you're stuck in a loop of a bunch of resume driven engineers there's alot of stability in frontend development, especially since the advent of meta frameworks (Next.js, Nuxt, Modern Angular etc) and stability in tooling (rollup v2+, webpack 5+, and especially esbuild / vite)

If you want to be even more stable here, you can forgo a lot of headache with web components, which will always have some backward compatibility built in thanks to it being build on standards.

It isn't 2016 anymore. New frameworks aren't just popping up left right and center and expecting adoption. There's a lot of stability out there and there will be for the foreseeable future.

Much like any engineering endeavor there are, yes, people pushing the frontier, but all communities have this.

     unless you're stuck in a loop of a bunch of resume driven engineers

This has been my experience and the experience of many peers that I've heard from. Admittedly, there's an inherent selection bias there... people dealing with frustrating situations are certainly more apt to speak up about them.

I've known all 3 of the enumerated types. I'd suggest a 4th to add in.

- The humble one, who helps mentor their colleagues to be better at what they do. They do this by helping provide critical insight at important junctures. By not attempting to grab the spotlight, but instead shine praise upon their colleagues.

These are people who help everyone get better. They are out there. While the first 3 are the loudest and most annoying, this 4th type is rarely self-identifying, often self-deprecating as they don't crave attention.

>The one who really is 10x, knows it,

I have a friend like this. I have never worked with them, but get to hear about how all their teammates are nearly useless on every team they work on throughout their career (mix of FAANGs and startups). Every time they join a company, they quickly become the team expert and biggest contributor, because they enjoy working long hours, spending their weekends coding, and are a very talented programmer.

I recognize they are extremely passionate for what they do, but I would never want to work with them personally. That kind of work relationship cannot be fun for anyone, except maybe the stake holders that are seeing rapid progress.

> The one who is 10x at the expense of their colleagues (they run fast and break things and leave to others clean what is broken, which is part of the reason that they are fast).

In that case they are not 10x. They are not producing 10x value if they are making it harder on their coworkers.

> The one who really is 10x, knows it, everyone that worked with knows it, but they are just obnoxious about it

In that case they are still not 10x because if they aren’t reined in, no one wants to work with them and work still gets done slower - again not producing 10x value.

You're hitting on the most frustrating aspect of this argument, the sometimes bizarre imaginary scenarios to try to make 10x a negative instead of a positive: "what if they're a 10x programmer but also a psychopathic serial killer who targets their colleagues!?!?!"

There is nothing “imaginary” about it. If you produce code that is harder to maintain, you’re producing negative long term value.

There are plenty of smart pricks in our industry.

Also if you produce code and don’t bother leveling up your coworkers, you’re a long term liability to your company.

The imaginary part of it is that you think that's what I mean by a 10x developer.

It's like insisting that surgeons are terrible people and pointing to Jeffrey Dahlmer because he also cut up people.

While what you are saying is true, sometimes 10x is 10x. They push that feature and it secures an investment round. They push that feature and it secures an important client. They push that feature, don't commit it to the main branch, write tests, commit tests to the main branch,and help the team kill that debt over the course of a few months.

I think the highly productive programmer who ships features like crazy but leaves a trail of garbage in their wake for others to clean up is actually the most common archetype I’ve seen in real life.

The core issue is the disconnect between leadership and other engineers: the leadership heaps praise on this person, gives them interesting work, and takes projects they think are “behind” away from others for their superstar to work on. The other engineers are left feeling resentful that they have to fix/maintain/extend/support this horrible tangled mess of code, while the “10xer” moves on and never has to deal with cleaning up their own mess. Sometimes management will actively protect the person’s time by asking others not to bother them with questions about their code while they focus on whatever’s next!

The features shipped have visible business value and are easily measured, but the impact on employee morale/retention/velocity is harder to measure, so it’s overlooked.

> I think the highly productive programmer who ships features like crazy but leaves a trail of garbage in their wake for others to clean up is actually the most common archetype I’ve seen in real life.

Yes. I've encountered more of these than I have 10x developers. In fact, I've FIRED more of these than I've encountered 10x developers.

That doesn't mean 10x developers don't exist.

Yep. I’ve noticed that the term “10xer” gets used in both the sarcastic and the serious sense, and it’s important to keep the archetypes and characteristics separate. I tried to clarify in this old comment:

https://news.ycombinator.com/item?id=18462325

- The one who is <INSERT ANY RATIO, EVEN NEGATIVE> at the expense of their colleagues

- The one who is, at most, <INSERT ANY RATIO, EVEN NEGATIVE> but think they are 10x and get a very disproportional part of the money, promotions, praise, notoriety.

The 10x jerk is a really common trope that's thrown around every time the 10x debate comes up anywhere in technical circles. Truth is while they exist, not all 10x are like that.

I've seen 10x that were excellent mentors. Perhaps not in a traditional sense, but through code reviews and answering questions. Everyone working with him seemed to improve really quickly.

I think the reason so many people have doubts on the existence of 10x is that they might have never encountered one.

I recall a story someone told me a while ago. Software business that did local CoL/prevailing wages. Hired an intern one summer that was just running around in circles around the other, more senior devs. Useless to say they loved him and the next summer they tried to get him back, even offering a signing bonus for an internship (something they considered unheard of) but he was already at a large search engine company down in the Bay. You can guess the comp was probably already 3x what his previous job was offering. Of course, he wouldn't return.

There's a whole class of engineers were completely invisible to most companies, even if they are in the same "local market" [0][1] (Some use the term "dark matter devs" but I know it has another meaning [2]). These guys tend to fly under the radar quite a bit. If you are in a tier 2 market or company, your chances of attracting one are close to nil. Because they are extremely valuable, they don't interview a lot and tend to hop between companies where they know people (or get fast tracked internally). When hiring is red hot, they might completely disappear from the hiring pool by junior year.

[0] https://blog.pragmaticengineer.com/software-engineering-sala...

[1] http://danluu.com/bimodal-compensation/

[2] https://www.hanselman.com/blog/dark-matter-developers-the-un...

But it takes two to tango. In my experience a lot of the negative impact of a 10x:er is actually that they make 1-3x:ers feel very insecure, and some of them can’t handle that / go off the rails…

Now, is that really the 10x:ers fault?

That has not been my experience at all with "10x" programmers. I have often run into the first type from the parent comment - "hyper-productive" people who churn out huge amounts of code without a lot of thought. They tend to leave side effects all over the codebase, and often have someone in management who sponsors them (hoping to ride to promotions as a pair) who forces other teams to carry the burden of cleanup. However, if you run a startup, this kind of person really is an amazing asset, because there isn't a lot of codebase to clean up.

People I have met in the the third type (true 10x-ers who know it) seem to have a lot more humility, in my experience, than suggested here. If you look solely at metrics like kLOC/year, they are often in the middle or bottom of the pack. They are not usually generalists, instead specializing in some area that is of high value.

I’ve seen it many times. I’ve even seen managers on teams try to sabotage a 10x:er because he made the manager (and team) look bad.

When a single individual outperforms a large group the large group typically doesn’t like it, or the person doing it. Sadly that’s just a part of human nature. Where I live (Sweden) it’s referred to as the law of Jante. In other parts of the world it’s referred to as tall poppy syndrome or crab mentality.

Do you think 1.5x people get paid 50% more than a 1x typically? If a 1.5x got paid 50% more for doing 50% more work, do you consider that disproportionate?

Fully agree. Will say that although the third type may be great at delivering value, they may have a negative effect on the team and either drive away talent from the team, bring down morale, or cause the only people to stay with the team to be less ideal (since some great team members may see the toxicity, and understandably avoid that job)

That is to say, some at this type surely can be managed, but it may take a really good manager (and even that may not be enough), along with team mates who are not only good, but also able to deal with such a team member.

Which in the end may negate the 10x productivity, or at the very least reduce it.

I guess one alternative is having them in their own “team” basically reporting to a director but having no immediate team members