These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor.

It's laudable to do your work well and go home to the rest of your life, and working "extreme" hours is both a bad policy and a bad sign that the system you're operating in is brittle. 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.

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

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

You can also trace personal backgrounds and you'll see a much higher representation in the newer cohort coming from upper middle class backgrounds with families in careers like finance, consulting, medicine/dentistry whereas more in the older cohort came from more modest middle class backgrounds in engineering, academia, or even working class trades.

Of course, there were always some of all of these people in the industry, but the balance shifted dramatically during the last couple booms, tracking the atypically high compensation standards set by FAANG's since 2010 or so.

The way I see it, it's like 'swatcoder and 'lovich said upthread: the field became a money printer, and attracted - not revealed, attracted - a different kind of people, with a different mindset. I too saw this change happening. Applicant pool size? That's a spurious correlation - it's just driven by the same factors that make software industry a money printer.

Well that and this is a forum for a lot of tech people which means a good number of software engineers here.

Also money is nice.

You never write code in a vacuum do you? You always have some kind of goal.

https://swizec.com/blog/lolcodetojavascript-compiler-babel-m...

It was pretty fun.

Also this other time I wrote a nodejs script to keep my computer at a specific temperature because our office fridge kept freezing my carrots.

https://swizec.com/blog/i-built-a-node-app-to-thaw-my-favori...

  > because our office fridge kept freezing my carrots.

I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation.

I'm not that old, but I've been around long enough to hear people of every age over about 30 claim that everything was better back in their day until the new generation came along and ruined it.

And they’d probably be right!

I remember the grognards giving me shit about memory management and me giving it right back by explaining that what they considered a large chunk of memory would be worth pennys next year because of Moore’s law and I wasn’t going to waste time considering something that I literally couldn’t learn faster than it became obsolete knowledge.

Quantitative differences can create qualitative differences and I don’t think it’s surprising that we’re in a different age of software engineering than we were 10-15 years ago for any given X year

But ignore memory at your peril. I have one proj that has a 256GB instance. For a fairly boring CRUD app. I am asking a lot of questions as apparently we are having the yearly 'we need more memory' questions. Things that are leading to speedups. Just by using less memory. At the bottom of that stack is a L1 cache with less than a hundred KB. It doesnt matter right up until it does. I have seen huge 300+ item string classes that needed maybe 10 of the fields. They threw it in 'just because there is enough'. Yet something has to fill in those fields. Something has to generate all the code for those fields. The memory mangers have to keep track of all of that junk. Oh and all of that is in a pipeline of a cascade of applications so that 300+ class is copied 10 times. Plus the cost to keep it on disk and shove it thru the network.

People that stopped running tests because they were configured to make 10,000 API calls in one minutes and it crippled the app until everything was restarted.

"Add some more memory to your database instance....poof"

Honestly, I think so much of this comes from the belief of needing to move fast because. Because why? That would require direction. I think the money motivation is motivating speed but we've lost a lot of vision. Moving fast is great for learning but when you break things you got to clean it up. The problem is that once these tech giants formed they continued to act like a scrappy developer. To not go back and fix all the mess because we gotta go fast, we gotta go forward. But with no real vision forward. And you can't have that vision unless you understand the failures. We have so many low hanging fruits that I can't figure out why they aren't being solved. From deduplicating calendar entries, automatically turning off captioning on videos when a video has embedded captioning so you don't just overlay text on top of text, searching email, or even setting defaults to entry fields based on the browser data (e.g. if you ask for user's country, put the one the browser is telling you at the top of the fucking list!). These are all things I think you would think about if you were working in a space where you needed to consider optimization, if you were resource constrained. But we don't and so we let it slide. But the issue is a death by a thousand cuts. It isn't so bad in a few cases but these things add up. And the great irony of it all is that scale is what has made tech so powerful and wealthy in the first place. But no one stops to ask if we're also scaling up shit. If you printing gold but 1% of your gold is shit, you're still making a ton of shit. The little things matter because the little things add up. You're forced to deal with that when you think about memory management but now we just don't

And that's why all applications are laggy as shit these days.

Then suddenly single threaded speedups didn’t happen anymore (and people realized even though cpu speeds had grown, it was not directly related to Moore’s law).

