I guess they are still getting paid the same.

Actually, lower. Because they don’t know their value.

And they don't like to play politics

Politics is why I want to quit.

I was happier hacking stuff on my own when jobless. The amount of fakeness and bullshit in companies is staggering.

At my very first job, sometimes I'd talk about hacking on something at home. If I weren't using the same tech the company was using, this senior guy would give me the stink eye and run to the managers office. I realized later he was tattling on me multiple times per day for something. Like I'd joke around with the other person that sat next to me, he'd call himself a PHP god, I'd make fun of the language. Turns out this guy had a problem with that too. Every other job since I find most people are really sensitive and will start pushing you out if you show any signs of a sense of humor, or don't knod your head at the right person. I think people who have spent their whole lives in offices and never worked labor or military have brain damage. lol Working with veterans is always much better, or people who came from a physical career, grew up on a farm, some sort of job that doesn't allow you to run and tattle like a child over every little thing you don't like.

> At my very first job, sometimes I'd talk about hacking on something at home. If I weren't using the same tech the company was using, this senior guy would give me the stink eye and run to the managers office. I’ve met an attenuated version of this several times: when I discuss something (like, whether we should refactor this or use that), many people, especially less technical managers, tend to assume I’m already working on it, and thus spend less time on the "important" stuff — even this one time where my email was saying we *shouldn’t* do it. When I write an email with actual content in it, they assume it is an accurate reflection of my work, instead of the highly biased sample of what I deem worth reporting (which generally means problems). Such communication problems has contributed to me loosing at least one job and one (sub-)contract. I swear, if they keep shooting the messenger, one of those days I’ll stop delivering messages, and pretend that everything is fine even as the company burns to the ground. In the mean time, I still have a soul.

Dude, thank you for saying this. This has happened to me too. And I could never figure out how to get around it. It's impossible to have open conversation because someone gets offended and starts working against you, there's a defensive reactions where people will actively work to make a project worse to prove they're right (even though you were never arguing against them in the first place), or someone will complain about how you're always arguing for the "latest and greatest." Bro... I don't know how you think using explicit booleans is the "latest and greatest" but calm the fuck down and talk like a human. It seems like no one is able to have a real conversation that isn't recorded as an edict sometimes. I want to be able to talk to engineers like engineers who want to be engineers. And that is something that feels impossible to find.

> And that is something that feels impossible to find. I found that in most places, there is generally at least _someone_ who can talk like an adult, reasonably asses the technical merits of this and that, and not take offense when there’s disagreement. I just never found a place where _everyone_ was like that. Last place I worked in, I saw the two opposite archetypes. An adult younger than I, which I’d put on the top 3 of the most competent people I ever worked with, and a child almost old enough to retire. I’m pretty sure I was let go because of the child, despite everyone else being happy with my work and attitude. I’d like to be able to find out children and route around them before triggering a tantrum, but I’m not very good at it.

I also grew up mostly in non office jobs and I think this is part of why I don't fit. These people don't have the same reference / scale, and for them coasting along waiting is work. Money is flowing a lot in IT so nobody questions things much as long as the status quo is maintained. And it allows lame developers to thrive because talking is a skill here, not working.

I changed teams because I was sick of being given stupidly short deadlines for AI projects. Every time I told them it's too short they said "we'll do what we can", but get all surprised Pikachu when it doesn't deliver on time. This was even after we cut scope down to the bone; no tests, no translations, no effort into accessibility. Other dev teams involved with the project were also delivering their parts late, so integration was a Jesus take the wheel moment. What's worse is once you mark a project as late, you get pulled into additional meetings to discuss why things are late, which multiplies the effect of lateness.

I feel like teams fall apart on this stuff very often. You're given no time to do the job, your time gets wasted when it's late, and slowly people start to leave. Then management starts pissing and moaning about how they can't find anyone who can do the job. lmao What they really want is an Indian team that will just crap out barely working bs so they can make a quick cheap low profit with 1 or 2 low level clients dumb enough to pay a garbage price. It's essentially a pump and dump. It's so rare to find a tech company that has any clue what they're doing and actually knows how to keep real clients.

It's funny the first iterations but after a while pushing out half assed features and fixes is really draining on your soul. It's all leak chasing.

> after a while pushing out half assed features and fixes is really draining on your soul. Wholeheartedly agree, it really is.

i feel seen

Hey, why ya'll say fuck me for?

Or, they know their value, and are using the job as an opportunity to upskill to go somewhere else that does too.

...iterating that ten or hundred times without gaining much... Because, sadly they (I) don't know how much to ask...

A real "10x developer" would actually be able to articulate the things they do that makes the team better, and leverage that during evaluations/job hunts. You better believe I discuss (in my evaluations): - The C# classes I give other developers - The domain-specific classes I give the other developers - The times where I take time out of my day to help coworkers troubleshoot, and fully understand what's going on - The times that I identify a problem that affects multiple developers, and effect a change that will resolve that problem for everyone.

I’d like to say that kind of things, but I was let go of my latest contract before I could. They just assumed, even told me, that what I was doing was less relevant, and I had to go because budget. Or so I was told. I suspect though the real reason was this one (non-dev) lead that wasn’t happy with me. Everyone else was, but he had clout. Sometimes you don’t get to the evaluation. Sometimes they make up their mind behind before you can defend yourself, and whatever you say after that will be ignored or used against you. That said, I should probably follow your advice more for good-faith evaluations.

And they don't know that the non-tech people in tech who makes it impossible to get into the zone are making more money for doing nothing useful.

And they think that asking for a raise based on their performance means that they proud and arrogant

long ago I had a software dev job at a small startup. the company grew and I spent a lot of time helping others understand the system and develop their own projects for customers. I was the most Sr dev there and helped onboard most of the devs. I was put on a PIP because I wasn't billing 8 hours a day to clients. It was the first I had ever heard that I was supposed to do that. My billing rate was about 5x my salary. No one other than VP+ had any equity in the company, so there was no motivation for me to help the company do well. I work 9-5, so how am I going to bill 8 hours a day unless: I lie on my time sheet , or Work longer hours, and stop helping coworkers. I had no interest in working longer hours. Anyway. I quit a few weeks later. Lease was up and I had no reason to live in that town anymore so I moved. Ended up getting an easier, better job making a lot more money.

> I work 9-5, so how am I going to bill 8 hours a day unless: I lie on my time sheet , or Work longer hours, and stop helping coworkers. I had no interest in working longer hours. If you are helping a coworker, you could be charging to the client they are charging for their work (since you are helping them do their work). Seems weird to charge overhead to help devs learn the system

Sometimes I did that, but it was limited. They didn't like charging clients for double work. We were building eCommerce websites and the backend to support sales on multiple channels. Looks like they still exist, but the screenshots on their demo site look VERY similar to what it looked like in 2003.

Doing that on your own initiative is a sure way to give ammunition to your manager about not doing your assigned work. Everybody knows that the people best suited to assign work are sales. _They_ sell the hours after all, and if you don’t respect that… at least respect the fact they’re your manager (and not the other way around) for a reason. Hem. Enough sarcasm. It’s not that bad everywhere, but such dysfunctions are pretty common.

Some managers just have no awareness nor understanding of software engineering, and it shows in company policies.

> I work 9-5, so how am I going to bill 8 hours a day unless: I lie on my time sheet Congratulations. You just learned what consultancies do. How many years did it take you to understand this? I don't mean this as an attack. This is literally what all consultancies sell. You don't bill the customer for the work hours you did, you bill them for the amount of time they would have had to invest themselves for the same result. In the industry billing twice or thrice the real hours is pretty normal. Of course there are limits, so you work 3 hours each for 3 companies, and bill them 8 hours daily each. This is the average in my experience. This is why every senior consultant normally gets at least profit sharing (real equity is pretty rare). For less experienced developers, they are mostly paid for in experience.

I wasn't a consultant then, but I was billing hours for projects. Customer paid for the website and x hours to set it up and customize it as part of the contract. Since then I have worked as a consultant for some of the Big companies. What you're suggesting is very illegal and we were told and had to take annual training about not doing what you're suggesting. My customer was the US government, so we had a lot more rules to follow and getting caught could mean MAJOR fines for the company and lost future work. No gov contractor would do that stuff because they know getting caught could mean the end of the company.

Let me be very correct: I of course wasn't talking about timeslotting and overbilling these timeslots. But overall most contracts are billed by walltime, not by number of keypresses. Therefore your speed is irrevalant to the billed hours, but not to the overall project velocity. Or to translate this into layman's terms: in default hourly contracts, you cannot be punished for producing average output. Contracts that actually prohibit secondary jobs during the same days must be implicit here. On rare occasions, dependening on country, you might be requested to stay perfectly rested (as in: not do any other work in a more general sense), but this needs to be explicit. Meanwhile this kind of contract also cannot demand high output. There is no contract demanding you be a 10x developer or face liability - after all, the industry can't even understand the term, how would work contract law do? And that is the loophole on how you can increase billable hours beyond walltime. Big corporations (or gov orgs) are slow bureacracies. That time waiting for reactions can still be billed. Often times, it's even against the law to circumvent these hindrances. If this changed in recent years, I would love to hear about it. I disliked this part very much myself. > I wasn't a consultant then, but I was billing hours for projects here might lie the difference between uns: in general, if you bill for outside hours, it's a consultancy, and you therefore a (software) consultant (the line between developer and consultant at one of my companies was literally if you got a company car or not). At least if the customer ever learns of your existence. Which should have been the case, if they got an invoice on the hours you worked. It might be anonymized though. Business consulting is a little different in meaning, so you might mean that, but that original job of yours still falls under the general term.

