Didn't we pass the rubicon on that in the early 2010s? I personally don't feel that its "like" finance but that its the exact same behaviors from the exact same set of people.

Once tech stopped being a bunch of nerds in a basement and started being a source of wealth and power, it attracted a whole slew of intelligent and wealth seeking individuals who would have gone to wall street previously. Its not like the math skills don't have a heavy overlap already.

And well, now that they're here, we see all the same power games being played with the same results

All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space.

Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral folder holding source code called all over the code base and the near impossibility of moving it in a location that makes sense for it without having to refactor the whole code base.

People, including myself, have a seriously bad intuition just how much volume there is in a space which grows at least exponentially.

The closest discipline to software engineering is mathematics and that has an even worse track record. There's the folklore about half of all math papers giving the wrong proof for the right conclusion. By comparison software engineering only gets catastrophic bugs less than every other time a program is run.

[0] All trees are natively embedded in some hyperbolic space of whatever curvature matches the average number of children per node, and all code can be ultimately represented as a tree.

Focus is a supper power. Not getting diverted with trivial shit. Don't get distracted , avoid creating more work for yourself and others. Todays me would find yesterdays me a -10X annoyance.

The sooner the software engineering field can be rid of its beliefs about the inherent brilliance of programmers, the better for everyone involved. Inlcuding software engineers!

The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5.

The ratio in more mature fields like civil engineering is closer to ~1:500.

There are lots of similarities between software engineers and the few folk in civil etc doing actual novel design work.

> Nothing that we do is so unique that another competent engineer shouldn't be able to fill in for you when you are having an off day.

In novel design spaces people are not fungible.

I know whenever someone says anything negative like this people come out of the woodwork to say the opposite, and that's fine, but I can't name a single competent programmer who doesn't say things like this in private, and I know a lot of them.

Test it for yourself. The next time you need one of the mediocre people on your team to do something pay attention to how they do it. I will bet you it's something like this: Get the ticket. Spend a day or two trying anything they can think of, googling, pasting stuff into chatgpt, etc. Then they start messaging people. They tend to try to not always ask the same helper because it would get too annoying, so they rotate around the team asking for help. The helper starts by offering suggestions, but the mediocre dev can't get those suggestions working or apply them correctly. Pretty soon the helper just types a bunch of code into the chat window so they can go back to what they are trying to do. The m dev takes this code, and pastes it into their branch. It's not quite right though, it needs a little tweaking to work but they can't figure out what to do, so they message the next helper. (And sometimes it's hilarious what it is, a lot of times it's a typo and when you run the code it says exactly what line it's on, but they don't know how to run code besides pressing the button in their editor that someone else set up for them) To helper 2 it seems like they are making good progress, they are just stuck on some small thing. Happens to everyone. They tell them exactly what's wrong. And voila, this is how about 30% of the people you work with write code. People don't catch on because when you are helper #2 you assume they wrote that perfectly competent code.

My university has an alternative entrepreneurial focused “senior design” course open to engineers and cs students. Because of scale the CS students are now separated in a different section. All I can say is the level of toxicity that I’ve witnessed from cs students to engineering students has made this a much nicer course to work with teams.

Engineering students can be ego driven now it alls sure, but the level of toxicity behavior and assumptions of superiority I’ve seen from CS students makes me glad I don’t have to deal with them anymore.

The primary fault I see, and it’s buried in the abstractions comments from others is the assumption that their knowledge is all encompassing because it is so abstracted. The inability to attach it to contextual realities is taken as virtue rather than a risk factor.

I always go back to the fast company article on the coding team behind the space shuttle and their culture. The difference is telling in terms of qyality and risk tradeoff. Realistically the number of engineers who will design something that could kill someone and software developers who will exist at opposite ends of the percentage scale. That reality manifests in professional culture. We’ve seen it in so many places.

This threat is insightful but not in the way commenters likely think.

The thing about being intelligent is that you have the capacity to find wisdom faster. I’ve worked with too many intelligent fools, and nearly all of them quit rather than face the consequences of their own actions.

I tend to stay too long, either cleaning up after my own messes or someone else’s. Maybe I watched too many westerns as a child. Who knows.

But I’d rather work with someone wise who can’t reinvent bloom filters from first principles than someone who could, and thinks doing so is a good idea.

There’s an ethical trap where you think you’re the only one here who can make something work, because now you’re on the hook to support it and if you have a negative opinion of your peers, how is that going to work out, do you think? Did you think? Or were you too busy wondering if you could do it to think about whether you should?

I think the advice, “never be the smartest person in a room” is just about the biggest bullshit in tech. Intelligent people cannot teach you to be like them. They can’t change your brain much more than you already have, just surviving school and university. But a wise person can teach you three new things before lunch, sometimes without even trying.

Don’t be the wisest person in a room, and if you must be, don’t denigrate the wisdom of beginners. Good teachers learn from their pupils.