Ofc your rationale used Moore’s law correctly while the ”cpu infinite speed growth rah rah rah” peoples didn’t.

https://en.wikipedia.org/wiki/Wirth%27s_law

And more generally,

https://en.m.wikipedia.org/wiki/Jevons_paradox

>FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory > 1: node::Abort() [/usr/bin/node]

Is what made me decide it might finally be worth the time to actually learn how memory worked

For instance I was a CS undergrad in the mid/late-90s. There was an enormous difference demographically between my incoming freshman class and the incoming freshman class by the time I graduated. And the talking points were exactly the same ones we see in this thread.

The original focus of this thread was on technical precision vs. market efficiency, and how quality was sacrificed for faster conversion to sales.

That shift compromises products for everyone by creating a race to the bottom toward the minimum viable product and safety standards. When the consequences eventually hit, the aggregate responsibility and emergent effects lose direct attribution...but they exist all the same.

The most salient values of the later cohort are different than those in the prior ones, and those values do track with the values we associate with those different class backgrounds.

But there's no ranking being made there. They're just different values.

The values of the new cohort have earned the industry a great deal of political, economic, and cultural influence on an international level.

The values of the old cohort didn't do that, except insofar as they built a stage for the new one. They made software differently. They designed products differently. They operated businesses on different scales. They hired differently.

Indeed some of us from the old cohort don't personally savor all the spotlight and influence and cultural drama that Silicon Valley collectively bears now, and miss the way thing were. And others love it. But that's just personal preference, not class warfare.

I'm only a little younger than Gates, and it seemed like, what else would you do? PCs were revolutionizing the world.

For about a decade I worked as an engineer in a field where the expectation (at least starting) was that metal gets cut, stuff gets built, and there's physical hardware.

Those existed. May have actually had more hardware interaction than many in engineering. Yet much of the day to day rapidly became computer simulations of the metal that might get cut someday.

In many fields, the organizational choice decrement on anything involving capital expenditure or purchase was so severe that usually the obvious choice was to run a computer model, and simulate what might occur. What else would you do?

Boy is this true. I don’t think we ever recovered. Imagine trying to start a capital intensive business like mining in 2025.

To be fair, I don't see any value judgements in the post you're replying to. He doesn't say if it's a good or bad thing, it's just a thing. But what I think this means is that field became more popular, entry filters became more competitive, and families with less resources to invest in their offspring became filtered out.

There's nothing good or bad about it.

Now the people entering the industry by and large see it as a game of wealth acquisition similar to finance or big law, and big tech is adapting in a similar way -- high salaries, insanely bad wlb, politics far exceeding any other skill as a determiner of career progression.

For a while, if you knew how to type into a text editor, you were hired as a "webmaster." Lots of people made a lot of money, writing awful stuff.

If there's money to be made, people will pour in. They aren't necessarily bad folks, and many of them are skilled, and willing to work hard, so the trope of "thousands of terrible engineers" is maybe not that accurate.

However, I kind of despair at the management skills of the folks that run the teams, and the decision-makers that set the bar.

But the story is correct. Teams need cohesion, a lot more than rockstars. We can do together, what I can't do alone.

For example EE used to be prestige and CS was the backup. And that would never compare to finance or law.

These are the new bloods that gifted us with surveillance tech, btw.

Andreessen, Scott McNealy, & Ellison were, to me, the ones that left a particularly bad taste.

At some point the wheeling and dealing, snake oil, corporate backstabby like people that many associate with finance were actually high schoolers at some point who had to pick where they went in life. The ones who only care about wealth and power, only care about wealth and power, so if software was a good route to that theyll put on their software face and do that job. Before software made a lot of money for people, finance was the default

2. I agree that unions are useful, and you’re starting to see them (eg Alphabet Workers Union). There is definitely opportunity here.

3. I think your visions of non-grandeur are blinding you to the possibilities that others live life and advocate for themselves differently, without it being wrong. Sometimes change is ok and sometimes people being different from you and your beliefs is ok.