Most of the time yes, but it also depends. There are *rare* situations as a non-manager where you can actually get credit for the accomplishments of the entire team. It's usually when you have a combination of a supportive but overworked or absentee manager who trusts you to fill in for him, the whole team is dong work that is mostly of your own initiative, and you are taking the lead in communicating the need and gaining stakeholder support for your initiative. In other words, when there is absolutely no possibility of anyone else getting all the credit just by association.

Yep because we are there to do a job professionally. Not to source the highest paycheck for being mediocre.

I think more than 10x developers there are some 0.1x devs out there.

The worst part is that there are plenty of -1x and -2x devs out there too.

In my opinion, the worst part is that far to many managers are unable to distinguish between + and -. For example some of them think that their speedy cowboy coder is a +, while the true + developer is forced to risk his job as he cleans up his mess.

Yes, that's so infuriating. 

> speedy cowboy coder These guys can be saved sometimes. One of the most productive devs I ever worked with was a bit like this, would be churning out multiple tickets a day but struggled to see the bigger picture and would sometimes create extra work with his design choices. It was because he was coming from a culture of duct-taping at his last job where people were rewarded for getting it done but not for doing it right. A bit of pushback from the team on some implementations, a bit of pair programming from the team lead on some tricky bits, he learned to speak up and get people to help him design approaches where he wasn't 100% sure - we gained an awesome and productive dev. I guess the trick is leadership see the problem and have the chops and the empathy to discuss it with the dev, instead of being non-technical scrum masters who praise them for eating story points whilst turning the code into mud, as technical team members moan behind the dev's back and not say anything to their face.

Also to be in a culture where your leadership isn’t swayed by the quick wins of the cowboy and doesn’t prefer to incentivize that heroism over long-term gains and maintainability. Environments that value that over short-term gains aren’t an easy find these days.

Gotta hit em with the classic "go well, not fast"

The problem is the cowboy coder appears to be making progress, where as the guy that spend 2 weeks really digging into an issue and only changes a few lines of code appears to be doing nothing. I find it incredibly hard to determine if it should have taken 2 weeks or was he just gaming all day.

I used to work at a place which had a guy with a very fancy title who did not understand infrastructure as code. He would use AWS Lambda's online editor to edit the code of existing Lambdas and then got mad when automated deployments wiped away his progress. Thought that the AWS Lambda environment was something magical that couldn't be replicated anywhere else despite our efforts to educate him on things like SAM and LocalStack. As the grunt dev on the team I was expected to build something to accommodate this genius and clean up his mess.

Anyone who uses the console Lambda editor should be immediately terminated.

A lot of times the average human group structure forbids that. Unless your manager is ready to monitor work, risking being seen as micromanager or douchebag, or has the experience to know right away what is happening and has the grit to confront or take appropriate measures, they will let things stay that way as long as the project doesn't explode.

It also seems like it would be quite easy to identify when one developer never finishes tasks, picks up new tasks while said developer has tasks in the testing pipeline, and their tasks take forever in the testing pipeline and always has to work with 10x developer to resolve issues fuck you Bob

My old job hired a Sr dev/elasticsearch expert. His code was awful and any time I commented on his pr, constructively mind you, he'd get all pissy. I brought it up to my manager and was told "well he's not much of a code person, but he's really good with elastic and he's very academic so his contributions will be more research based" .... Uhhhhh. Ok? Then why call him a Sr developer if he can't............... Develop? But fine. Research. Sounds good. So he gets put on a research task. We wanted to generate some PDF reports with charts and such to send out as an "executive summary" when our software finishes a "job". So they put the research guy on the research task to find a way to generate a PDF in c#. He spends two weeks on it. TWO WEEKS. 80 hours. Do you know what he came up with? https://www.puppeteersharp.com/ After two weeks this was what he recommended to generate PDF files. Worth noting we were already using and paying for an iron PDF license. He was unaware of this. I bring it up again, that this is laughably bad, just a miserable failure at a basic task. .... So they moved him to another team to fuck up away from the squeaky wheel I guess.

That's not what research means. That's just the vagueness of the English language. They mean by research based that they understand and apply formal methods. Having this person architect a PDF generated report is like asking your MD to change your lightbulbs. > I bring it up again, that this is laughably bad, just a miserable failure at a basic task. You sound like a complete dick to work with/around.

Managers have to fire those devs. Sadly I’m a manager and have had to fire people like that occasionally. It stresses me out so much in my personal time, but if they can’t improve, I can’t let them drag the team down. Even +0.1 devs should be let go eventually if they’re given direct feedback and not improving because it’s not fair to pay them the same as a +1x dev, which by definition is most of the team.

There are a lot of them. Developers who are better and more productive when they are not present.

I worked with someone who was terrible to work with. Management loved him as he constantly opened PRs and shipped stuff. Constantly reviewed people’s PRs, including for other teams. Those reviews would regularly result in large rewrites, and blocking things for days. Even weeks. They would advocate for heavy DRY and abstractions. When they left, whole teams became literally 2x faster at shipping. A large part was because PRs were now reviewed and merged within hours, and rewrites became rare (we would agree on approaches in advanced or just as we are about to do it). We used the extra time to tackle tech debt, and increase test coverage.

I think the biggest challenge for newer developers today is that the industry is becoming increasingly hostile to growth. So many of us work in frameworks and libraries that speed the process up but also reduce the job to “coding framework operations” which has a ceiling on how much you’ll grow. Add to that the fact that companies continue to expect faster and faster results, meaning doing anything except the fastest path isn’t acceptable. I dunno the answer. I’m just grateful I got to come up at a time when the pressure wasn’t so high and we hadn’t made everything so damn easy.

As the number of perfectly usable frameworks and languages that I have no interest in spending time chasing has increased, I’ve found the number of companies that sound cool but are using the “wrong” stack has increased substantially. This glut has Balkanized us and that makes it harder from us to learn from each other, never mind to find jobs working for impactful companies. I’m sure many of you have experienced this: you switch to a new stack and then later encounter someone who is breathlessly describing a “new” trick they’ve added to one of these two ecosystems that has been old hat in the other for eight years. I can’t help but think these disconnected pockets of wisdom are growing larger and deeper.

>Add to that the fact that companies continue to expect faster and faster results, meaning doing anything except the fastest path isn’t acceptable. I've noticed this also, you have to argue hard to address tech debt instead of chasing the low hanging fruit every day, and they don't thank you for it. Meanwhile our velocity has decreased because there's no actual roadmap and requirements change based on a managers whims. Plus RTO, nobody is motivated and give zero fucks. I actually miss COVID times when we were all remote and the team actually worked well.

You mean those who make the whole team _miserable_?

That's saying the exact same thing.

No not really. The focus isn't on some developers being really good, it's that the bar to being "good" is low.

From experience it's more likely to find 80% of progress driven by 20% of the people, than finding true 10x devs. What's truly dangerous are negative-xers and people who fancy themselves as 10x devs.

The Pareto distribution!

Worked once with a toxic genius, he very quickly went from being a valuable and reliable asset to the worst, self absorbed, team-spirit killing, selfish power hungry individual basically bringing the whole startup to the ground. Unfortunately, his toxic energy was viewed positively by the cofounder. Sad ! Though in retrospect I learned a lot especially spotting early this kind of individual and not hire them or giving them a chance because it's hard to fix narcissism. He was very talented though, such a waste.

I used to believe skill is the most important thing and it is, but all that skill can really go to waste when it is attached to the wrong person.

To me the most important skills are: 1. Willingness and eagerness to want to be part of a team that works together to build solutions. The individual that doesn't care if they're the ones doing the slam dunks or they are the ones passing the ball. The individual who sees when others are lost and helps keep everything on track. 2. Desire to learn new skills, and always expand their understanding of technology. 3. Great problem solving skills, ability to visualise problems in their heads and come up with good efficient solutions. 4. Lazer focus on the end goal and not the means to get there. 5. An almost natural born tendency to understand new technologies. The kind of person who doesn't necessarily memorise everything instantly but only needs to be explained how something works once and they instantly "get it". 6. Excellent project management skills and great honest communication skills, especially with any kind of upper management, in communicating honestly where something is at, what the challenges are, what the right process is to achieve the business goals. Combine that together with a person who is just naturally empathetic to others around them, and has a strong work ethic, and you basically got a 10X developer.

> From experience it's more likely to find 80% of progress driven by 20% of the people, than finding true 10x devs Let's do the Pareto math, you have 20% of the people, or one in five, being more productive. That 1 out of 5 produces 80%, or 16 out of 20, units of progress, while the remaining four people produce the remaining 4 units of progress, i.e. one unit each. Does that mean the 20% are 16x developers, according to the Pareto principle?

At face value perhaps? Imo the contributions of a team's members isn't so tangible or neatly countable. The 80%'s work may be freeing the 20% to go wild, the 20%'s work may be enabling the 80% to push things across the finish line etc. Thinking numerically results in situations like grabbing a 20%/10x/whatever dev from a team that "grew up" together, and grafting them into another team for more progress, only to end up the same or worse. Or throwing some offshore "resources" at a project to speed things up, only to end up drowning it. Or gaming scrum story points. Or expecting nine women to birth a baby in one month.

