[0xB31B1B]

I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B players hire C players etc. Building a team from the ground up is very much an iterative process of fighting complacency and mediocrity all day every day, and this guys pitch is just "give in, its not so bad".

[gilbetron]

In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 10x programmer, but only if you ignore everyone else on the team that allows the QB to shine. Same with software. Software is a team sport, and if you don't get that, you should get that.

[Dracophoenix]

> but great teams makes great software, not great individuals.

For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals along with the contributions of a small number of itinerant volunteers. While teamwork can be an important if fickle instrument, it tends to be a lightning rod for inviting too many cooks into the kitchen. What is often downplayed or goes unsaid in these commendations of teamwork is the place of an individual mind as the wellspring, the sine qua non, of great ideas and projects, including software. As is often the case, one person can solve an issue that has stumped thousands of others. Such individuals tend to work at a faster pace alone than the de facto committees that teams often become as they lose their agility, foresight, and focus. Unlike a football team, coding doesn't require a minimum number of people to achieve greatness. On the contrary, the opposite appears to be true - that there's a Dunbar's number for doing good work.

[matthewmacleod]

This example proves the exact opposite of the point you intended to make.

[Dracophoenix]

In what way?

[gilbetron]

https://openssl-library.org/post/2018-12-20-20years/

OpenSSL was made by a team, just read the history.

[Dracophoenix]

As per your own source:

> For the first 15 years, OpenSSL membership was mostly a small collection of individuals working on a part time basis and the membership fluctuated and changed through those years.

I never claimed OpenSSL was the product of a lone wolf or that teams have no place in coding. The essence of my point is that the invocation of "teamwork", often as a concept and practice distinct from the sum of its parts, obscures the significance of individual contributors who making great software. After all, code is a mirror of the mind. That one can distinguish between great and not-so-great code implies that one can distinguish between a great and not-so-great coder.

[Nathanba]

that's a bad analogy because a single football player cannot ever deliver a match entirely on his own. A single developer can absolutely deliver a full product on his own, it's not inherently a team sport whatsoever. You could make this claim about many things, "blacksmithing is a team sport!" Nonsense.

[swatcoder]

While a single talented developer can conceptually complete a whole project (of some kind) on their own, the concrete reality is that they're often being tasked to do so in the context of some time and resource bounded opportunity.

There's only so much code they write per unit time, only so many designs they can consider, only so many meetings they can attend, only so many demonstrations they can perform, only so many regressions they can debug, and really, only so many domains they can master.

Solo projects written by excellent engineers can be stunning works of craft. Many of us prefer to work that way, and accept the compromises of scale or time that are associated with it.

But most projects that you're familiar with need a team to produce them in a way that meets their real-world time and resource requirements. That's where the sports analogy comes in.