While I do think unions are important, Silicon Valley engineers are responding in-kind to their fungibility. It’s pretty common to see people jump around every few years, chasing opportunities instead of loyalty. Usually collecting a pay bump. It’s generally not looked down upon in hiring, because it’s increasingly normal, and the extra pay and corresponding savings protects against periods of unemployment. Regardless of people’s thoughts on the practice, “resume driven development” grew as a reaction to the fungibility - forcing their own self-growth upon a disloyal employer.

Big urban areas with lots of job opportunities are difference employment environments, and employee’s actions of self protection evolved differently. Is there room for learning? Always. But this entire comment seems to pass judgement upon a world that frankly doesn’t exist.

As a Bay Area resident who once lived in the Midwest, I can confidently say that people on the coast don’t have such a negative view of “corn lands” - this narrative is very much self imposed.

Amount of toxic behavior in nerdy groups is just as high as finance.

Every single one just thinks how smart he is and how to one up the other.

Technical interviews were always bad even before 2010 as there was loads of gatekeeping anyway.

Accountants have the same bullshit memes we do.

The 787 did something Boeing vowed they would never ever do. They let Mitsubishi build the wings of the 787. They’ve never let a supplier do that. The wings are the heart of the airplane. I am completely amazed that Mitsubishi never progressed past commuter jets after that project (and I believe they shut that division down about 5-10 years ago). Just unfathomably dumb.

I don’t know what we in software need to learn from this. I don’t think being meaner makes anything better, but maybe more assertive is the answer.

this happened "in the early 2010s"? I don't think so. Software engineers have no power, and in comparison to finance, quite limited wealth.

I have no doubt they would fail their current interview cycle for engineers if they tried it under a pseudonym, they were considered software engineers when they started their companies and that cohort is now in charge of a double digit percentage of the planets wealth.

If you think software engineers have no power and limited wealth compared to finance then I can only imagine you are not a software engineer are are downplaying the amount of power the class has absorbed, or we fundamentally disagree on what a software engineer is

Like that fellow who runs a car company now

Sort of tracks with the Welchian bullshit he seems to have supported as CEO.

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.

Trying to diminish engineering disciplines that have existed for millennia by imposing an arbitrary constraint of "3 euclidean" is pretty wank. Let's drop silly constraints.

Do you have any idea how complicated concrete is? It's just sand, aggregate, cement and water. Exothermic reaction. Job done.

Let's look at wood ... the stuff is a bundle of fibres and stuff and yet we build huge structures out of it. Who on earth knows how or why plywood works? Britain had several all wooden aircraft during WWII - the Mosquito was so good that Herman Goering declared that it was worth two kills.

Steel - its just iron with other stuff.

Software engineering is growing up gradually but please don't be a dick towards people who practice disciplines that invented things and concepts you rely on and live within.

For example the concept of a token that allows you to do something exclusively - " exclusive lock" - was popularised by early railways. A single track should have only one train on it and after a few accidents the idea of an exclusive token was "invented" that could be passed across to the next exclusive user.

When you say hyperbolic, you should be aware of how close that is to hyperbole.

The point is that all other engineering disciplines don't have enough design space to make a true mess of their projects. Software by comparison hasn't been limited in its design space since the first super computers started having gigabytes of ram memory in the late 1980s.

That doesn't mean that either discipline is better or worse, it means they are different. Other than math there is no other field which has as much freedom when it comes to basic design choices as software engineering, and math proofs are even more of a mess than software programs, to the point that pretty much every non-formally verified proof is wrong in some way.

Or to put another way: would railways be more or less complex if we allowed them to be embedded in a higher dimensional space instead of being essentially a 2d network on the earth surface? If you don't think so I'd like you to think about what a train schedule would look like on hyper graphs: https://en.wikipedia.org/wiki/Hypergraph

Every discipline has infinite depth.

Railways in 2D may seem simple but there the simplicity may be intentional. Just like when you write software that runs things like planes, trains, or medical devices, all of a sudden you’re writing in C, without recursion, without function pointers, without using the heap, etc.

Look at the concord airplane. A mess of a project.

Look at anything in biology and human health. The complexity is unimaginable compared to software.

Edit: reduced emotions

Any type of physical engineering is based on hard facts, data, and well established historical research, mathematics, and more.

