9 ms·

I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex techn

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

deleted 2y ago
[deleted]
aisisbdidns 2y ago
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”.
- grandempire 2y ago
  In every project I have worked in big and small - a key person took charge. Others contributed, but that individual made it happen.
  - aisisbdidns 2y ago
    [dead]
  - NalNezumi 2y ago
    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 2y ago
      > 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 2y ago
        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).
- andoando 2y ago
  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
- 0xB31B1B 2y ago
  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.
- therealdrag0 2y ago
  Not needing something is different than not benefiting from something.
mdgrech23 2y ago
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.
- 0xB31B1B 2y ago
  Yes, exactly! And that is good!
- therealdrag0 2y ago
  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.
swatcoder 2y ago
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 2y ago
  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.
  - thi2 2y ago
    > 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.
    - BigJono 2y ago
      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.
    - systemf_omega 2y ago
c_e 2y ago
> 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 2y ago
  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.
klysm 2y ago
Look at it from the perspective of a scared business owner who wants replaceable cogs
gilbetron 2y ago
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.
- deleted 2y ago
  [deleted]
- Nathanba 2y ago
  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 2y ago
    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.)
weitendorf 2y ago
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.
mvdtnz 2y ago
This is bullshit. I'm sorry you've never had the pleasure of working in a high performing team.
chamomeal 2y ago
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
gorgoiler 2y ago
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.
on_the_train 2y ago
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 2y ago
  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.
al_borland 2y ago
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 2y ago
  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.
nextts 2y ago
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".
Juliate 2y ago
> 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_.
interludead 2y ago
The "two people carrying the team" dynamic does happen, but that's often a sign of bad management, not some immutable law of engineering
khazhoux 2y ago
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 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - khazhoux 2y ago
    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 2y ago
  So, you think productivity or even quality can be measured in "amount of lines of code produced". Which is completely wrong.
  - khazhoux 2y ago
    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.
TrackerFF 2y ago
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 2y ago
  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 2y ago
    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 2y ago
    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.
solatic 2y ago
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.
wesselbindt 2y ago
About 15000 engineers have contributed to the Linux kernel. You should be more mindful of how facts line up with your feelings.
alphazard 2y ago
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 2y ago
  Spot on. The productivity gradient is extremely steep, and calling this out has become impolite.
  - nateglims 2y ago
    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.
- 2y ago
whatnow37373 2y ago
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".
stopyellingatme 2y ago
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).
tester756 2y ago
>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?
potterbarbatod 2y ago
[flagged]

deleted 2y ago

[deleted]

aisisbdidns 2y ago

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

grandempire 2y ago
In every project I have worked in big and small - a key person took charge. Others contributed, but that individual made it happen.
- aisisbdidns 2y ago
  [dead]
- NalNezumi 2y ago
  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 2y ago
    > 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 2y ago
      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).
andoando 2y ago
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
0xB31B1B 2y ago
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.
therealdrag0 2y ago
Not needing something is different than not benefiting from something.

mdgrech23 2y ago

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.

0xB31B1B 2y ago
Yes, exactly! And that is good!
therealdrag0 2y ago
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.

swatcoder 2y ago

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 2y ago
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.
- thi2 2y ago
  > 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.
  - BigJono 2y ago
    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.
  - systemf_omega 2y ago

c_e 2y ago

> 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 2y ago
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.

klysm 2y ago

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

gilbetron 2y ago

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.

deleted 2y ago
[deleted]
Nathanba 2y ago
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 2y ago
  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.)

weitendorf 2y ago

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.

mvdtnz 2y ago

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

chamomeal 2y ago

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

gorgoiler 2y ago

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.

on_the_train 2y ago

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 2y ago
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.

al_borland 2y ago

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 2y ago
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.

nextts 2y ago

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

Juliate 2y ago

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

interludead 2y ago

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

khazhoux 2y ago

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 2y ago
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.
- deleted 2y ago
  [deleted]
- khazhoux 2y ago
  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 2y ago
So, you think productivity or even quality can be measured in "amount of lines of code produced". Which is completely wrong.
- khazhoux 2y ago
  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.

TrackerFF 2y ago

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 2y ago
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 2y ago
  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 2y ago
  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.

solatic 2y ago

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.

wesselbindt 2y ago

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

alphazard 2y ago

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 2y ago
Spot on. The productivity gradient is extremely steep, and calling this out has become impolite.
- nateglims 2y ago
  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.
2y ago

whatnow37373 2y ago

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

stopyellingatme 2y ago

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

tester756 2y ago

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

potterbarbatod 2y ago

[flagged]