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.
OpenSSL was made by a team, just read the history.
> 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.
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.)
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.
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
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.
strange example, considering that the super-smart owner is purely a delegator at this point, and there are thousands of contributors.
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.
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.
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".
The guy who can roll his own probably also has a better idea than most what easy off the shelf solutions are out there.
Which is why I have learned to stay away from people who use that metric.
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.
What a great environment to train juniors. Does not sound toxic at all.
Junior does not mean incompetent, it means unexperienced.
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.
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.
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.
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.
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.
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”.
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
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).
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.
> 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).
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.
> 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.
Indeed this is one of the hard problems for a manager.
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.
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.
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.
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?
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".
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_.
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
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.
Which is completely wrong.
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.
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.
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".