I've seen many an electrical engineer say, "fuck it, this is too hard and pays too little" and so they pivoted into software engineering quite easily.

On the other hand I've never seen the opposite. Real engineering is hard because you actually have to get shit perfect. The wrong o rings and real people die.

There are a few real software engineering shops and real software engineers, but 90% are just slinging shit together for a bunch of enterprise CRUD and they are all just one bad deploy away from disaster.

I read it as: “software is special because its design space is high dimensional, compared to all other engineering disciplines which are limited to 3 spatial dimensions. Large design space leads to ability to mess things up.”

I wholeheartedly agree with you: “real” engineering (where lives are on the line) is hard. Most software that is made is not to control pace makers, air plane autopilot, space shuttles, etc. When we do need to program in these life and death situations, we should look carefully at the real engineers that do this all the time (looking at you self-driving car software).

I totally agree with their post and get what they're saying.

Within circuits (big or small) it is possible to do some crazy stupid shit, but reality kicks in much sooner. Either because of physics or price.

Analog circuits (my specialty) are a perfect example of this. Sure I can try to cut corners and interconnect two distant parts of the circuit together in weird ways ("tight coupling" in software), but the options I will reach for are limited, and "nature" forces me to "decouple" them. With software I can just set a distant variable...

I have a Building Engineer on my team, who also moved to Software Engineering. I can ask for examples in his field too.

Engineering with constraints builds discipline. Maybe we are lacking as engineers in software because the constraint bar just continues to raise.

We could always talk about stacks, AVL trees, or NLP before any meaningful conception of computers, and indeed a lot of computer science research happened when computers were still fairly primitive. Computer science and its applied form, software engineering, are about computation (data and code) and abstraction. Even computation is just a distraction at some level. There's some world with the ideal behavior that a program should abstract from, but an ideal is an ideal, so programming is often floundering to figure out what ad-hoc world the program mirrors and tweaking haphazardly. Software engineering isn't engineering not because it can't be, due to the (very real) differences of software from the physical world. It isn't engineering currently because we aren't taking control of our actions and their consequences, in all senses.

Intellectual superiority is not relevant here. Everyone has hard tasks. If you're a civil engineer, then design and build infrastructure well. If you're a programmer, then design and build programs well. Any discipline demands honesty and forthrightness in evaluating its work.

90% of programming is enterprise CRUD, and the bar is low. Likewise, 90% of electrical work is basic circuitry with off the shelf parts: does it work and not catch fire. There are electrical engineers doing Real :TM: Engineering, but 90% or more of the work is electrician work.

Since I want programming to be inclusive and not have a bad rap publicly, when a peer says “software is better than all other disciplines because of X, Y, Z” I want to convince them otherwise.

As a leader and teacher with more grey hair every day, I feel this responsibility

You should probably do less of that since:

1). That's not what any of my posts said.

2). My degree says mathematical physics and not computer science or software engineering.

3). A field where you're tone policed by the tone deaf is the opposite of welcoming and inclusive.

U/callc appears to be reacting to the public perception of how this thread would read externally, you appear to be reacting based on hard logic, which is unpalatable to most of the public.

I think you two are talking past each other

This is why steelmanning a comment before arguing against it should be a rule.

Based on your comment I’m interpreting “special” as “better”, or “harder”.

I interpreted the comment you replying to as software is “special” as in it is “different” and the differences require different solutions than other fields have.

Like when I talk to my civil engineer friends I only on the surface comprehend what they are dealing with when they need to move literal thousands of tons of mass. I can try and make an analogy to my own experience with bandwidth and memory, but nothing will be a 1:1 comparison with the amount of energy used when the physical mass of the entire internet is within an order of magnitude of a strawberry.

Simultaneously my civil engineers friends don’t have to deal with a situation of one of their apprentices making a logical mistake based on a single missed `!` and their features suddenly using up 100% of all resources everywhere

What makes software unique to other engineering disciplines is that it isn't a discipline at all. What makes software so great is how quick the iteration cycles are.

Software sits at a higher abstraction level than physical hardware, so much of our time is spent throwing at the wall and seeing what sticks because that's often (although not always) the best use of time.