how much does the strength/weight ratio of building materials improve every year? how much does the price/quality ratio of building materials fall every year?

software engineering is working with technology where compute capacity was doubling and price/performance was halving every two years for decades. this rate of change has slowed, but in a world where the price of everything else inflates, software is a rare field that works with a continually deflating capital base.

the uniqueness of software development is real and based on underlying physical/economic factors that exist in very few industries.

software developers are not unique. they are still human. but the profession is unique and the financial incentives are unique.

consistent, careful, workmanlike effort over time wins on average, but because the incentives are large, many people will take the risk to get exceptional rewards.

i approach software development like a professional athlete. i work on optimizing every aspect of my performance (physical, mental, social, technical) to be the very best i can be. anyone who applies this level of dedication in any field will be highly successful, but it requires dedication, sacrifice, and risk, which many people are not willing to accept.

the world is full of exceptional software and algorithms designed by unique individuals who developed things nobody else could or would. there is a reason why mathematical discoveries are named after the people who discovered them.

building software for large corporations necessarily revolves around median-level teams, because mean-reversion always happens at scale, but that is also why a great deal of technical innovation takes place outside of large corporations.

The board decided to promote these people who negotiated a 4-days week; after all the team had never missed a deadline, and gradually I was given more and more tacit responsibilities without explicit status recognition. This creates a double-bind situation for both sides. While I could never be satisfied because of this lack of trust, you have to understand why they approached me with suspicion while being dependent on me.

A 10x engineer (or any Nx engineer with N > 1) has to interface with the rest of the team and this necessarily implies more work. In my case, resentment grew because of the increased workload this led to for them, and my colleagues felt more impacted by this than by deadlines being not met. As for management, since deadlines were already met, they felt more compelled to listen to the negative feedback they gathered about me and develop suspicion. And yet, they had to rely on me for any impromptu problem they had.

What's this article is discussing is not engineers with bouts of outstanding performance but engineers with that symbolical status. It's attacking the myth, and the attribution of that label, not a reality with measurable outcomes. The article doubts that such a measure exists, however the departure of an employee can have destabilizing effects on an organization. The delta won't exactly measure this employee's worth, but an organization can put itself in such a configuration that it will unknowingly rely on a few key individuals for its financial strategy and use the added value these people bring against its competitors, to win investors attracted by this differential in efficiency or proceed to acqui-hires. This leads the company to bind itself to commitments which pushes it near to a dangerous threshold.

Once crossed, when one of the cheap keystone employees leaves, this excess of work can cascade to other keystone employees, and cause more resignations, and the company won't be able to make up for it because its finances are already engaged elsewhere.

    > well known toxic field, finance

I'm not sure what you are talking about. Finance people regularly talk about risk adjusted returns, not raw returns.

There is a big difference between filling in someone on an off day, and actually taking over their job. It's only felt over weeks and months.

"Consistent, careful, workmanlike": this does not describe the kind of software built by most teams, but it does describe the work of good individuals.

And not even anything to do with AI.

But i take the title to indicate a bias against neurodivergence — “One of us,” repeated in a robotic monotone over and over. Hahaha ;)

Perhaps i should read the article!

This is worth remembering for basically anyone who works on anything, or manages any kind of project.

>The effect of consistent, careful, workmanlike effort over time trumps any number of crunch weeks and burnout episodes, to an almost absurd degree.

If you have an actual life, you know, with unexpected stuff coming up from time to time, this is just not possible. Then the only way to get stuff done is go 10x during the time you have whenever you have it.

Complex multiyear things are so unique that there is next to 0 chance to find another competent engineer as replacement. Some companies do that, and the only result is the extreme lack of quality and consequently reputation degradation. I witnessed this myself many, many times - great products turning into non-efficient and hard to use BS.

Complex things posses such a big number of moving components that simply iterating over them placing them into context is impossible for anyone except the one that was deep into it for years. Its not possible to "fill in" such person, particularly if that person was lacking in some domains like proper documentation (typical case).

As an example, I am leading a project that creates a government bank from 0. Just in last 2 years I wrote 1000+ pages of compressed documentation on it besides programming and management. Please replace me. My company and I are trying to do that for last 5 years.

When there's 1000 ways to do a thing, with wildly different pros and cons, and insane amount of unknowns in a field that is evolving so rapidly that it is (near) impossible for someone to keep up, being "competent" is not easy.

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.

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.

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

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.

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

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

Exactly.

I think i'll never click on an IEEE Spectrum article again.

IEEE has jumped the shark.

It seemed more interesting a decade ago, but I can't be sure if it's because the quality was higher or if was because I didn't know better…

I wonder what Sutskever would think if you asked him that question. I bet he'd point out several of his contemporaries that are more deserving of praise.

I'd argue there are plenty of Sutskever's out there who are normal engineers.

> We place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors.

This is just author trying to impose their personal politics on their org. Popular sentiment among pmc unfortunately especially in the last 10 years of zirp