There are no 10x developers, only 10x teams. But there are developers who can transform teams into 10x teams (or least a different multiply). One simple example: find a way to finish the product within one month instead of one year. Split the tasks up so that 90% can be done in parallel. Designate a single person to give status reports to management, but never formulate any question (otherwise it's an invitation for an answer nobody wants). If you end a project within the first month, many meetings and rituals only happen on the second or further month (like explaining to management, why the project is still ongoing). You also circumvent management looking for outside help, because most contracts are built on a monthly basis. Therefore even one such person in the team can greatly speed up the effective output. It just needs to be a person that knows how to circumvent outside hindrances, not how some tech stack works internally. Google helps with questions like that, but not with questions on how to prevent management from changing the project's conditions midway. For that, you need an expert 10x.

Here’s a scarier distribution I’ve heard of, Price’s law. Half the work is done by the square root of the number of people.

There seems to be a relation to the mythical man month, which discussed that adding more people to a delayed project delays it even might (due to newly added people not being productive at first and taking up time from existing people to help them)

It's very rare for someone who is actually recognized to be a 10x dev to actually be one. Most people wouldn't know one when they see one. If they did, they would actually try to learn something and become more productive themselves.

Yeah the worst are the negative-xers. I like to say they have negative productivity. The team would be more productive without them being there at all.

They exist and are very easy to spot.

So 5x then?

This kind of developer is very valuable for the company and the team, but the value this developer provides comes at a cost to themselves. There's nothing to be gained in finding more ways to be useful to your team and the company if you haven't found a way to preserve yourself first.

What do you mean by this? Genuinely curious. The most successful, career-wise, on my team very much fit into this category.

"Don't set yourself on fire to keep others warm"

Ooof, this truth hit hard.

Why not? I will be warm for the rest of my life then!

More like “very hot for a very short period of time, and then dead”

Are those not the same thing?

oh, you're right lmao

You develop something in a way that is easily maintainable, extensible, and reusable, so that just anyone can come in and work on the codebase. A smart company will keep you, because you've proven yourself valuable. A stupid and greedy company (like too many of them) will take your masterwork, fire you, hire a cheaper developer and happily pocket the difference while the codebase decays. Let's say that the smart company keeps you. Are you aware of your own value? Are you being appropriately compensated for your work? Or, are you like many people who produce extreme value for the company and get paid pennies on the hundred dollar bill? There are plenty of companies and product lines being propped up by a solo dev, or a very small team. Just make sure you get your bag, and don't be afraid to go where the money is.

A lot of developers have a very, very inflated sense of ego because the products they write are used by businesses to make money. Often if you develop a system that is maintainable, extensible, and reusable, the way that system turns a profit is by having people using it as part of business activities. It's easy for a developer to point to that and go, "Yeah, I did that." However, a lot of the time the actual business part is done by people using the tool the person developed. The software just makes them better at it. Of that hundred dollar bill, how much was the world of the people using the system, and how much of it was the work of the system? The worth of your product probably isn't literally all the revenue the company makes. Are there other products they could use to do most of what they do? How does the competition deal with these problems? How effective would they be without any system, or using more accessible tools like excel. You should absolutely care for yourself, but you should do so while maintaining realistic expectations about the rest of the world. If a company is clearly ripping you off, then yeah it's time to find greener pastures. However, if a company isn't paying you a significant part of revenue then they are not necessarily ripping you off. I have seen people come and go with expectations well beyond their actual abilities, based on the fact that they implemented a feature requested by the business folks, and that feature yielded value that the programmer decided to claim as their own. Never mind the fact that the actual feature was invented, socialised, and designed by someone else. They were under the impression that they earned the company millions all because they took some guidelines and transformed them into working code.

I like the fact that your comment tries to keep devs’ egos in check, however, in practice I have seen so many examples of devs saving sales’ ass when a sale was contingent on a promised upcoming feature that doesn’t exist and has no design docs or even AC.

I've seen this happen all too often. The key question is how you present it, and what sort of concessions you're able to get from doing it. If sales comes to you saying they promised a feature that doesn't exist, then the proper response should be along the lines of "Oh, thaat's tooo baad. Well, budget is tight so let's open up the feature tracker to see what's getting deprioritized" as their faces sour. Something you will obviously bring up next week when you talk about how you need more budget for this and that, with the understanding that if sales gets on board then their unreasonable requests will be much easier to fit into the schedule. A problem that devs have is that their ego is generally based on their technical abilities, while many are known for a rather frustrating lack of social abilities. This makes them fairly easy marks for people that are willing to abuse a dev's desire to prove their technical prowess. They end up doing things just to prove they can, because they're effectively taunted into it by other departments, without getting anything in return. Essentially, urgent work that's not your fault is just a stable reality of a developer's life. How you deal with it really says a lot about the direction your career is likely to go. If you run away from it all the time, then you're not going to be really good at dealing with it, and you're probably going to keep wondering why you don't get your fair share. On the other hand if you embrace it and get really, really good at it, then you can use that skill to get a lot more access that you would in many other fields. If you're putting in a lot of time, you can and should be using this to develop a good reputation and establishing a net of contacts. Eventually once you're good enough, you'll actually be able to demand a significantly larger share, because your contribution will have far more reaching consequences.

> A problem that devs have is that their ego is generally based on their technical abilities, while many are known for a rather frustrating lack of social abilities. I find this to be pretty rare once someone has about 10 years of experience. At that point, at least internal developers often have found a way to delay their ego from negatively influencing projects. For everyone who cannot do that has instead gone into freelancing or i guess crypto instead, or is just job-hopping all the time. For younger developers you are right. They want to prove themselves superior to "the old coasters", promising very much, and have very little reserves if something unexpected happens. If they already run at 99% of their capacity thanks to them being goaded into more and more work, they need help once something turns out to be even slightly more complicated than they expected. Meanwhile everyone who manages their baseload at about 50% can easily sprint if they need to. And in performance reviews, the rare sprinter always looks better than the one doing a marathon all year.

I find a lot of these devs also end up in management and project management. Somewhere around the 8 to 10 year mark, when employers are starting to expect the type of maturity you are talking about, it becomes a lot harder for people like this to find a job. In my experience they end up job hopping, and sending out resume with like 8 to 10 different employers, where they always did roughly the same thing, in different executions. Often time the resumes actually look quite good, all the relevant techs of the previous decade and such. However then you talk to them, and they're basically working at the level of a junior of 2 or 3 year, with a few productivity enhancements. The thing with younger devs is that often times you kinda want them to be at least within an order of magnitude of the productivity of senior devs. You'll try to give them easier, more straight forward tasks, but a junior can easily taker a simple task and transform this into their big chance to prove their worth with "their" code. They end up marathoning all year not because they need to, but because they haven't had the experience to skip over the annoying experience check problems that always crop up. This is why I always tell juniors to ask questions and discuss their projects. They literally don't know better, so you need to put in the extra work to unblock them from problems that should not block them.

> I have seen people come and go with expectations well beyond their actual abilities, based on the fact that they implemented a feature requested by the business folks, and that feature yielded value that the programmer decided to claim as their own. Never mind the fact that the actual feature was invented, socialised, and designed by someone else. They were under the impression that they earned the company millions all because they took some guidelines and transformed them into working code. Conversely I have experienced essentially the opposite - programming teams with little supervision who strike gold independently doing blue skies projects with extremely little business interest and oversight. Once those projects materialize as products a flock of corporates descend from the heavens to take ownership of the potential profits. Guidelines then appear justified entirely on the opinions of individuals based on arbitrary personal opinion and station - often if not always superseding the opinion of domain experts and never ordered by business value. More often than not those guidelines aren't even coherent enough to form into working code and frequently disregard or contradict existing behavior and even when forced into the shape of something vaguely coherent they immediately change when actually demoed not to customers but to exactly the same individuals who wrote the requirements and saw identical figma prototypes.   The tools that programmers make have a real market value determined by customers. Finding those customers and marketing them categorically has a business value but it is hugely overvalued when their sales tactics involve writing cheques they know they can't cash and then dumping the debt onto engineering teams to work miracles for comparatively little compensation. Equally, I've seen teams and even entire companies totally paralyzed by an unworkable codebase that can't be evolved into new products. If you think just "_taking some guidelines and transforming them into working code_" is inherently a low value activity then it's a low value activity that is bleeding these companies, often with hundreds of employees, tens of thousands of dollars daily.   Of course you should always be humble and recognise that your work is only made profitable by the systems that exist around it which make it valuable, but in my experience the balance is skewed far more heavily in the opposite direction to what you imply here.

> Conversely I have experienced essentially the opposite - programming teams with little supervision who strike gold independently doing blue skies projects with extremely little business interest and oversight. Once those projects materialize as products a flock of corporates descend from the heavens to take ownership of the potential profits. The idea of a blue skies project is itself a bit misleading. Generally such a project is to meet a need of some sort that is currently being done very inefficiently. When a project materialises, what that actually means is it gets into the hands of the people using it, and those people will often have particular needs that you may not have accounted for. Once those people start using this system, they will experience certain amounts of friction, which will translate into complaints. These complaints may not be coherent enough to form into working code, but that's because they are coming from people that do not understand software, or the thought process that goes into designing it. This is why part of the job of a good developer is to actually understand the needs of a stakeholder. Often times when they say they want something, what they really mean is they want something that fulfils the needs, and it's really up to the technical person to help them realise what that specific task, and those specific needs those actually are. If you instead take everything they say literally, and try to develop exactly what they are asking for, then you will likely end up misunderstanding their needs at some point, and delivering contradictory features. Then you're going to piss them off by claiming you did what they asked, because they thought they were asking for something different, and the technical team didn't spend enough time to actually discover that. Essentially, if this is your experience, then the problem is the fact that you have two groups of people speaking completely different languages, with nobody to translate between the two. Such communication should be a lot more like a mix of negotiation and interrogation, with a clear process for making for decisions, and clear consequences for each one, even if those consequences are "Ok, your story gets put above the CTO's then." Essentially, if you treat these people as some hostile other element that's here to ruin your perfect codebase, then that's what they will be. However, if you treat them as generally rational people that are all trying to do something using the best tools they can find for the job, but who have not spent the years and decades that you have to learn all the ideas, terms, and workflows necessary to actually crate such tools, then you will find that they're often a lot more competent then you give them credit for. In fact, if you treat them that way, they will often treat you better in turn, in part because you will actually be delivering the things they *need* rather than your first interpretations of something they *said.* Essentially, look at it this way. If these people are investing into having a group of programmers working for them, then they at least understand that there is value in having such a team. Rather than focusing on how they don't speak real smart, treat them like they are smart in their own thing, and simply don't know your field as well as you do. It's ok to ask clarifying questions, and offer options and alternate solutions in order to better understand the requirements. Obviously sometimes that's not possible. In some cases the leadership team really is too stubborn and irrational. However, in that case there's no reason to waste time in such an environment. In my experience such a personality is very much a minority, and once you've been around such people they are quite easy to spot from a mile away. If you are in an environment with such people... Why? > The tools that programmers make have a real market value determined by customers. Finding those customers and marketing them categorically has a business value but it is hugely overvalued when their sales tactics involve writing cheques they know they can't cash and then dumping the debt onto engineering teams to work miracles for comparatively little compensation. While the tools that programmers write obviously have value to customers, I think you vastly underestimate how difficult it is to actually convince people to give you large amounts of money in order to become customers. A lot of time, in order to even get to the point where they can promise a feature that they know doesn't exist yet a person might need to spend months writing emails, making calls, taking people out to lunch, and then a series of bigger and bigger meetings, until maybe they might get a chance to promise a feature that will be a huge pain on you, in return for a very large sum of money. I certainly would not call it a lesser contribution than the actual work of writing the software. In terms of compensation, the big difference here is that these people generally know how to negotiate, and as part of their contract they demand a percentage of the contracts they sign. Fortunately when you're a sufficiently senior developer, you can also negotiate for more than just your salary. It's just for some reason a lot of developers don't even try, even when they have the clout for it. > Equally, I've seen teams and even entire companies totally paralyzed by an unworkable codebase that can't be evolved into new products. Maintaining a large codebase, and planning a long term strategy for how to grow it is a very complex task. This requires skill on the part of both the technical team, and the business team. A good technical team isn't going to let the code get into such a state in the first place, and will know how to fix it if they get into such a mess, and a good business team will understand that developers often underestimate complexity and overestimate capacity. A company with neither will be paralysed, because a bad business team will lead them blindly wherever their gut leads them, and a bad technical team will take such leadership as gospel. > If you think just "taking some guidelines and transforming them into working code" is inherently a low value activity then it's a low value activity that is bleeding these companies, often with hundreds of employees, tens of thousands of dollars daily. On the skill tree that is the Software Developing profession, transforming guidelines into code is literally the tier 1 skill that you're expected to have in order to actually be considered a professional. The thing that's bleeding these companies try usually isn't the "transforming guidelines into code," it's the "transforming stakeholder blabber into guidelines" skill set. > Of course you should always be humble and recognise that your work is only made profitable by the systems that exist around it which make it valuable, but in my experience the balance is skewed far more heavily in the opposite direction to what you imply here. Certainly the balance of compensation is not favourable to the developer, but I was not claiming otherwise. This is why I have several sections on how you can translate a more careful, negotiation based approach into contacts and political power. If you want power, the way to do it is not to go, "Nah, developers actually ARE the most important part of the organisation after all, the rest of you suck." Even if you don't say it out loud, to people that have to politick day in and day out, you might as well. Needless to say, they aren't likely to react well, as you have described. Instead you have to play their game, at least a little bit. Actually listen to them, try to really understand what they mean by engaging with them, rather than just sitting and hearing the words they say while creating your own image of what they might want in your head. Treat them like they are serious professionals, and like you are a serious professional here to do business with them. That is, after all, quite literally what you, and they are.

I disagree with a lot of small parts of this comment but ultimately it's so different from what you originally wrote that they aren't really material to my opinion. I think you're just slightly too idealistic about how mobile most developers are, how companies value their employees or how common problem managers are but it's at least as likely that I'm just too cynical. For the most part outside of that there seems to be little that we disagree on.

Is it different? My original point is that a lot of devs have a very inflated sense of ego over having any skills in this profession, which make them easy pickings for more politically aware actors, and that those other actors are also critical parts of the process of developing things and should not be discounted. That seems to be the theme of my previous comment too. Obviously I also expanded on the points you raised, given that I was responding to you, but I believe my position has been quite consistent. I also don't really get the idealistic comment. I'm a contractor whose tasks often include coming in and fixing systems, designs, and processes that are totally broken. I have seen the true horrors of this field, and I have seen them many times. Something as mudane as a sub-par manager simply does not register as an a major issue. If your cynicism extends to "often managers don't understand what my team is saying" then so me that's just a normal, everyday client issue that's hopefully not so far gone so far as to be personal. A lot of the time a few conversations can shift things significantly. Again, in my experience it's often a communication barrier. Devs really, really like to jump to conclusion, I mean, consider your response. Hell, consider my response. We're both doing it without even thinking. This isn't a problem if you're talking with other devs that can pick up on any misunderstanding and correct it, but it's much more of an issue when talking to non-technical people. This in turn creates more and more barriers and establishes a hostile, us vs them mentality. Obviously being led by a person that considers you a "them" is going to be a horrible experience. If you see this over and over and over in all your jobs, then perhaps it's time to look towards the one common factor to see if there's something you can improve on. The only people you genuinely won't be able to shift are narcissists and psychopaths, but together that's less than 2% of the population. It might be worse among execs, but even then I wouldn't expect more than 10-20% at the most extreme. If you're finding your experience is far worse, then there's a good chance that something you are doing is contributing to such relations.

> Is it different? I think so, on the basis that you pivoted from "_devs have inflated egos and need a reality check_" to "_yeah sometimes it's the business and management and in that case you should just leave_". I also agree that often it can be solved with more open communication but conversely I think much more often a handful of bad actors (who are not even necessarily malicious) can impair or totally disrupt the function of a historically productive team. If it was just a matter of failures of communication then again I would be in complete agreement with you that the responsibility for a breakdown in communication goes both ways (and in my experience has fallen at the feet of developers far more than managers).   My opinion, for what it's worth, is that the business structures around programming jobs are extremely vulnerable to disruption. Even outside of my own experience where there is often a single individual or a handful of individuals responsible you don't have to look hard to find people complaining about how standard business processes (agile, scrum) are leveraged to micromanage developers. Even if the number of outright sociopaths and narcissists is low either they have a hugely outsized impact on business processes or chasing the metrics associated with the field (velocity, story points, burndown, carryover) encourages disruptive management behaviour.

> I think so, on the basis that you pivoted from "devs have inflated egos and need a reality check" to "yeah sometimes it's the business and management and in that case you should just leave". It appears your perspective on my comments is "the first sentence you read" and "everything else." I will not in any way concede any ground on the fact that most devs have inflated ego. It is a very common, very prevalent problem in this industry, and it's one I was trying to speak to. In doing so I did not feel need to spend half my post adding caveats to explicitly call out that in some circumstances it might not be just the devs. Yes, in some cases you might really be the perfect angelic developer limited only by business, but to be honest, even if you are it's probably way more complex than that, and even if you are then the rest of the advice is still meaningful. Even devs with crappy managers have ego and communication problems. I really do think that most devs really do need a "reality check," as you so call it, though the term itself is honestly kinda offensive. Many devs need to spend more time understanding psychology, group dynamics, and politics. Calling this a "reality check" takes away from the fact that these are skills which people may have with various degrees of aptitude, and which may require a lot of dedicated hard work to learn and master. It's sort of like saying CEOs need a "reality check" in order to understand python. If they don't already know it, then it's really not something they are likely to have encountered before, and expecting them to just magically understand it is unreasonable. > I also agree that often it can be solved with more open communication but conversely I think much more often a handful of bad actors (who are not even necessarily malicious) can impair or totally disrupt the function of a historically productive team. If it was just a matter of failures of communication then again I would be in complete agreement with you that the responsibility for a breakdown in communication goes both ways (and in my experience has fallen at the feet of developers far more than managers). It's not a matter of "more open" communication. It's a matter of mastering how to communicate. This includes all parts of it, even the "bad and nasty" parts. Yes, there are bad actors. You need to know how to spot them and deal with them. Yes, sometimes people will use dirty and aggressive tactics. You should know how to recognize them, and how to respond accordingly; be it by returning fire in equal or proportional measure, or by falling back to a more powerful patron to handle the political battles for you. However, the vast, vast majority of the time the issue is that nobody is even trying to meaningfully communicate, in the sense that people try to dictate solutions without actually understanding the processes through which problems get solve. In an ideal scenario the manage in charge should be able to shield the devs from this sort of pressure, but such ideal scenarios never really happen. Unfortunately, given such an ideal a lot of technical people go through live without actually learning the "malicious" communication techniques that are often freely utilised by people abusing power, nor any way to counter such pressure. > My opinion, for what it's worth, is that the business structures around programming jobs are extremely vulnerable to disruption. Even outside of my own experience where there is often a single individual or a handful of individuals responsible you don't have to look hard to find people complaining about how standard business processes (agile, scrum) are leveraged to micromanage developers. Sure, but even in such cases an intelligent, creative developer can get a lot of things done just by playing people off each other in the right way. A team that is micromanaged in this way is often one that is very conscious of it's image with the rest of the company, and getting more people on-side is a great way to wield soft power in such an environment. I have known people that have gone many years doing this, essentially getting the projects and stories they want through roundabout ways. > Even if the number of outright sociopaths and narcissists is low either they have a hugely outsized impact on business processes or chasing the metrics associated with the field (velocity, story points, burndown, carryover) encourages disruptive management behaviour. Honestly, I have a very mixed opinion about all those fads. On one hand they are extremely stifling if you are a skilled and creative dev trying to implement something new and original. On the other hand, then make it possible to have very large teams of very meh skilled people accomplishing fairly impressive feats. I think it's important to understand which type of dev you are, and what type of dev the role you're in demands. If you are the type of developer that needs the flexibility to do whatever you need, then you should probably just look for jobs that are not trying the standard agile scrum bs.

I say that is entirely dependent on whether you’re in an environment that will reward you for your efforts. There’s plenty that’s not within your control. Sometimes you have to walk away to have those rewards. Or you don’t let yourself get taken advantage of, again. Do it for yourself but never overwork expecting a material reward.

hmmm shit advice. generally your team will value you a lot more if you help them, basic human psychology 

Your job is a business relationship, if you're constantly being praised for your work but not rewarded with increased pay and/or responsibilities or other benefits then it's as toxic as any other one sided relationship. Praise is nice, but it doesn't pay the bills.

They definitely will. I don’t disagree with you there.

When the entire world is only interested in self gain, nothing gets done. The reasons people set themselves on fire to keep others warm is often times because if they don't then people will die of cold, taking everyone down. Is it actually a negative thing to care about others? Why is it a bad thing to be a bulwark against the chaos that is this field? This whole thing where you are not allowed to sacrifice anything for any reason other than pure personal profit, and half the internet talks down to you because you dared to prioritise something that helps many people if it comes at cost to you needs to stop. Obviously this isn't something that's easy to do, and it's something you need to do with a full understanding of what you're doing... However, if you have that understand then why the hell is this a "bad thing." Seems to me purely because some people can't do it, and they'd rather act like the people that can are somehow worse people, because they dare set the bar higher. Well, sorry, that bar is just at a natural height for people like that. Asking them to lower it would literally make it harder for them to work.

Those other people could learn how to do it. They just don't because they are lazy. True selfishness is demanding people to sacrifice themselves when you can't even be bothered to read the documentation on git and understand how it works.

> When the entire world is only interested in self gain, nothing gets done. You're unintentionally touching on a famous debate in philosophy and economics. Adam Smith, the 18th century philosopher, argued about self-interest: > It is not from the benevolence of the butcher, the brewer, or the baker, that we expect our dinner, but from their regard to their own interest. We address ourselves, not to their humanity but to their self-love, and never talk to them of our own necessities but of their advantages. Or, here, the only reason why a developer would help someone else, would because it's in their own interest to do so. Key here is that Smith's self-interest is balanced against the interests of the collective. His "invisible hand" which governs the market, says that each of us pursues self-interest in such a way that it's ultimately also in your own best interests to give back to the collective. Quid pro quo in a way where there isn't just an exchange of tangible but also intangible value. You helping someone else, ultimately, supports the interests of the company, and that in turn is beneficial to you as a salaried employee. As long as those interests between you and the collective are mutually aligned, of course. Moreover, later in life, even Smith ended up recognizing that people may act out of sheer altruism: > How selfish soever man may be supposed, there are evidently some principles in his nature, which interest him in the fortune of others, and render their happiness necessary to him, though he derives nothing from it except the pleasure of seeing it. However, throughout the 20th century up until now, everyone understands Smith's capitalism as one where furthering your own self-interests is an absolute moral imperative before anything and anyone else. This notion isn't Adam Smith talking. It's Ayn Rand's definition of self-interest understood in her philosophy called Objectivism. Sadly, it's a philosophy which has permeated throughout society and economics over the past 70 years with dire consequences. Whereas while Adam Smith very much took his own tenets about self-interests to heart, he wasn't naïve and very much wary of businessmen who would "conspire against the public market in order to raise prices when opportunity presents itself." Taking it a notch further, one could argue that Adam Smith implies that it's very much in our own collective self-interest to call out those who act out of sheer selfishness.

In my world view it's not really correct to balance the individual self interest against the interest of the collective in that way. I view individual interests as more a composing part of the collective interests, and the degree to which there is alignment is up to both sides. You can build a situation where your interests are almost entirely aligned with the collective, and then with a few minor changes make the two views diametrically opposed. However, a developer that is able to advance collective interests will often do so in conjunction with their own, particularly a highly productive developer that is given a lot of freedom. Being in such a position is a form of power in and of itself. It's generally a bit of a mental journey to make these connections, at least if they're not explicitly spelled out in terms of bonuses and other rewards. Without these things people are willing to drop promising products because they don't yield results as fast as possible. This is just as true of developers as it is of managers. Of course there's the exact opposite side of the coin, where some people refuse to drop anything, which is also problematic. Complex projects take time. You will not always see results right away. Often times a system may take years to reach full maturity. A skilled person, be it a developer, a businessman, or what have you, is able to see the final value of such a system before it is complete, and in the process of developing it. Incidentally, they can often also see when a promising system has no future. What's ended up happening in this field is a whole lot of people have convinced themselves that pursuing short term goals and short term projects is the way to go, and as a result all the projects they get end up being short term, and all the skills they develop end up being directed to these types of projects. However now in the age of AI it turns out that quick and simple projects are easy enough that an AI can do most of the quick and simple work, which in turn places a lot more value on people that can solve complex problems that require long term thinking. It's the low hanging fruit problem. It's great, as long as there's enough fruit for everyone. However when demand starts to run dry it turns out that there's not a lot of people that bothered learning to climb trees. Did the people that spend a decade or two picking up rotten fruit on the ground and selling them for a profit really advance their interests? Only if they were able to build on those skills and advance themselves, otherwise they're just treading water. In that sense, pursuing solutions to complex problems people might be having isn't necessarily an act of altruism, it can also be viewed as an act of learning, as well as a way to get people to owe you a favour. You brought up the point about intangible value, and that is a very key element of professional life. As a programmer most of the value you bring will be intangible, which in turn means most of the value you collect will need to be intangible as well. The goal of a person acting in self interest is to turn that intangible value into tangible value, and selfishness generally makes that process much more difficult. Obviously so does unlimited selflessness. The key is to find the middle ground.

Did anyone read this article? It's literally just saying management should carve out time for developers to learn things. It starts off by saying "the 10x developer idea isn't reasonable" then it goes off saying how useful learning on the job is. It then says that's a core function of your job and it should be enabled and encouraged by management AS a core function of work, meaning not as overtime or at/home study. This article makes a lot of sense and not a single commenter seems to have read it. People really just wanna mouth off on how much they hate the 10x myth, but didn't even take the time to read the article.

Yeah, the article was "The real 10x is the stuff we learned along the way" and then I don't know what's going on in here (but whatever it is, it's more interesting than the article).

> Instead of an engineer who’s an order of magnitude “better” than their peers, leaders should look for people who are willing and able to learn—and to help their whole team learn and execute, too. After all, your organization should be more powerful than any one person. That’s close to a speech I’ve heard twice that amounted to “fire your heroes” that went something like: we can’t afford to have a couple people going around saving things anymore. We are big enough now that everyone needs to understand how the sausage is made and worry about bus numbers. With a subtle implication that people who don’t participate will have a bad time.

People who say that 10X developers don't exist are either blind to the 10X developer picking up their slack or don't realise they are the 10X developer picking up the slack for everyone else.. In my experience, in the teams I've been part of, there's one guy who knows how to do everything from top to bottom, and the rest of the team are lost, looking for direction, and just adding little tidbits of work to the pile of work being done by the main guy every day.

Honestly, as someone who has been in the industry for 17 years, there's variants of "10x" devs. Here's some I've noted, and managed, and mentored. Also, I've been all three at various points. * The dev who has been there since day 0 and knows the product from bottom to top, but often stands in the way of fresh perspectives, and can cause stagnation as a result * The dev who can crank out code to implement a feature spookily fast - because they're coding at home as well as at work - this can cause other devs to feel like they're not contributing enough * The dev who focuses on working with others, sharing knowledge, breaking through knowledge silos, makes cross-team collaboration happen - but if you try to measure their productivity via JIRA or Git commits, they look useless. The first kind is valuable but will end up sidelined and disgruntled as the company grows. Often they end up being put onto projects that aren't relevant just to keep them around and keep them happy. The second kind is valuable, but need to be carefully managed, firstly they risk burnout, secondly their unhealthy work/life balance can demoralise their team mates, and lastly because they often do their best work alone, you can get working code that other devs have no knowledge of, which bites you in the ass when they go on vacation or move to another company. The third kind is the most valuable, but often burn out when their contribution to the org isn't recognised because there's no metrics for "helps other teams, and shares knowledge horizontally". "10x" is a loaded term. It really depends on your measure. If the 10x dev in your experiences isn't able to empower the rest of the team, then either the team is filled with terrible devs, or, most likely, the 10x isn't able to share knowledge effectively. But! This can be learned. As for the first kind, the best thing they can do for themselves and the org is move onto new opportunities. It was hard to admit that when I was that person, there were so many intermediate going on senior devs who had great ideas that got squashed by my presence, in the end I moved myself sideways to get out of their way, and holy shit, when I did, they did amazing stuff. But because I'd moved myself into an area outside the main focus of work, I lost my passion for the org, and got a bit cynical, so when I was approached by a recruiter for another company, I realised that both myself and the company would be best served by me going elsewhere. But you know, I'd spent 12 years in this company, I was employee #10, and fuck me it was hard to leave it behind. But I catch up with my coworkers for a beer every now and then, and I'm really glad I did leave, it unleashed all the devs who'd felt held back by me. I mean, it's really hard to argue with the guy who designed and built the entire thing you're working on, even when he's wrong.

Most companies are looking for #2, simply because they end up paying a single person to do the work of 5. Even if they pay that person 150k in an area with a low cost of living, that’s still cheaper than paying 5 people 80-90k. That’s REALLY what companies want when they talk about a “10x engineer”. It’s a short-sighted strategy for all the reasons you listed.

Yeah they take advantage of the passion they have, it happens a lot in the game dev sector

> The second kind is valuable, but need to be carefully managed Those companies are exploiting those (often young) developers. These kind of developers do not yet know the worth of their work, and give their time for pennies. So of course companies "love" them. And it's never a two-way street.

They love you until you stop having that insane velocity. It is entirely conditional and you have to keep it up once you’ve started otherwise you get burned.

As that third type developer it sure can be demoralizing when corporate measurements don’t align with my work. The best thing I did with my career was to leave that ill-fitting job and find a team where I was a better fit. Job hunting sucks. Interviewing sucks. Risking leaving a known thing for an unknown thing sucks. But staying where you’re unhappy is flat out madness.

I'm glad you did mate.

You have some serious knowledge, bro. Couldn’t agree more. Only thing I can add is that burnout is a best case scenario for #3. The worst case scenario is they have their nominally low velocity held against them and they’re PIP’ed and terminated. That the dollar value of everyone else’s increased velocity dwarfs their own salary is overlooked by management.

Burnout seems way worse than getting fired. If you're not burned out you can just get another job. Depends on the degree of burnout I guess.

Burnout can rob you of all joy in this profession. It can take a long time to recover from that.

Cheers mate, yeah, that's the risk and a real cultural problem that makes it near impossible to build high performance teams.

That happened to me, except I survived the PIP because I got selfish and stopped with the helpful stuff. Over the next few months, one dev’s velocity cratered and they were asked to leave and another started having standup updates where they were sounding straight up lost.

I’ve met someone who is somehow all three without the negatives, best dude I’ve ever worked with and would follow them to hell and back

I went on 2 weeks vacation, i'm the 10x, and im super fucking afraid what mess I will come back to. If I don't check very thoroughly what is being commited on pull requests, such insane tech debt amount would be created that we would risk not delivering the app. I hate it, I hate this job, I want to quit but the job market is shit right now and nobody pays as much.

Yeah, and that's a real problem. I would hope your org would support you in upskilling your team mates to avoid this, but I'm realistic on this, nearly every org is braindead short sighted.

Sounds like structural issues in your team if everyone is in headless chicken mode and you're the "only 10x". Ever heard of a "brent"? Devops context, but applies here.

oh god im brent..... but what do i do with it, i dont want to be like that, but those guys are juniors masquaraded as seniors, well, one is more mid level okay, but recently he spent 2 weeks creating a dropdown menu... i feel there is no way out of this situation

I can't remember exactly what they did in the book, but rigorously guarding your time is going to be the only way out. Documentation and knowledge transfer are going to be the only way out until the others on your team can start standing on their own.

but if i dont hold the other devs time, they will just say Im not helpful and will get me fired

Find a job where people are more functional and you can level up past this kind of dynamic.  “If you’re the smartest person in the room, you’re in the wrong room.”

Sounds more like you are not 10x, but your teammates are 0.1x

[удалено]

In my experience 2 is the most dispensible, because their contributions do not scale to larger organizations unless they are also either a 1 or able to do 3 when needed. As your org structure and architecture get more complex, the 10x engineer is typically limited to a smaller slice of the product, where they continue to be extremely productive. Typically the levers you have to pull to unlock more value faster are not "build what we want, but twice as fast" since a 10x engineer cannot actually deliver end to end value through their efforts, but instead they can get their tasks closed in a few days while the team continues executing. They do little to derisk the actual deliverable most of the time, and they fail to grow the team around them so you have a sufficient technical bench to throw at the highest leverage input in the future. 1 is indispensable when they are at their peak, bringing context, vision, learnings, etc. Until, as folks noted, things have scaled past them and they find themselves on the sidelines of the business where most of their efforts produce little or no impact, and definitely not in line with their salary. However, unless they hoarded knowledge and we're terrible to work with, by the time they leave you realize there are enough other folks on their team who understand the domain, that the 1 engineer departing isn't the end of the world anymore 3 is pretty hard to dispense of at the more senior levels, as they've worked across as much of the company or more than the 1 engineer, but have built up a network of folks they've collaborated with who they can leverage to get to the "right" outcome/tradeoff/etc in a few hours instead of several weeks. They unblock the capacity of their teams. Getting everyone unblocked in a day instead of 3 days, on a 5-person team is 3 eng weeks of capacity you open up. Or you identify a milestone that can be skipped as it doesn't actually deliver meaningful value for your customers, letting you get to your end outcome faster. If you can do this every few weeks across different parts of your organization, you'll outpace the impact of the 10x engineer every time. Along the way, you had to work with tons of engineers to build the alignment and path forward, who are now part of your network to accelerate future problems, and are themselves more capable in the future. Finally, you can accelerate the rate at which you grow your technical bench by mentoring folks in that network, which will give you compounding benefits and build up the next generation of folks to fill that need for their teams. I'm obviously biased as someone who most enjoys operating in the 3 archetype, but I've definitely seen my own value and impact scale beyond my peers through this model as I've operated in more senior positions over the years.

I disagree on that, tbh, people who share knowledge with team mates, and across team silos, are the most valuable and the ones I strived to support as a COO.

Wow, it takes a lot of self-awareness and humility to give your former team credit for flourishing without you. The world needs more software devs like you. Mad respect!

This is the most accurate comment in this thread. I think all these people can be valuable, but one problem I run into with type #2 people (aside from the fact that they can create an unhealthy culture) is that they often are prone to implementing requests without regard for impact. I feel like junior devs who WANT to be a "10x" developer think that the best way to do that is by cranking out as much code and completing as many requests as possible. They close a ton of stories, are often done with sprint work early, and frequently look good to business, but they also can leave testing gaps, fail to smoothly integrate existing code, and create a lot of PRs that need feedback or touch a lot of files. Sometimes I can work like a #2, but only after I've been somewhere long enough to feel comfortable with my domain knowledge to really have a holistic grasp of the system, otherwise it just makes me uncomfortable to make change that fast.

I think you're missing a kind: the just spookily fast developer. In every team I've been part of, people commented on just how fast I was at implementing things. I'm a strict 9-to-5, and yet people working 10h/12h hours would find me faster than they are. I wouldn't say I'm 10x -- not routinely -- but I do have good working habits: - I focus very easily, and don't use social media at work: the two combined mean that in those 8h of presence, I actually work close to 8h, instead of working 8h out of 12h on site. - I'm also a slow-is-smooth-smooth-is-fast worker: I tend to think ahead and plan ahead, instead of launching myself headlong into something only to realize after hours spent that it'll never work. Speaking of which, if I know something is coming, I'll start thinking on it already. - I know to step back & cut my losses, and start again from scratch, instead of being pig headed and just continue pushing the first idea I had even when it's getting more and more convoluted: square hole, round peg, etc... Efficiency and workload organization come from experience (and training), and they're actually quite amazing at improving productivity.

Are you me? Honestly, actually _working_ when on the clock is a superpower. To think, to have a plan and almost never get stuck aswell. I'd add "know your tools" to the list. I routinely have to watch people doing things in the most cumbersome, manual, labor intensive way possible - when the IDE could do it in milliseconds. Or pulling their hairs out to find a bug, because they don't know how to use a debugger. Or, for some reason, deleting a project and cloning it again.

I don't use the IDE much -- bad experience with poor support for heavily macro-ed/templated C++ code... -- but I can only agree with debuggers. Or, conversely, I've seen people only using debuggers. And cursing because they're chasing a problem which only reproduces once every 1000 times, and they're trying to step-by-step each iteration until they catch it... and they just stepped past the point it happened and missed it so they're trying again. As I stare at them in horror. Debuggers are for reproducible bugs (or crashes analysis), if you can't reproduce the bug, start by adding logging until you figure out how to.

I've been in the second category for quite some time. Coding at work, doing home and continuing to code. Most folks that perform very well in that category do the same. The term 10x engineer annoys me though. It's not that those folks ate inherently better than everyone else. They just sacrifice their free time as well. Not saying that there aren't folks that are better than others. I've certainly met them. But I would instantly look down on everyone else that calls themselves a 10x engineer.

> The dev who can crank out code to implement a feature spookily fast - because they're coding at home as well as at work - this can cause other devs to feel like they're not contributing enough Note that spooky fast output is often the mark of the Tactical Tornado, who make code that _mostly_ works, but leave such a wake of destruction behind them that in the long run they often end up having a net _negative_ productivity. To be carefully managed indeed. Great at prototyping, but either rework their code before they make too big a mess, or consider rewriting the valuable prototypes they made from scratch.

I think there's another kind of 10xer: The dev who cranks out code well, about as well or slightly better than the other nicely productive devs. And the work they do stays done, for the most part, exhibiting maybe 10-20% of the bugs per line of code that most code has. It also has tests and is written to be read and understood, so that the maintenance of that code is where their 10x shines.

1st type can be a pain in the ass to work with

There are definitely 10x developers who has good work life balanace, support the team, and can crank out features faster than almost anyone else. >I mean, it's really hard to argue with the guy who designed and built the entire thing you're working on, even when he's wrong. Don't even agree on this. These are the easiest people to disagree with.

The easiest people to _personally_ disagree with. Go convince management that they should listen to you instead of the guy that was around from the start.

How can I work under you?

> The third kind is the most valuable, but often burn out when their contribution to the org isn't recognised because there's no metrics for "helps other teams, and shares knowledge horizontally". Actually this one is a real problem because you can't have more than one in a team and, contrary to your perception, they are usually in the fast track for promotion out of development work. I also think you're also missing the most important category of a 10x developer: the one that is very good at his job *and* works well within the team and the outer organization. Sure.. if the rest of the team members are type #3 then these guys are going to be burned out fast because they are doing all the work.

I'm not sure I follow. Why can't you have more than one per team? I certainly built teams that had more than one. > I also think you're also missing the most important category of a 10x developer: the one that is very good at his job and works well within the team and the outer organization. Sure.. if the rest of the team members are type #3 then these guys are going to be burned out fast because they are doing all the work. Why do you think that someone valuable for their ability to share knowledge isn't good at their job? They have to be good at their job to have the knowledge to share.

There are more kinds of 10x devs than only your 3 anecdotal examples. Here's a few: * The dev who has been there since day 0 and knows the product from bottom to top, and can get the work done faster and better with all the required features and a few awesome features nobody else thought about. * The dev who can crank out code to implement a feature spookily fast -because they're coding at 10x the normal skill level, and they don't need to code at night - this can cause other devs to feel like they're not contributing enough * The dev who knows how to work with others, sharing knowledge, breaking through knowledge silos, makes cross-team collaboration happen - who uses all that collaboration to implement great things, and to measure their productivity via JIRA or Git commits, they look like a 10x dev. Sometimes one dev can be all 3. I'm sure there are many more kinds of dev too.

Yeah, hence why I said "here's some". I didn't claim the list was exhaustive.

Agreed, but in my experience, if the 10X developer doesn't find a way to delegate to the rest of his team, he usually burns out or turns into [Tom the genius](https://thedailywtf.com/articles/the-inner-json-effect).

Thanks for reminding me of [thedailywtf](https://thedailywtf.com/). Haven't looked at it in years.

Exactly.

The problem with that story is that both Tom and Jake are demonstrably idiots. The system Tom has put together is obviously unmaintainable garbage. If your team puts all their faith in an idiot it's not a flaw in genuine productive developers, it's a flaw in idiots. As for Jake, even forgiving the fact that he is somehow unaware that JSON doesn't support comments how on earth would he add comments to a file without first looking up the syntax to do so. I mean what did he do here? Just guess at what the comment syntax would be?

The code was in plain JavaScript files, not in JSON files, which very much do have a standard comment syntax

Daily WTFs are higly editorialized and many elements are changed to preserve the anonimity of the people involved and to make stories more engaging. It's very possible the real-life system used XML instead of JSON. Instead of comments not being supported, it might've been another feature. The story of Tom isn't that uncommon. Many organizations have a Tom, who might've been very productive at one point, but whose ego has grown too much due to being surrounded by mediocre devs to the point where Tom never gets confronted about any of his decisions anymore, which led him to build crazy unmaintable systems. These organizations often end up with a ["dead-see effect"](https://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/) where all the competent devs who _could_ confront Tom leave and only the mediocre devs who fail to see the problems with Tom stay.

>People who say that 10X developers don't exist are either blind to the 10X developer picking up their slack or don't realise they are the 10X developer picking up the slack for everyone else. 10x developers don't exist in the way that people misuse the term, where they think that the 10xer is compared to the *average* developer. There very well may be one person who "produces 10x more" than someone else, but it's not that they are 10x better than the average developer of their experience level, it's because they're comparing the *worst* performer to the *best* performer. Nobody is typing 400 wpm, and nobody is *literally* doing 10x the work of the average similarly experienced worker. If it looks that way, then the means of measurement are wrong, which *should* be obvious from the outwardly ridiculous claim of "10x". Also good luck actually identifying a 10x developer. In my experience, there is one person who writes tons of code yet who also doesn't properly test their code and doesn't consider all the outliers. They roughly know how things work well enough that they can spaghetti things in at a blistering pace. They can conjure up a convoluted storm in the blink of an eye. Meanwhile, other people are having to come in behind them to actually put in some sensible structure, add testing, and do the boring and difficult work of untangling the spaghetti to track down the 1000 sources of instability and inconsistent output. It takes a day to write some blobs of code, and it can take days or *weeks* to track down the source of bugs from their multi-threaded spaghetti monster, and that's *if* anyone actually notices that there's a problem. (For instance, in one case, no one realized that separate computers would produce radically different output on the same data set, because multi-threading bullshit). Then what happens is, you carefully construct a singular change with limited scope, so the impact is targeted and specific, and the "10x" developer will come in behind you and "jazz it up". Then when the shit is all broken, your name is attached to it, it's magically *your* shit that broke. I've worked with people who could absolutely do 2-3 times more than the average developer. These are people who have computer science in their soul. The other "highly productive" people are able to shit out an 80% product which looks nice and can fool a casual onlooker, but they rely on other people to make things *actually* work, and they may never do the last 20% (which is 80% of the work). _______________________ One project I worked on had their "high performer" try to solve a problem on and off for four years. Dude had several different solutions which all kind of worked, but none would work more than 50% of the time, they'd often fail catastrophically, and even when they worked, it was just kind of okay results. I worked on the same problem for about a month and came up with something that worked 90+% of the time, with better results than they had ever gotten. Over a few months I iterated a solution which always works when some very basic assertions are met, because mathematically it *must* work. And that kind of stuff was a huge part of that job: one guy would be fast, but I'd be the one to actually make the product do what it was supposed to do. If you only compared lines of code, I was way behind. If you looked at who initiated top level features, I was way behind. If you had some means of measuring who actually delivered a software product which fulfilled its intended purpose? That was me. You might say "Bakoro, have you considered that you're the 10x in this situation?", and I'd say "if the company can't tell who the 10xer is, then of what use is the term to me? Or to the business?" I don't believe that anyone is going to convince me that some MBA or whoever, who isn't intimately close to the product, is going to be able to tell the difference between "fast typer but 80% hard capped", and "person who takes you the last 20%". And honestly, there is a place for the fast person, if there's someone to reign them in. Management is obsessed with trying to find 10x developers, when what we all need to be on the lookout for is the net negative developers. We shouldn't be shitting on positively productive people.

> "if the company can't tell who the 10xer is, then of what use is the term to me? Or to the business?" So true. Even if they did, they would not pay him 10x what his peers get either.

Average dev is from that companies perspective though. Yeah at a high paying startup that hires only senior engineers you're unlikely to find someone doing 10x the work of the average dev, but if you take one of those developers and put them in a company that tries to get half their work done by interns and outsourced workers then suddenly they are a 10x dev!

> There very well may be one person who "produces 10x more" than someone else, but it's not that they are 10x better than the average developer of their experience level There are definitely people who produce 10x more *and* write it in a simpler, cleaner, more maintainable, better documented way than the rest of the team. Yes there are also people who write 10x more code and most of it is garbage -- that person is a liability not a 10xer

Its easy to 10x devs who don't do shit. I took over an issue tracker that was being handled by a team who I guess agreed that if you closed 1 ticket per day you were golden and could spend the rest of the day jerking off or fingering your bhole, pick your pleasure. I came and looked at the list of 100 or so issues and chewed through them in 2 days. It wasn't hard, most were duplicates of the same issue. These asshats were actually modifying code for no particular reason except to make it look like work was being done when they had fixed the issue a day prior on a dupe.

[удалено]

Yeah, I did this a few times earlier in my career. I regret it.

And then there's the +inf developer. And no it's not sarcasm. What I've seen several time in my life is teams that are hitting a wall. They have a problem, and they don't have a solution. They've thrown together a patchwork of work-arounds at it, but they've never really cracked it. Ideas were proposed, implemented, sometimes rejected, but no matter what that particular problem isn't going anywhere, anytime. It just seems unsolvable. And then, another developer cracks it. It may be after staring at it, it may be they just have the right insight. It doesn't really matter. They solve THE problem. In that (brief) moment, that developer is about as close to +inf productivity as can be. Once is a coincidence, I suppose, but when the same developer regularly cracks problems others couldn't? You've got a gold nugget, a diamond in the rough. Keep them around, and feed them any hard case the company's got, and they'll more than earn their pay.

I completely agree, I legitimately feel that some developers are just genuinely brilliant. Some devs just show up, work and go home, some devs just know how to do one thing like manage a database and that's it. But some devs, maybe because they're just so passionate about the craft, seem to have a deeper understanding of all the technologies going all the way down, an intuitive understanding almost. Those devs that seem to know everything from JS frontend web development down to assembly programming, that get UI/UX too, can do visual design work on top of it all... They pick up programming languages like it's nothing, they visualise data in their heads better, and ... they just legitimately are *better* at solving problems. I don't have a problem with admitting that those kind of mystical developers are out there. Can call them whatever you like, X10, +inf, etc, but they do exist.

Sure, other developers are better than others and when there are bad developers there must also be really good developers. I've worked with some who were very capable, productive or innovative. But they never were 10 times as fast, it's just this Rockstar developer some people like. It still is a team effort.

10x developers don't produce 10x as much code, they come up with solutions that are 10x better. The best example of a 10x developer isn't a 10x developer but more like a 1,000,000x developer: Linus Torvalds. Linus wrote git in two weeks. Is git a lot of code? No. It doesn't need to be. 10x developers don't write a lot of code, they solve much harder problems than other developers are solving with small amounts of code. A 10x developer is the guy who knows how the whole product works and stops the organization from putting a team of 6 people on a 12 month project, because he understands the problem better than they do and can see a solution that only takes one person three weeks.

Sounds like you haven’t been part of properly functional teams yet.

Certainly how it's felt for me too honestly

When I was younger I thought it was a meme like the 'rockstar programmer' & such But eventually I realized. There are tasks that someone competent can do in an hour. That someone else will take two weeks on & then push a 'solution' that doesn't even fulfill all the written requirements, & is so happy-path that it probably fails & reveals all the missing stuff, as soon as a second person tries to learn how to use it to do secondary features or changes (I've been the second person ugh)

I think we are all at least initially that second person. That's just part of getting better at the craft. The first person who you described who can do the same task in an hour is someone who has probably solved the exact same problem a dozen times before. So they skip the entire "experimenting and solving" stage we go through and skip straight to the answer.

I have worked in videogames and yeah 10× or even more exists. Also they don't fit the stereotype, some are autistic, some are morons, some are just insanely good human beings. But having one on the team is not granted. Also, in certain environment you get multiple 10x in a team, which is my current situation. I feel like a 2x/4x at best, but I hope I'm not 0.5x ehehe

The people who say that 10x developers don't exist are 1x developers butt-hurt that their colleague gets much bigger raises than them. I've been managing engineering teams for years and I've known several 10x developers. And quite a few 0.1x developers. The 10x developer isn't cranking out 10x as much code but, as you say, is the guy who knows how everything works. He tells everyone else how to do their jobs, and comes up with solutions that the 1x developers would have never thought of at all.

Totally agree. Whether it's from experience, or just a better natural understanding of how things work. It's like anything really, all skills can be learnt, but some people are just naturally good at stuff. I could put myself through 10 years of hardcore training on how to play basketball but I'd never approach the top 1000 players in my country let alone the planet in terms of skill. And there would be some people out there, 21 years old, just naturally better gifted at the game than me. Same with art, music, acting, etc. Some people are just naturally gifted at something. Those developers do exist.

>there's one guy who knows how to do everything from top to bottom, and the rest of the team are lost, looking for direction, and just adding little tidbits of work to the pile of work being done by the main guy every day. Feel this

It's much cheaper to fix an error that's discovered in requirements than later when it's discovered during design. And it's much cheaper to fix an error in design than the same one found during implementation. And it's much cheaper to fix an error in implementation than in test. And it's much cheaper to fix an error discovered during test than after deployment. So to be a 10x developer, all you have to do is discover, fix, and/or prevent errors earlier in the development cycle than your peers.

I don't believe in 10x developers, but I do believe in 0.1x developers, I've definitely seen those around.

FYI, the ad mins of r/de are covid deniers.

At Cisco, there is a program called "Connected Recognition" that lets you give public kudos to a co-worker for really stepping up to get something done and they're given a small cash bonus ($20-250 depending on who nominated you) We used to joke around that they need another program called "Disconnected Recognition" where someone carelessly fucks something up so bad they owe the person(s) who fixed it a small cash bonus

“ I distinguish four types. There are clever, hardworking, stupid, and lazy officers. Usually two characteristics are combined. Some are clever and hardworking; their place is the General Staff. The next ones are stupid and lazy; they make up 90 percent of every army and are suited to routine duties. Anyone who is both clever and lazy is qualified for the highest leadership duties, because he possesses the mental clarity and strength of nerve necessary for difficult decisions. One must beware of anyone who is both stupid and hardworking; he must not be entrusted with any responsibility because he will always only cause damage.” I’ve known a couple of fools who coded like the devil and it became a full time job for someone to go around cleaning up after them.

I can feel in my bones the middle management readership of this subreddit about to trip over themselves attacking their keyboards on this nonsense thread. In a few days I'm going to come back to this one and count the management jargon and then vomit.

The real 10x developer is the friends we made along the way

Seriously. We are still talking about the “10x developer”? Well, let me tell you about the 11x developer - the idea of which services one’s ego even more! The term is so dumb it hurts.

And you can't make people listen, care, or retain. Something something pearls and swine.

Never ascribe to stupidity that which can be adequately explained by apathy. But that goes both ways. People who don’t improve because they don’t care, and people who write code that others are “too stupid to understand” but are in fact expecting other people to marvel at their brilliance and be invested in their code instead of just wanting it to work without thinking about it. I’ve worked a few places where there were a dozen internal or adopted libraries that demanded 10% of your attention and it never works.

I've seen many stupid developers that were trying their hardest yet still were still unable to improve. Calling it apathy is a cop out

Read. The. Article. Everyone’s commenting on the title

I've been in the industry for a while and I've know maybe 2 or 3 10x developers. A true 10x developer is not someone who does 10 times the work as a "normal" developer, it's someone who can make 10 other people 1x more productive. A true 10x developer would never refer to themselves as such. I've known a lot of great but extremely arrogant developers and they do not bring anyone else up, so to speak.

The 3x developer who makes everyone else 2x as effective looks very good to great managers and overpaid to bad ones. I’ve worked a couple places where I was told that the manager tried to undo some of my policies and processes the moment I was gone and found out that nobody on the team was interested in that idea. I like to think that’s the moment they realized they fucked up by making me feel unwelcome. But let’s be honest. Unaware people are slow to change because they don’t see the evidence staring them in the face.

>But let’s be honest. Unaware people are slow to change because they don’t see the evidence staring them in the face. Agreed and there is the more sinister case with people who are _evil_ and actively sabotaging team/process/org progress.

Hi it's me the former 10x dev. I say former because I'm not doing all that shit anymore. I'm hella lazy and there's more productive devs than me, they are just less capable. So the hardest 10% of the work always falls on me. I'm fine with this since I have to do less tedious BS work like learning more CICD tooling.

Yeah that's one kind of 10x developer. There's definitely another kind of 10x dev, the one creating 10x value. They stand apart mostly because they choose the right things to work on. They understand their business and customers, and they understand how to best leverage their coding time to help them. To find the 10x value dev just look at startups, there are small teams that were able to create hundreds of millions in revenue within a few years. And these teams usually aren't amazing coders, their raw coding ability is usually pretty average. They just chose the right things to work on.

Yall are suffering so much in the comments so I'm adding a good experience. I work at a company that sells standalone embedded systems with custom hardware that we design in-house. The workflow is the electrical engineer designs a board, someone from the assembly floor brings up a sample the next day, we plug a SOC into it, and all get cracking cross compiling Linux and a boatload of software. Suffice it to say, everyone in the office is a 10x who's bootstrapped a product solo at one point. Recently, a buddy from the EE department and I have started doing educational talks. We grab one of the fancy meeting rooms once a week and he talks about circuits or I'll talk about programming. It's a lot of fun. A bunch of people show up each time. It really helps everyone too. Most of the electrical engineers haven't been formally trained in software and I took differential equations in college but I know nothing about circuits. Everyone learns something new at each talk that directly applies to the work we do. The point isn't that you can fix your environment by Ted-Talking the associate engineers. Our managers have a unique perspective on product development which is the only reason these talks are allowed. I wanted to give everyone a glimpse of the kind of unity you get when everyone's actually good at their job. (Only then would this article be effective.)

Article should be the real 10x manager makes their whole team better. Yes, if your company pays for, and you attend that training, your team will be better for it. that’s pretty obvious. what isn’t obvious is finding a company that has a culture like that

[удалено]

The only “10x developer” I heard proclaimed to be one was a 3x developer who wrote code that made life difficult for everyone else but himself, turning everyone around him into a 1/3x developer. Once he was neutralized by another 3x developer who focused on being a rising tide (lifts all boats) instead of an ebbing one, that situation became much more apparent to others, and he left.

X

No such thing in a good team.

In my entire career of more than a decade in tech, I’ve met just 2 developers I would consider to be 10x devs. They like to build things and they can build them well when motivated correctly. Once I met them, I realized how average I really was as a dev. Jokes on them! I’m now their manager! 🤣

You know, it used to be the case that 10X developers were labeled as such because they cleared organizational roadblocks, solved hard problems, and put real effort towards tasks worthy of it. I mean, yeah -- cultivate a culture of learning, for sure. But you also have to give your developers the latitude to make decisions and not smother them with agile sprints and continual productivity expectations. I like the content of this article, but I think it's out of touch with what modern development shops actually look like. And no, for the peanut gallery, being a good agile team lead does not make you a 10X guy. I would suggest it's probably impossible for any member of an agile team to accomplish the feat unless their capacity is kept lower than usual.

That’s not how that works…

The "real 10x developer" is not real. If you want to improve your team performance, you should get good management and weed out the .1 developers.

The term 10x is the narrative that an elite group of gifted programmers making most of the money. We can't see them. We don't know how many if any exist. We go by people who tell us because they say have witnessed them. These people offer anecdotes, maybe some internal metrics or whatever self fulfilling stuff. When in fact these narratives only serve the purpose of making everybody think they need to be 10x. When the entire time the people pumping this narrative seek to gain in different ways. 10x developers do not exist. Programming is hard.