Back in my EE days in 90's, "full stack engineer" meant, for example, being able to build a physical calculator by connecting a numerical keyboard, bunch of 7 segment displays and a micro controller using bunch of wires on a circuit board, and THEN writing the assembly code to allocate memory and run your program in an infinite loop. You had to erase your EPROM with UV and burn your program to the chip over and over every time you changed a byte in your code. Debugging? You wish.

As a side effect, full stack engineers had the risk of getting electrocuted, or going blind :)

These days you are hard pressed to find a language that uses dynamic scoping as the default.

The needle likes to swing back and forth between dynamic be static typing but we definitely seem to be coming back to static typing again

    patients = 400
    x = pat / 2

This joke is like a decade old at this point https://xkcd.com/1172/

Namely, what does the following code do?

    patients = 400
    patents = 20
    x = patients / 10

“Doing something” is the beginning of how to describe the actual truth of what some actions causes in relation to its affect on reality.

“Supporting something” has literally nothing to do with reality beyond what’s necessary to support a brain that can _intend_ a result or action regardless of what actually happens.

I linked the xkcd comic because the behavior described by the developer in the comic met the criteria for “doing something” but it didn’t meet the criteria for “supporting something” because the behavior of the software was not what the developer intended.

It's also my experience that a few well written integration tests are more useful and catch more actual bugs than a million unit tests. This is especially true of web apps which are inherently highly stateful.

The most powerful design paradigm I have ever found is to spend the first, say, 10-20% of my time making a rough prototype. Not with an eye of actually using a single line of it (although it happens) but just to do the quickest and dirtiest possible exploration of what the actual problem is.

you mean concerns that should be seperated but they did it in a wrong way?

Software is ultimately limited to building things in a space that is only countably infinite. There is only so much junk you can hide in a space that is only countably infinite.

All other engineering disciplines by comparison deal in a space that is uncountably infinite 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 measurable "collection" of intervals having such weird holes all over the real number line and the near impossibility of shifting it up or down that makes sense for it without having to rethink our whole notion of measure and still end up with something like the counting measure that definitely doesn't make sense.

People, including myself, have a seriously bad intuition just how much volume there is in an uncountably infinite space.

However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points.

What's very different is the cost to change the system to do something new and that's where this unbounded complexity blows up in our face.

This is a common sense view of computation that's unfortunately wrong.

The simplest counter example is the busy beaver program: with as little as 12 states we have saturated the computational capabilities of the universe, but it looks completely safe and sane for the first few states you would be testing against.

You may call it pathological, and you'd be right, but the point is that you never know under which rug a function that takes more computation than the universe can supply is hiding.

By comparison power electronics engineers don't have to formally prove that they didn't accidentally include a nuclear power plant in their e-scooter design.

If on the other hand you're speaking of the theoretical computational needs of the program you just wrote, then your earlier dismissal of mathematics and its "even worse track record" is all the sillier.

Which, indeed, is different from engineering where constraints are non-negotiable, and thus the methodology as well.

I think a lot of people doing functional programming, as an example, enjoy the constraints and the discipline that it imbues on their craft.

except that's not really true. The big difference is that to negotiating the constraints when it comes to (physical) engineering, one of the biggest factors is money (and lots of it). "Well, we could double the span but for that you'll need to have parts A1, D5 and T3 built out of ..."

Software development isn't free, but it doesn't typically incur doubling of costs for tweaks to the feature list (and I do mean tweaks).

Then marketing come along and ask to make it a trilogy and a few weeks before release they ask you to add in Ewoks because it'll sell more toys.

The _need_ to build higher-level abstractions to manage the complexity or verboseness required to do things from lower level components always seems to be fighting with the _desire_ to build your own higher-level abstractions that fit your own view of how things 'should be', despite many of the decisions going into this being abstract and not easily objectively measurable.

On top of that, software components as 'reusable boxes' only seems to work up to a certain level. The idea seems to be that higher-level abstractions and reusable pieces are all nicely shaped square boxes that all perfectly fit inside other boxes, but the reality seems to be more that even the best reusable boxes aren't perfectly square, have weird edges, and themselves have to fit into larger non-square shapes with weird edges.