Most 1x engineers/developers care deeply about users and the end product, and also likes to keep the code well maintained and performant, so they can do their peaceful work and go home, while not making the life of the user any more miserable.

Most 10x engineers are too brilliant and remain busy rocking the boat and doing so many mind blowing things at any given time that the destruction trail is only materialising slowly once their presence has faded for a while and the remnants are being pieced together.

I think, we equate the frenzy with 10x(productivity & excellence) while the less creative and cautious ones tend to be the most valuable over long term with most boring stuff.

Of course to each their own, but the too many destructions of the 10x stars had made me very weary these days.

1x is normal. Some people are less, some people are more. Normal is good and predictable. There's nothing wrong with normal. Normal people that put in a decent effort will produce results. That's a good thing. For a lot of long lived software, normal is what you want. You can't reasonably ask normal people to be more than normal. That would be abnormal. Putting in 120% of your best is not a thing. It doesn't work that way. You are doing pretty OK if you are getting 70-80% of your theoretical best. That's what normal is.

There are of course people who are a bit more capable than their average peers. This is often confused with working long hours. The ability to work longer is mostly something young, relatively healthy people are good at. But there's a difference between working longer and working smarter. You can't work 10x more than a normal person. There's only 24 hours in a day. The only logical way to get 10x more done is to work smarter. There is no other way. And some people really just are that good that they get more work done in the same amount of time. Part of that is experience, brains, and just being really efficient with their time.

An exhausted 10x developer is not a 10x developer. Because they'll be perpetually too tired to work smart. So they might be producing a lot of code but it will be the type of code that will need a lot of maintenance. A true 10x developer consistently writes less code with high impact without wearing themselves out too much. Doing that requires skill and experience. The best code is code you don't have to write. Use the right libraries, avoid reinventing wheels, make your code testable (so you don't get bogged down debugging it), don't repeat yourself, etc. If you find yourself doing the same thing over and over again, automate it. That's your job. Don't keep on doing the same thing. That would be stupid and somebody else will do something smarter eventually.

You don't have a 10x without there being a 0.1x engineer. And we can't all be right.

Which works for some time, or when extensively coached, but eventually they move since their time is oh so precious and now you have the rest of the team to work with their work. Not that great.

Then people wonder or complain when business doesn't appreciate devs. How would you look at folks who are critical to your success yet often don't have your company's best interest at the center of their efforts.

To use your terms, those 1x devs always end up maintaining and evolving that code of 10x guys. Their velocity with changes is massively lower and error rate is significantly higher compared to code created by 1x devs. This is what business sees and there is not much love for that.

Some engineers have an obsessive, sometimes compulsive, nature which is actually at odds with the business. These types usually spent a large amount of time in institutionalized learning settings and will be far more opinionated about how their labor is allocated.

Having said that, there is also something to be said about engineers who consistently cave into management pressure not because of brute force management tactics, but because the engineers themselves haven't spent the effort to build confidence into good engineering practices that will allow them to both fend off pressure and deliver better work. I see people complaining: "oh the company we work for does this, that, the other, irrational things". Yes this is true, but what are you doing about it.

Do you expect higher ups, detached from reality and practice, to drive your working processes in a rational manner? This can only be the exception and we all know it. There are exceptions that proove the rule

I met great engineers or developers who won't even care to answer a fizzbuzz-type question.

I met terrible ones who had top technical and math capabilities but little agency at pointing what is relevant or not in their work.

Even considering it's pyramid-shaped is excluding all the externalities that make one person thrive in some contexts, and just flat or negative in others.

Take a top performer, if he's not in the right position at the right time, nothing will happen. Conversely, someone not so good, but being in the right place at the right moment may nudge things in the right direction.

That's exactly around what I understand the OP develops in her article: engineering, building is a work of teams, not individuals. In a team, people come and go, roles are different, shift with time and progress. "Terrible" people become "excellent" and the other way around, that's life.

Perfect performance all the time isn't even what we require of machines, because then they (or systems they relate to) break faster. Why would one have the same expectations with people?

Coding and productivity are one thing, but engineering in the end is a lot about having a certain awareness of the impact your technological choices have on a project both in the short and long term. I'd rather take someone who has this awareness, than someone who hasn't, even if the person in the latter category would be slightly better at coding.

Here's my pointless randomly made up on the spot anecdote - you're more likely to write a vulnerability in your own logging system than being impactedby using a widely adopted opensource one.

Yes, i have many examples. Two of them I personally fired. One of them, I should have fired much early. I let this engineer basically add negative value by trying to make his peers (other engineers) finish the work it was delegated to him, thus creating negative value by preventing the other, highly productive engineers, to do their tasks.

I warned him not to do this, but he didn't heed. Sadly due to Human Resources the firing process took way too long. I should've acted earlier.

No. Have you really worked with someone that did this and they weren't fired?