(And the same is true for the blacksmith and tailor. One master blacksmith or tailor might do stunning work, but they can't outfit and army or dress a court ball on their own. They need support, and that support often needs to be of a different level of mastery than themselves, if for no reason but to facilitate needed coordination and deference.)

[Nathanba]

Nobody is seriously claiming that all work on earth can be done by individuals. Obviously the master blacksmith that designs and leads the outfitting of the entire king's army with superior weaponry thanks to his personal leadership and expertise and care ... is not hammering every sword himself. But to call it a team sport is also highly misleading and to say that he hasn't been x10 is also just flat out wrong.

[antupis]

I think it is more like an NBA situation where a single superstar player can pull up the whole team just look Nuggets but still most likely thing is that the Cavs, Boston, or OCK wins the championship because those teams have a superstar player + a great team.

[handwarmers]

The big question is, can we find counterexamples to your model of reality in actual reality. And if we can easily do that, what does your apparent over-confidence about your statement say about you?

E.g. https://bellard.org/

To add to the insult, I'd challenge you to think of how many "great teams" of "normal" engineers, whatever any of these terms means, could pull off most of these projects in any amount of time.

Great professionals exist. They produce great work that is tough to reproduce. Your "helping" them does not mean they couldn't have done it without you.

[alienthrowaway]

Fabrice Bellard is not a counterexample you think he is. He is brilliant, but he doesn't stick around the projects he starts off. Someone has to triage bugs, setup CI, tag releases, keep the website running and all the other boring stuff.

I have contributed to one of the projects he originally authored, and my mundane contributions along with other volunteers not as brilliant as him have ensured the continued success of the project. I'm with gp: teams ship software, not individuals. Individuals may ship bug-fixes or largish features, but for software in the large, that is the realm of teams.

I've been there & done that: I've been the person that crunches and turns around impossible situations, and I have also spent months cleaning up after a 10x engineer who shipped a feature in "record time" that made the company lots of money but caused countless support calls and bugfixes for months on end until it stabilized. Many so-called 10x aren't, and rely a lot on a supporting cast of regulars to enable their "outstanding" work

[handwarmers]

My main frustration with the person I was responding to is that a lot of the terms we are arguing about are ill-defined, and yet he's arguing them with a lot of vigor.

There is also a time dimension to software. I have been on some occasions the only developer of pieces software that were tackling hairy problems that teams of "normal" developers would avoid. I always wanted to solve those problems in a way that would make everyone's life easier. To do that I had to spend a ton of deep focus time on modeling the problems effectively, and if I was successful, people who were put off by the problem space would come and contribute, because they found the model amenable. Or they thought it'd benefit them to be a part of a project that's picking up steam. A lot of these people would fix small issues here and there, but some of them actually donated a lot of focus and helped take these projects to new levels. The ones making the deep changes always cared deeply about the problem space, or brought a lot of knowledge from another subset of cs, and I wouldn't call them "normal". I think it is a disservice to the sacrifices they made to do what nobody else felt like doing and throw a blanket statement like "teams of mundane contributors do the really important work".

This is not a dig at "normal" devs - I have been the "normal" dev on many projects, but because of my experiences I try to give credit where credit is due.

I also detest the 10x thing exactly for the reasons you pointed out.

[0xB31B1B]

Great teams are made of great individuals. All of the policies and trust and rituals and expectations are based on the performance of the bottom quintile of the team. If the bottom quintile of the team is still the top quintile of "engineers applicable to this problem" you will have a radically different and improved culture and performance than if the bottom quintile of the team is a median engineer, and especially a bottom quintile of "engineers applicable to solving this problem".

[jjk166]

A great quarterback with an otherwise average team is still going to beat an average quarterback with an otherwise average team every time. That a team is more than the sum of its parts just means that adding great team members can lead to more overall gain than their skill alone would imply as they boost those around them.

[__loam]

Even in the examples he gives, I'm sure Linus would be the first to admit that Linux has a lot of maintainers that have been essential for the project.

[c_e]

> Nearly all complex technical projects are owned by one super smart person (Ex: linux).

strange example, considering that the super-smart owner is purely a delegator at this point, and there are thousands of contributors.

[throwaway2037]

Yeah, the OP is utterly delusional. Linus himself has said that he spends most of his day merging patches. Each subsystem, example: file system or USB, has multiple highly skilled owners/gate-keepers. I am sure that the file system gurus know far more about it than Linus does, and I say that with no disrespect to Linus.

[swatcoder]

There's truth to what you're saying, but just as in sports teams, you ultimately need a certain number of players to play the game and exceptional people characteristically have an ego that only allows so many of them in the locker room. If you have too many, they get starved for the individual recognition and validation they're used to receiving, leading to crises and clashes and quittings.

Unless your project's scale is reasonably small and focused -- representing the equivalent of a true solo or duo sport like tennis -- you need committed, professional "normal" team members to flesh out the team or you'll just never have enough resources to get done everything that needs to get done.

[0xB31B1B]

Comforting yet false assertions. Great engineers tire of working with “normal” engineers, they want to work with others who they respect. A team of only great engineers can have a completely different culture than a team of “normal engineers”. Teams of great engineers are magnets that attract others. Building a great team weirdly does not become harder over time, as your project is derisked you get access to larger and larger pools of talent. Talent concentration pays an enormous dividend and is a worthy investment. Maybe things change when you hit like Facebook/google scale, but at that point… we’ve won anyway, wouldn’t be arguing online anymore.

[hot_gril]

Even before you hit big scale, there's a lot of boring work that great engineers won't want to do. And what really makes someone a great engineer is the ability to transform a hard problem to something regular engineers can handle the rest of. So I agree that 10x engineers are real and it's often 2 out of 12, but all-star teams don't work, which is why those people often get moved to run new teams/projects instead.

[0xB31B1B]

The reason people aren't motivated to do boring work is because of a poor culture of ownership, it has nothing to do with skill or "10x" stuff. Having a team of only great people allows a much deeper culture of ownership and its much easier to get people to work on the boring stuff. Allstar teams absolutely work and are the best way to work.

[johnnyanmac]

Uhh, I think it's becsuse boring stuff is boring. If you start to do repetitive plumbing aren't much "greater" than the ones working assembly lines, no?

People who describe themselves as "great" feel such work is beneath one and know there's only so many hours on earth. Easier to pay a grunt to do that instead. And hence power dynamics are established.

That ego alone is why a team of only "great" engineers is bound to fail. You have a bunch of strong but negative polarity magnets trying to stick together. It simply won't be allowed.

[noisy_boy]

Every team doesn't need to have "great" engineers; I don't want "clever" solutions to my bog standard business application, just people to write sane, clean and maintainable code.

[0xB31B1B]

This might be a definitions issue, but my assertion is not that a "great engineer" is someone who can complete leetcode hards in 15 minutes for 8 hours in a row without stopping. My assertion is that about 1 in 5 people have 5-10x the business impact of the median software developer, and if you are recruiting or managing a team you should have the goal of having your team be entirely composed of these top quintile folks. The article specifically says that you should not have this goal, and I extremely strongly disagree with that assertion in the article.

[alienthrowaway]

Some years ago, Google published a paper whose conclusion was that high-trust teams were the most productive - not the ones with the 10x developers. This obsession with the "great man" theory as applies to software is harmful to software engineering.

[johnnyanmac]

Computers are all about synergy and understanding the hardware you're working with. No one algorithm will work optimally on every chip. One of the harder problems is in. Fact getting optimal hardware use by coordinating multiple threads, chips, or entire clusters to work on the same problem together.

It's a shame some can't apply such metaphors tk humans and think "no, sure, there are single processors thst outperform entire distributed networks" we're different".

[jjk166]

You don't need a former fighter jet pilot to fly an airliner, but a former fighter jet pilot would probably do a very good job flying an airliner.

The guy who can roll his own probably also has a better idea than most what easy off the shelf solutions are out there.

[interludead]

A great engineer isn't the one writing the most "brilliant" code; it's the one who understands the problem, picks the simplest solution that works, and makes life easier for the next person who touches it.

[tremon]

In my experience, the person you're describing is hardly ever the one perceived as having "5-10x business impact". Specifically, "making life easier for the next person who touches it" is unproductive use of company time.

Which is why I have learned to stay away from people who use that metric.

[redserk]

Yeah, “business impact” is measured entirely on a short-term basis.

In 3-4 years when you need to make a drastic change, that’s when the actual business impact comes into play, but this is never measured.

In my experience with some groups, waiting another 2-3 months to do things correctly would have saved years in future work.

[thi2]

> Comforting yet false assertions. Great engineers tire of working with “normal” engineers, they want to work with others who they respect

What a great environment to train juniors. Does not sound toxic at all.

[Seb-C]

There are great and normal juniors as well.

Junior does not mean incompetent, it means unexperienced.

[systemf_omega]

Wanting to work with ambitious people that match your level is not toxic.

[BigJono]

No, what's toxic is building an environment like 99% of companies where juniors are told that everybody is the same and there's no point doing anything other than copy pasting whatever dogshit the "senior" next to them is typing into VSCode.

[TrackerFF]

Have you ever worked on large projects? I'm talking about projects which involve hundreds of people, thousands even, and those that stretch over many years.

In the grand scheme of things, the 10x-100x engineers work gets attenuated - think of it as some kind of averaging filter.

Do you think some 10x engineer carried the moon landing? or the Large Hadron Collider?

Sure, if you work on some dinky team single-digit number of workers, the contribution from the 10x engineer will be more apparent - but as the number of people involved increases, the more important the average is.

[silvestrov]

10x is not about the number of lines produced.

It is about programming languages and tools, about database design/schemas.

Choose the wrong language/tool for the job and the amount of work needed to solve the job easily expands 10x.

Guido van Rossum and James Gosling and Anders Hejlsberg likely have reduced the amount of work by 10x for a lot of projects compared to implementing them in a lower level programming language.

[TrackerFF]

10x is not literal - the origins is from the 60s, and stem from some study where the best engineer was found to be 10x more productive than the worst engineer.

Average, is of course relative to the sample. If some "elite" company only hires 10x engineers, there's likely not going to be any 10x engineers there. The most productive engineer will probably only be slightly more productive than the worst.

If some other company has zero standards for hiring, to a degree where you can basically pick anyone off the streets and put them to code, the best will probably Nx (where N is very large) more productive than the worst.

But even then, there are so many dimensions and aspects to this.

[whatnow37373]

Being 10x as productive then has more to do with your position than your skills.

The Roman emperor could make or break entire regions by vaguely wagging a few fingers. If and when he made a good decision - which could often easily be attributed to good luck - he could be, and was, heralded as the best thing since sliced bread because he saved millions. Such power surely must be divine. I don't think so.

Not saying Linus or Guido aren't competent engineers. I'm just saying that I don't think they are the sliced bread many make them out to be. They are good. Lots of people are good, but not many people get to be the first to create Python.

And, to be frank, Python - and its ecosystem - and me are through the honeymoon phase. Let's just say the chemistry has worn off and I'm not quite so sure Guido is the net positive we think he is. Maybe Python replaced some other upcoming far superior language. We can't know. (I suspect it did.)

In general I don't think individual/personality worship is a net positive on any axis.

[al_borland]

In a lot of cases, some of those who carry all the water are doing it to themselves, and it hurts the team (and themselves).

In the organization I work in we have an operations team to take care of day to day failure. Write a run book, set up ticketing, hand it off, good to go. I treat this work and hand off as a high priority, as it frees up my time to work on other things. The ones who are chronically busy and appear to be “carrying the water” don’t do it. Their time is dominated my support, they are constantly busy, and it looks like they are doing a lot… but they’re doing work that can and should be handed off.

I’ve been the water carrier as well, but always tried to skill up people any time I had the opportunity. Or I’d build tools to make it easier for people to help, or find a niche where they could be useful doing something that would really improve things that I either didn’t have the time or interest for.

[0xB31B1B]

you are not describing someone who is "carrying water for the team". Someone who is carrying water for the team is, for instance, working on reliability improvements so that the errors or things requiring support occur with less frequency. Its not about being busy, its about having impact.

[aisisbdidns]

You’re over optimizing for engineering skill. The majority of projects don’t need a team full of A players, and trying to get that is going to limit you.

Get rid of team members that make your life harder. Keep the ones that make it easier.

> Individuals ship software not teams

I can’t see how this is remotely true outside of contorting some definitions of “ship”.

[andoando]

It really depends on the project no.

For a lot of stuff, one guy who knows what he is doing is worth infinitely more than any number of engineers, because this job is mostly about knowledge, not labor hours.

Even in a regular enterprise web application, one guy whose just more skilled in architecting solutions is insanely valuable. You dont need a bunch of engineers writing a bunch of inconsistent/unthought out apis and architecture, you need one guy to lead it

[grandempire]

In every project I have worked in big and small - a key person took charge. Others contributed, but that individual made it happen.

[NalNezumi]

so in every key project you've worked on, a one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"?

I think it says more about the size of the project and the complexity of the task that you've worked on, rather than "10x engineer vs normal engineer". Not even at a 10 person startup have I seen "one" person done everything. Unless you're talking about someone just forking OSS and gluing it together, to make a carbon-copy application of something that already exist(for free) then sure.

Edit: >key person took charge and made it happen

person - singular.

made it happen - it's hard to call an engine a car. to make something happen, you need all the component (contributions).

[grandempire]

> one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"?

I didn’t say that. Read it again.

It’s not even the same person every time, people trade off being that key person.

> I think it says more about the size of the project and the complexity of the task

You have no idea. Please address the ideas rather than making personal assumptions.

[whatnow37373]

Humans tend to have pyramidal power structures, because of [reasons]. I don't see how this relates to the topic?

> It’s not even the same person every time, people trade off being that key person.

So it's the role that delivers software? I think I agree with that. Even so, that role cannot function without its support system (the team).

[therealdrag0]

Not needing something is different than not benefiting from something.

[0xB31B1B]

No, I’m optimizing for making customers happy. I dgaf about your ability to leetcode. I strongly care about the rate and quality of the things you ship to prod. This is what a 10x engineer does 10x of.

[alphazard]

This comment is spot on. I would add that it's not only 1 super smart person, or only 2 people per team, it's a power law. 1 person does the most, a few people do almost as much, then you start getting out into the tail of "normal" people. You can try to hard partition the tail and create an 80/20 rule, but it's fundamentally continuous, and the shape parameter will be different for each organization.

Understanding this distribution of productivity is a great litmus test for a manager. If they say the distribution of productivity is shaped much differently than this, that is a red flag. They probably can't tell who is contributing, and you can't trust them to do the basic functions of hire, retain, fire.

The article reads like it was written by a manager with tunnel vision. A manager's value-add comes from making a bunch of "normal" people productive, while staying out of the way of the few engineers who will deliver >50% of the value anyways. If you only focus on making the normal people productive, you are only doing the additive part of your job, and neglecting the negative part, which is to recognize and not interfere with the high performers. I would imagine this guy goes around creating lots of least-common-denominator systems/processes, which drive away talent and make the high performers less productive.

[0xB31B1B]

Spot on. The productivity gradient is extremely steep, and calling this out has become impolite.

[nateglims]

IME people who say this in the workplace tend to overestimate the importance of one aspect (usually the product development itself) and ignore the importance of things like taking a product to manufacturing, getting technical costing under control, or adapting to user needs. There's a lot of fluff in the article, but this part in the conclusion and your statements about "A people hiring A people" or the example of Linus' place in the kernel all align:

> It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams

There's plenty of otherwise "10x" programmers who go outside of their strengths and suffer for it.

[flavio81]

100% based.

Indeed this is one of the hard problems for a manager.

[on_the_train]

Thank you. Every software is essentially being built by a few greats fighting against a dozen morons. 10x doesn't even get close to reality.

We're currently in deep shit because a long term dev was under the assumption that you can only instantiate objects once. He built an insanely complex system around the belief, which shipped. Our users used that system to write configuration files that now drive a machine that cost about half a billion dollars. So we can barely change anything because the data must be supported for 25 years.

The cost of such fools is orders of magnitude higher than their salary. I'm convinced that the world would be a better place without bad devs. Everything would be faster with less people, too.

[0xB31B1B]

The skill gradient is steep. Broadly speaking a top quintile dev will have 5-10x the productivity of the median dev, but only 110-150% of their salary. A bottom quintile dev will have zero impact, negative impact, or .1x impact relative to a median. The goal is to have the top quintile for your project, whether that is product engineers working on b2b saas, or graphics devs working on improvements to game rendering.

[wesselbindt]

About 15000 engineers have contributed to the Linux kernel. You should be more mindful of how facts line up with your feelings.

[weitendorf]

I think this varies a lot with the type of software you’re building and composition of the team. If you are making a very typical CRUD web app in a structured environment (eg a shop that cranks these out one after another, or with strong project/product managers and designers who do a good job speccing things out) you do not need some rockstar 10xer to get it shipped. In fact, that kind of environment might bore or not be rewarding enough for someone like that to stick around even if they do show up.

But you still need people to actually care about their work and get it done even when it’s not “hard”. Someone who could be a solid engineer on one team could be a “10xer” on another team just from caring about the project and consistently putting in the hours on it, if their team is mostly coasting by doing the bare minimum or highly underskilled. In fact I think many so-called 10xers may just be solid engineers who found themselves in workplaces with a culture of “not my problem” or “I can probably stretch this ticket out a few weeks”.

Conversely if you take someone who might be a wizard on one team and drop them into some super complex “engineering catnip” project they might just be seen as a solid engineer there. I think cases like that demonstrate the author’s point pretty well: if you design the project’s processes and tooling around the wizard’s wizards who eg dont use debuggers because they have some insane skill with tracing running binaries you are missing out on the productivity you might gain from the less skilled engineers.

[gorgoiler]

A lot of people will agree with you and a lot of people will disagree with you because the subject might as well be food and for some people that’s coleslaw and for others that’s master chef.

Both have their place. On the topic of greatness (your example, Linux, as opposed to say a build script for vending machine firmware) I couldn’t agree more with both you and the people disagreeing with you.

[chamomeal]

I don’t think I agree with your level of cynicism, but I definitely think my biggest enemy at work is complacency. I joined a company in the last few months, and it seems like this codebase lost the war against complacency years ago, and it’s such a hard hole to climb out of

[tester756]

>Nearly all complex technical projects are owned by one super smart person (Ex: linux).

LoL?

By that logic CEOs are super humans too, cuz they own the companies? :D

>A players hire A players, B players hire C players etc

Where did you hear it?

[klysm]

Look at it from the perspective of a scared business owner who wants replaceable cogs

[whatnow37373]

I claim that being able to work alone or in a small high-performance team is a _luxery_. It's comparatively easy to be performant in those circumstances. The realities of business are what we are usually fighting.

The "complacency" and "mediocrity" you mention have deep roots in politics and human psychology and I'd wager less than 1% have anything to do with tech. One of the many things you do in a business is wrestling with such monsters as capitalism and its various types of dysfunction and a plethora of other nice human factors such as hunger for prestige, power and social status.

To give a concrete example: at the moment I am quite ineffectual at work and the core reason is that I just don't give a flying F. I wasn't always like this. I distinctly remember not being like this. I was made into this and I'm sick and tired to pretend it's actually my own fault.

It's sad to see us engineering types being herded by power hungry psychopaths into arenas where we fight eachother to the death like roosters to see who is the "10x".

[Juliate]

> Individuals ship software not teams

This is true at time T. But over time (can be as short as a matter of weeks), it is not anymore. Team work, interactions, support, resiliency takes over, in a good way.

And that's a good thing, because that's how you build relevance for your work.

If your take on managing your team is fighting complacency and mediocrity, maybe it's the hiring/training/managing process that ought to be reviewed _first_.

[stopyellingatme]

While you may need an individual or two to carry things, you will also need other little things to get done that would slow down the "super stars". It's a team effort, always (when you get outside of personal projects).

[interludead]

The "two people carrying the team" dynamic does happen, but that's often a sign of bad management, not some immutable law of engineering

[mdgrech23]

when people talk about a players I feel like a lot of times it's really just the person who knows the project best or maybe they wrote a lot of the original code so they have the best idea of how it works. My point being who's an A player in my opinion is not reflective of actual skill per se but rather other factors.

[therealdrag0]

Knowledge of the domain helps a lot! But software engineering and dev tools are also domains that are transferable. I have outperformed coworkers with much more code domain familiarity because I had more engineering/debugging/tooling domain performance, or better ability to design and communicate etc etc.

[0xB31B1B]

Yes, exactly! And that is good!

[khazhoux]

Your post is super offsensive. And true.

The number of times I've reviewed someone's code that's been "in progress" for 3 weeks, to see it's 200 lines of simple python code... ugh

"oh, but it was really actually complex and you just don't get it" --> Incorrect

[nextts]

Or maybe they aren't pushing flaky shit into prod and actually thinking about their work. Maybe they did 1k lines (counting lines LOL!) of code reviews, fixed some bugs, helped on an outage etc. Fuck. This one dimensional view of things. Look how any company makes money. Let's say Google. It is not by the number of lines of code.

[khazhoux]

I don't know how many engineers and different engineering teams you've worked with. But I see this all the time.

I worked once with a young engineer that spent 3 weeks for 2 lines of code. We celebrated him as a fucking superstar, because those 2 lines were in a low-level linux library, and he went so deep to find that bug, it was insane. He earned the reputation as one of the top problem-solvers in a multi-hundred person org.

So that's not what I'm talking about. I'm talking about the developers (so many of them) who spend 2+ weeks in standups saying they're "working on automating the deployment", and when it's done you look at their code, and it's an argparse block followed by 6 lines of calling docker with trivial parameters. You've seriously never seen this? Lucky you, then.

[flavio81]

So, you think productivity or even quality can be measured in "amount of lines of code produced".

Which is completely wrong.

[khazhoux]

When a developer takes weeks to come up with trivial code, they are not productive.

I understand that complex problems can (should) be solved with simple code. That's not what I'm talking about.

Simple problems should be solved with simple code, and good developers do this quickly. If someone takes 3 days to figure out how to make a one-line REST api to a well-documented service, they are not productive.

Maybe I just unfairly expect developers at top companies to be able to not get stuck at every step and to not get confused by basic programming. I probably just need to recalibrate and understand that what I consider to be slow developers (certainly by comparison to the many excellent people I've worked with), are actually the norm, and I should just be OK with that.

[solatic]

As a 10x engineer, hard disagree. The modern stack is just too large. Sure, building out an MVP can be done by one 10x engineer, because basically any prototype can be built by a single engineer. But making the UX aesthetically beautiful, adding a test suite (at least for automatic dependency updating), adding observability and alerting, performance optimization, persistence optimization, cost/deployment optimization, day-to-day maintenance automations, architecture and network diagrams, tutorial/how-to/explanation/reference documentation.... you are delusional if you think that can all be delivered, at consistently high quality, by a single engineer.

You can have a single genuinely senior 10x engineer oversee all those efforts, executed by "normal" engineers. But no, not execute them all by the 10x engineer's self.

[mvdtnz]

This is bullshit. I'm sorry you've never had the pleasure of working in a high performing team.

[nextts]

It is teams in a functional organisation. Once everyone is performing then how you organise work: how you communicate complex ideas, how you order work, how you set up each other for success matters a whole deal.

If you measure something meaningful it's teams. If it's LOC or some macho measure of productivity (rewrites in Rust using the hardest frameworks) then yeah it's those "tenexxers".