And what are the weird sharp edges? Decisions that had to be made about solving a problem. Every higher-level software component is on some level a set of (mostly arbitrary, sometimes measured) decisions about how to take a set of lower level generic components and make something more specific with them. Libraries might assume a certain structure but leave choices for how they're composed to the user. Applications make many more decisions about how their components are used in order to provide a more specific tool. There is a move from genericity to specificity as you move up layers of components.

And finally, software requirements change all the time, but the need to change is itself at odds with the requirement that problems are solved only by making hundreds of decisions that have to work together for a working solution but also may be difficult to undo.

> the constraints and the discipline that it imbues on their craft.

Perhaps the constraints and discipline here comes from a desire to move towards some kind of standard or expected way of structuring software, knowing from experience that the cognitive cost of making (and sometimes having to read and understand) all the arbitrary decisions mentioned above is actually quite high. (This itself also leads to the notion of 'best practices' which seemingly change too often to ever really be considered best).

Case in point - more than one Mars mission has failed due to software errors.

However you could argue that the best way to deal with that complexity is not to have a brilliant mind that can grok more of that complex space, but by simply taking good engineering practices to minimise and manage it - ultimately the complexity is beyond us all if not managed.

If you do not have the experience and skill to express your ideas in text in a clear and concise, you will struggle to write good code (and vice versa tbf).And coders generally are lacking on the more humanities side of their educations.

Different jurisdictions have different tax rates.

Eh, you can also create a bijection between all programs and the natural numbers, so I don't think this analogy gives much insight. It's also silly to think that structural engineers or whatever only have to worry about where to place indistinguishable cubes in 3d space at a single moment in time and move on to the next job.

This honestly comes off as the kind of masturbatory rhetoric the GP seemed to be talking about.

Let's take a made up example of a structural engineer designing a building. As another comment mentioned, in theory the design space here is enormous. Just the concrete mix can be endlessly optimized. But here there's a large monetary cost tradeoff that's obvious to everyone involved. Say an overenthusiastic junior proposes attempting to rediscover ancient Roman concrete mix for this project. Everyone from the other engineers to management can call that out as absurd.

In theory you can make the building out of anything. But in practice the economics of producing real world components only allows for a few choices in each stage of the design.

Meanwhile, software components are essentially free, especially if they're open source. Just clone the repo, hook up the code and you're done, right? So surprisingly often, the overenthusiastic junior can convince the whole company to build the new feature with some obscure framework that'll be unsupported in a few years. And no one can reliably call them out, because there's no easy, objective way to measure something like tech debt. (Another compounding problem is the rapid growth of the software field. Juniors are minted faster than they can be trained.)

To make the software example more concrete: there's an internal config language "blub" in one of the FAANGs that someone designed in two months. It looked simple, gained a lot of adoption quickly. Fast forward 5 years, and it turns out using blub was a big mistake. It scales terribly, the semantics were badly thought out and cause subtle bugs everywhere. But here's the kicker: there are now millions of lines of blub. Over the next decade, the company makes several very expensive attempts to replace blub and fails. Blub continues to underpin their production infra to this day.

So to sum up, I think maybe the core issue is not so much "3d space versus hyperbolic space". If you view the space as the tree of decisions you need to make to reach the goal, all engineers are working in hyperbolic space.

However, when designing real world things, economics rapidly culls the design tree. Buying materials requires cash up front. But in software it's often the opposite: you get the libraries "for free", and the unmeasurable tech debt accrues over time.

Exactly like sticking with blub, which was only chosen because of historical accident, but they're stuck with it because it would cost too much to stop all progress while refactoring everything to work around it.

You're arguing a matter of degree while asserting a matter of kind.

And the point is still ridiculous with the explicit comparison to maths, which is somehow different because there exists wrong proofs.

Sorry, what? This is an extraordinary claim.

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.

This is not a 10X programmer. A 10X programmer delivers the same amount of functionality in 1/10 the time.

For me the first 10x programmer that comes to mind is Peter Norvig. This spell checker he wrote in a single flight remains a work of art:

https://norvig.com/spell-correct.html

Very few programmers would come up with something so concise and elegant yet powerful in such a short amount of time.

Writing and debugging production code is a different skill set. Finding the optimal algorithm is useful but not the same as releasing it into the wild which may require maintaining backwards compatibility, work arounds for bugs in other code or hardware bugs that can no longer be fixed at the foundry - the list goes on.

The vast majority of work programmers do 10X or otherwise is not greenfield where you get to pick the programming language you have 10K hours of experience using, the best hardware or an unlimited budget of money and time.

Now I would consider Dr Norvig a 10X educator. That program demonstrates how a decent knowledge of algorithms and math can take a relatively complex problem and make it tractable.

Yeah, he was at Google at the time (https://norvig.com/resume.html) so he was probably involved in the original development of the thing he was making a demo of.

He's definitely smarter than me with that CV but this particular project doesn't seem like some insane productivity achievement.

Uncle Bob tried and failed to use his own strategy of many small functions to solve sudoku. There’s been a lot of Trough of Disillusionment talk about him lately. My impression of him is that he’s got the right code organization idea but for the wrong reasons, and so his ends often don’t justify his means. It’s a common pattern in software to guess the wrong reasons why something works, and then overfitting to the wrong reasons.

I guess it’s worth pointing out that he does support one of the arguments the article makes:

> But they didn't, and come to think of it, why should they know about something so far outisde their specialty?

So yeah, he’s implicitly saying, “I have a lot of domain knowledge here.”

But that said: wow, that code is so concise and elegant, it gives me tingles. If anyone IS a 10x engineer, it’d surely have to be Norvig.

this is crucial. from my own productivity I know that I can function at 1X or 10X depending on my focus.

being a great engineer requires practice most of all, and the consistency of focus during that practice will impact its value.

in my experience, engineering is all about efficiency, and as i have developed over time the scope of factors i take into account when calculating the efficiency of something has increased. in the beginning i only looked at the technical details of the implementation, and then over time that expanded to considering maintainability, team co-ordination, business objectives, etc.

the potential scope here is unlimited. when you start, just making something compile takes all of your focus, but over time as programming becomes reflexive you are able to expand the factors you take into account far beyond the immediate code, and it seems trivial by comparison.

See, that’s a problem.

Engineering is all about effectiveness. Not efficiency.

Focus is great for slamming out a bunch of code that everybody else hates and has to tiptoe around you about because focus also made you so goddamned proud of your monster. Slow down and check the signposts before following your good intentions all the way to the end.

A null engineer is an inf engineer.

It took you 4 times as long to bring value to the company, you had lot of enthusiasm but were not using it right.

Being a kX (k > 1) means that you need to work fewer hours to accomplish the same amount as an average developer. If you then got to spend more time to fix your stuff, that counts against your time budget.

If I’d had this perspective the day before I would have been finished before 5. But I got wrapped up in thinking I was close and I should have stopped for air.

https://www.youtube.com/watch?v=YgL8fpya8BA

No we won’t do that, but we can do this. Or that is trickier than it sounds but we will think about it until it makes sense.

You are part of the toxic culture until you realized that was that it is overall counterproductive. Collectively we software developers are to blame and no one else.

I think that the idea of having people (at startups) working at a frenetic pace is because

1. The VC money is running low 2. Being first to market used to be a major determining factor on whether the product would succeed or fail

One time I worked so many hours I lost vision (temporarily) in my eye - called cotton wool spots. I was a generally healthy younger guy. Working this way has health effects. If in fact there is such a thing as 10x engineer - how long do you think you will stay 10X once your health deteriorates. Just my 2 cents.

What would a 10x engineer do at any of these companies pushing bloat in their products? How do you keep the software clean even as it becomes successful, millions of dollars and jobs change the ethos of your organization, but you are tasked with preser ving.

A 10x engineer at msft would have avoided notepad being modified.

A 10x engineer knows how to stop the forces that be, from adding an "ai" feature, where it clearly doesn't belong.

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!

From my life experience, the claimed statement actually does have some truth in it: software engineers experience a lot more bullshit marketing than other professions that require skepticism and analytical thinking, thus they, in my experience, have indeed become more immune to exaggerated marketing claims.

Also it fits my experience that software engineers are much more vocal about calling out bullshit (just consider the "bullshit bingo" game) than other professions that require skepticism and analytical thinking, thus based on the audience reactions alone, any salesman would likely indeed come to the conclusion that software engineers are the most skeptical audience.

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.

A software engineer having no idea how to build something doesn’t make it novel, it just indicates inexperience or ignorance in all but a vanishingly small number of cases.

In practical systems, you won’t find much novelty outside the rare frontiers of performance optimization, systems software architecture, the occasional bit of weird silicon with unusual computational properties, and some narrow algorithm domains that have never been adequately developed e.g. compression and AI. Almost no software development can justify even thinking about these types of things and they virtually never do.

Conventional engineering is worse because the laws of physics constrain almost everything to boring well-explored solutions. In some cases, we’ve pretty much done exhaustive exploration of what is possible.

Google has something 25,000 developers. You think Google has 5,000 people working on novel design spaces? That number sound way, way too high. By at least an order of magnitude.

And Google at least has customer facing technology compared to the thousands of companies whose developers only work is, say, integrating HR systems or deploying SAP or maintaining some legacy billing system.

Yes.

Maintaining a bridge is in general not novel. There are clearly established best practices that have stood the test of time.

Maintaining a ridiculous tangle of millions of lines of code is novel. There are no best practices on par with other engineering fields. We are at the stage of rough heuristics in most parts of software dev.

One day there will be broad and consistent over time agreement on how to handle large software projects. But we aren't there yet.

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.

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.

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.

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

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!

    > well known toxic field, finance

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.

The processes surrounding development often strike me as haphazard, cargo-cult like behavior, and entirely subjective.

Regarding people not remembering stuff--yeah that's probably true, but there's a lot a typical developer has to jump between--do people really get to "specialize" in JUST like writing Java CRUD or something anymore?

Feel like there's always also troubleshooting some Docker thing, some cloud provider, some build system, some pipeline etc etc.

When there's no stability and moving targets, maybe you're not incentivized to be a "specialist" on a language or whatever (this might also be painting oneself into a corner for their career) given how easy information retrieval is today?

RE: the scenario

Is this real?

I've never been employed at any sort of fancy role but I've never encountered this kind of thing (publicly) involving me, and I generally get on well with others, so I assume I'd have seen it by now

I'm sure plenty of programmers pasta from LLMs constantly now, but I've never had bizarre low-hanging "what do" inquiries.

Most people have some discipline and structure when asking questions:

- I'm attempting to integrate library x into the project - I've done the following and the build fails in CI with $ERROR - I've checked x, y, z - Have you encountered something similar?

This indicates some level of actual understanding of how things work, or prerequisite research prior to asking.

Also, where can I get a job where they hire people this minimally competent? I'm seriously burnt out and this seems like a nice change of pace.

I'm totally serious with that question.

The weird thing is, at a high performing organization it's relatively straight forward to get a job: be very good at what you do and practice for their hiring process.

At a dysfunctional organization there's not really a way to get hired (apart from an internal recommendation). This is almost by definition, as their hiring process doesn't measure anything reliably. Being physically attractive or charismatic helps a lot.

Actually this gives me an interesting idea, can you measure the quality of an engineering team purely by how ugly they are? My hypothesis is that a dysfunctional team has a low ability to measure aptitude, and so things like physical attractiveness will have a higher impact on hiring decisions.

I don't blame you for wanting a nice stint in one of these dysfunctional companies, I think I could have worked an hour a week and been praised as a top performer at the ones I unfortunately spent time at. I think if you do go this direction you should get 2 or 3 such jobs. It's only a tiny bit more work, and these companies tend to just stop existing some random Tuesday.

I too have been nothing short of perpetually shocked at how dysfunctional a large part of the software industry is. This is why I'm never able to take the "engineering" moniker seriously when people talk about programming.

The hiring process is so maddening and I'm glad you said that.

I get that resume scanning and what not is fully automated and makes no allusion to being a useful nor functioning process, but I'm perpetually amazed as I submit resumes (where I meet or exceed every "requirement") to companies I know are not well-functioning organizations only to be rewarded with an automated rejection email minutes later.

How many years of experience do you have? and how many languages have you written code in? Include all languages where you tweaked or wrote even a single line of code.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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?