I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field.
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.
>These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor.
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
I don't think it "attracted" a certain kind of people, I think the people who were already in tech just became more wealthy and powerful, and that, predictably, brought out the worst in some. The worst qualities of "tech" people can be conflated but I think have a different flavor than the worst qualities of "finance" people. It's really just the same obnoxious behavior you can spot in young tech people. Some people grow out of it, and some people earn a ton of money and so have no reason to grow out of anything (not that you can't make money AND grow out of it, but there's less outside pressure to do so).
No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is [software engineering vs business development] and how to approach it [optimal solution vs soonest deliverable].
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.
This is what happens anytime a field gets large in terms of job applications. Replace software engineer with anything else to that measure and you see the same things with wealthy families being overrepresented in the cohort because they always have an edge in getting the best credentials due to not having to work any part time jobs and having mom and dad (or even a paid advisor) actively working on your behalf to vet potential internships or other opportunities for you. You are essentially out numbered 3:1 or even 4:1 or more, and you can't work a full 1 part anyhow due to the aforementioned other obligations life has saddled on you.
I doubt that has anything to do with getting "large in terms of job applications" alone. It's a correlation, alright, because wealthy families have it easier to get high-status and high-paying jobs for their kids, and if such a field grows, wealthy people flock to it like everyone else. But I sincerely doubt you'll find the wealthy over-represented in physical labor / blue collar jobs, regardless of how the ups and downs in the labor market for those occupations.
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.
> It's a correlation, alright, because wealthy families have it easier to get high-status and high-paying jobs for their kids
You have just written down a partial solution to this dilemma: make these high-paying jobs less attractive in terms of status for these wealthy families. :-)
I completely agree. Software engineering is just the most recent field I can think of(unless you consider data science a distinct enough portion of software to carve off as a separate field) that has had this pattern occur.
Well that and this is a forum for a lot of tech people which means a good number of software engineers here.
Speaking as an old school basement nerd (coding since middle school, 90’s): If I can do cool things with code _and_ get paid, I’m gonna go do that. Business constraints make it feel much more interesting than writing code in a vacuum.
That's quite nice! You may wish to look into implementing a PID controller, so as to avoid overshoot (your carrots become too thawed initially) and unnecessary oscillation about the setpoint (meaning you are wasting energy on cooling and heating cycles that in the end cancel each other out, where you could have kept the temperature nearly constant during that time). I loved juicing carrots so much my face turned orange from the beta-carotene.
> No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is
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.
> 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.
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
>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.
And that's why all applications are laggy as shit these days.
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.
On the other hand, I've seen developers who don't know about things like that start up a project on a small instance and wonder why everything is running at turtle speed.
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"
I definitely agree with the greybeards and I think we see the results of not listening to them. We have these processors, buses, networks, and all sorts that are magnitudes faster and more powerful than what they began on but many things are quite slow today. Worse, it seems to but getting slower. There is a lot of value in learning about things like caching and memory management. A lot of monetary value. It's amazing to me that these days your average undergraduate isn't coming out of a computer science degree being well versed and comfortable writing parallelized code, given that is how the hardware has moved. It is amazing to me we don't normalize caching considering a big change that was driven from the mobile computing side and adopted into our desktop and laptop environments is to fill ram because you might as well. It is crazy to me that we have these games that cost hundreds of millions of dollars to develop that are buggy as shit, hog all the resources of your machine, and can barely run at 4k60. Where you can hit a bug and go "yep, I know what's causing that memory error"
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
As the base reality of computers and the inflated reality of software have diverged more and more, education and culture has tracked the software story and led to runaway irresponsibility. Forget not optimizing for performance; I think a lot of software today straight up fails to actually serve users some way or another. And those are paying users at that!
I agree. There are just too many obvious low hanging fruits. So I'm just trying to inspire people to take action and fix stuff. Ask not for permission, just fix it. Ask for forgiveness later.
As a fun anecdote I think this same rationale - ”next years hardware is so much better” - is why so many desktop softwares 90’s->00’s became slow - ”meh you don’t have to care about performance, next year’s cpu is going to be so much faster anyway”.
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.
You're not wrong but this is overly reductive. In other words this is more of a sliding scale and not a step function centered on 10-15 years ago.
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.
This post is so weird on so many levels. I'll focus on this part:
> 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.
So, you reach for class warfare? Sheesh. It is anyone's fault that they are born into an upper middle class family? Are people from lower economic circumstances somehow superior, as you imply? This is just bizarre.
As a reminder: Bill Gates, who is certainly old school tech, was born and raised in an objectively wealthy, well-connected family, then went to Harvard. This is nearly made-for-TV silver spoon stuff.
It is telling that you considered their post to be about class warfare rather than different values.
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.
As the sibling comment noted, I think you might be projecting value judgment onto value distinction.
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.
> So, you reach for class warfare? Sheesh. It is anyone's fault that they are born into an upper middle class family? Are people from lower economic circumstances somehow superior, as you imply?
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.
A slight addition to this topic. A lot of jobs also became software, even if your intention in signing up for the jobs was different to begin with. 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?
Frankly a shame. Since there's a been a lot of development in mining technologies over the years.
Even for the folks that have an ecological focus, there's quite a few methods developed with limited degradation of the landscape, and reclamation of the mining sites into alternative uses (park, forestry, entertainment, tourism). The Wieliczka saltmine in Poland's an especially impressive example [1]
And these days, there's also a huge number of resources in terms of mineral identification and site mapping. The EMIT Imaging Spectrometer from NASA's a cool example that does remote satelite mineral identification from orbit. [2]
It's a "yes and" situation. You're completely correct that people who were already in tech just became more wealthy, but there's no question that in the mid to late teens (in particular), tech fundamentally became, for many, about $$$. There was a huge migration of people who couldn't write code from NY to SF in a "there's gold in them thar hills" kind of way.
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.
Same kind of thing happened in the early 2000's, when the Web suddenly took off.
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.
Yes but imo this change happened no later than late 90s. I distinctly remember how suddenly it became cool to be a programmer and the 'new type' was already making changes by early '00s. And yes, the $s attracted smart people who did not embody the old hacker ethos.
These are the new bloods that gifted us with surveillance tech, btw.
The behavior you're describing definitely happened but what I'm describing did as well.
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
People in the trades relatively speaking in the midwest are easily far more wealthy than engineers in the bay area, and they have no such delusions of grandeur seemingly. They seem to understand that an electrician is an electrician and an engineer is fungible. That is why many of these engineers are unionized as well because they understand labor is replaceable and needs to advocate for itself. The coasts have much to learn from the corn lands it seems despite the prevailing narrative being the opposite.
1. The data absolutely does not show that midwestern tradesmen are wealthier than Bay Area engineers.
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.
The data does show that if you look at what cost of living is buying you in the midwest versus the bay. New construction large homes on large lots are in reach. Multiple vehicles are in reach. Everything is in reach after that. I'm sorry but the housing stock in the bay is just poor quality for what it is. The lots are tiny barely larger than the home. The home is small. The bedrooms are small. Most you can do is tear out the old chicken wire and plaster building and build a big ugly modern glass/cement box to the edges of the property line and even then you are slumming it in terms of space to what you'd have in the midwest. You want actual property, with some setbacking from your neigbors, and still convenient to things, its just not really available even if you had the money. Like those homes on pinehill or robin road in san mateo would be the caliber i'm talking about you can buy as a tradie in the midwest, in terms of setback and square footage, even finishes too for that matter. and that land in the midwest will actually be relatively flat and probably cleared out for you vs it being a home tucked in high slope chaparral you might technically own but can't really do anything with like build outlaying buildings.
You could have an indoor pool in a detached building. You could keep horses. You could have a 6 car garage. All the upgrades from the builder too. All for a song in comparison to a home a fraction of all that in the bay. I mean just start looking on zillow between these sorts of homes in say indiana or ohio and it is absurd the difference in cost of living. How much you'd have to pay to rent a tiny old boat on lake tahoe for the day vs buying a boat outright and even paying to winterize and store it in a yacht club on a great lake. SF country club fees vs midwest, literally exclusive fuck you old money rates vs only a couple thousand initiation fee for the same sort of course conditions and probably a nicer appointed newer constructed clubhouse in the midwest. Same is true for the private schools too, the nicest ones nationally recognized in the area can only charge so much because there's just so many people with kids and wealth in the private school market so they aren't absolutely stupid like in the bay. Even the public schools go up to bat with those in some districts.
I don't think "the data" you might cite are considering all of these factors of the lived experience. Maybe one or two economic indicators but not how life actually plays out with even the half dozen or so things I've laid out above.
> The data does show that if you look at what cost of living is buying you in the midwest versus the bay
But that is blatantly not wealth? For a topic so humorously numerical, this entire comment is decided not.
> You want actual property, with some setbacking from your neigbors
First, not everyone wants these things, and even quality-of-life is not one size fits all. Second, this is also not what wealth is.
> You could have an indoor pool in a detached building. You could keep horses. You could have a 6 car garage. All the upgrades from the builder too. All for a song in comparison to a home a fraction of all that in the bay.
Uh, duh the midwest is cheaper than the most economically productive region in human history. Thanks for explaining.
As an ex-Cleveland resident who now lives in San Francisco, I can confidently say that these trappings are not available to most midwesterners nor Californians; neither tradesmen not high skill workers; and its also still not wealth, although it is certainly more closely correlated.
Anecdotally, you couldn't pay me to own a horse, nor do I even have use for my single car - owning 6 seems like a waste when on-demand self-driving vehicles will shuttle me effortlessly around San Francisco.
> I don't think "the data" you might cite are considering all of these factors of the lived experience
Because that's not what the words in this conversation mean.
> Maybe one or two economic indicators
That's what these it means. And they're not in the favor of a tradesman in the midwest.
> not how life actually plays out with even the half dozen or so things I've laid out above.
But what you laid out (quite condescendingly btw) is farcically not the meaning of wealth, and not the indicators of a good quality of life. I can name a long list of things that the midwest can't provide to the wealthy that are readily available to working class people in California (eg. an extra 100 days of sunlight a year). But I won't because it's obvious and not the definition of wealth.
Despite where they are now, the FAANG founders could sling some amount of code back in the day.
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
Out of 10 richest people of the world, 8 have background in software engineering. Musk, Zuck, Bezos, Ellison, Gates, Page, Brin, Ballmer. Only Buffet and Arnault are exceptions.
Pretty sure he was explicitly brought on by Gates and Allen because he was a non-technical MBA type, and Microsoft had grown to the point where they needed one of those.
Sort of tracks with the Welchian bullshit he seems to have supported as CEO.
The story is that the reason Boeing got eaten by McDonnell Douglas is because the MD execs were meaner than the Boeing execs and they used their sharp elbows to take over a company that was objectively doing better than they were. And it started showing signs of unravelling on the first airplane they built under the new regime and has only gotten worse since.
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.
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.
"All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions."
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
I say this as someone who loves software: software is not special.
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.
Not op, but I'm clearly reading their message differently than you.
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 graduated in Electrical Engineering but have worked as a Software Engineer for the last 20 years.
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.
Software "design space is high dimensional" is true in that storage, latencies, processors, memory we just keep growing and growing. Given that, software should be faster and better than ever because the dimension where software lives has gotten exponentially larger and more performant. Rather than use that like responsible engineers we all started writing bloatware because it was easy and we could get away with it.
Engineering with constraints builds discipline. Maybe we are lacking as engineers in software because the constraint bar just continues to raise.
The power of software is not tied to processing power or memory, although those help a lot. Code is the deciding factor, not quite because it can be laid out wherever and have far reaching effects, but for the underlying basis for code. Software is all about leaky abstractions. It's not quite math or any sort of empirical engineering. Software models entire worlds. Excel is "just" people churning out calculations from paper spreadsheets, except now you just see the results on a screen. Pong is a ping-pong game. But I used the word "leaky" before. "All models are wrong, but some are useful."
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.
There's software engineering work and then there's programming.
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.
Thanks, I edited to assume the best interpretation of the thread.
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
Since I’m already in the thread defending you against the other poster, I’ll add here
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 say this as someone who loves software: software is not special.
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 :)
A big reason I switched into software is the fast iteration time. Designing machinery takes a very long time before one see's results. But with software, it's overnight.
There is a discipline, it's just very fast-growing. Many techniques remain and become classics, it just takes awhile to realize what is fad vs classical.
It was somewhat common in the 1970s and before for programming languages to support abbreviating variable names when you referenced them. So for example, you could say
patients = 400
x = pat / 2
And x would be 200. This seems like an obvious footgun today and I don't think any language designer would even consider it, but it seemed to make sense for a while.
Were they actually supporting abbreviating or just doing something like only storing the first 3 characters of the name? That feels more like something a compiler trying to fit in 8k of RAM or whatever would do.
If the compiler truncates, x will be 2 (assuming it allows variable reassignment), and you've probably introduced at least two bugs. It's doing some sort of lookup against the source, well, all bets are really off.
“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.
I would disagree about TDD. I am continuously surprised when I learn that yet another one of my teammates practices TDD. TL;DR: TDD is dead; long live TDD. I think that TDD will remain viable in enterprise programmer for decades, perhaps permanently, thanks to "vibe-coding", where LLMs eventually produce most code for CRUD projects (the vast majority of enterprise programming).
Yes, exactly this. I never bought into TDD, but I can understand that it brings comfort for many normie enterprise CRUD developers... of which I am one myself!
I despise it because I've seen some absolutely HORRIBLE designs that excessively separate concerns (that are actually linked and shouldn't be) in the name of "testability". I would rather maintain 50 lines of clear idiomatic code than 1000 lines of TDD code salad full of 3 line functions that each take a bunch of fragile mocks.
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.
I think maybe this misses the mark. Yes software can lead to unbounded complexity unlikely many physics based engineering disciplines.
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.
>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.
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.
I think you just made my point. If designing an eScooter you'd look at available power needed across the problem space. Even more so you might put in a safety features like a temperature monitor so electronic components don't fail because someone decided to go up a steep 12 mile mountain path and overheat the battery.
If I was designing a software system, I could introduce a time constraint. An imagined conversation:
"How long will it take to get an answer?
Between half a second and the heat death of the universe.
OK. Can we just issue a timeout error after 1 second?"
This is putting controls in place so the system doesn't exceed its constraints and although hypothetical it might be able to do a job for any input, it can't because we haven't been able to find a more efficient solution for certain known and unknown scenarios.
And then you quickly find out that the turing machine on your lap doesn't actually have infinite tape. Do you honestly believe that there's no other human endeavor where you can DoS yourself?
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.
> engineering where constraints are non-negotiable
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).
I do a lot of data engineering work, and people are horrified to learn how much costs increase as you go from daily/hourly batch jobs to real time or near real time streaming. Seems like a tweak but it does sometimes incur massive cost increases.
This is why I prefer to liken software to crafting a novel. You come up with a nice self-contained story, a clear story arc with a hero and a villain and a good ending.
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.
There is an incredibly large space for decisions and belief systems in software that are not evidence-based but that can all lead to programs (in the general sense) that all function and produce the same results while being internally very different.
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).
Both software and physical engineering can hide junk. It just depends on who is looking. There are plenty of products made that are junk. If you start to understand how products actually come to fruition in the business world, you will see that most of what we buy or sell or see marketed is actually junk. This is because engineering both in software and in the physical world is rarely, if ever, incentivized to seek out a perfectly optimal solution. What is able to generate profit sufficiently over costs, today with today's economic context, is what ends up getting shipped in both cases. That might change tomorrow and suddenly the product is not viable due to the costs of the junk associated with it. We talk about legacy code and how it is junk we are beholden to, go ahead and look at the engineering behind car designs and you will see there are legacy engines, legacy car platforms that people are similarly beholden to no different than legacy code people are afraid to touch. And that is just that one sector. Legacy engineering is present in everything you can conceive of due to the fact no one is paid to go off into the woods and optimize optimize optimize, only to ship by a deadline even if it a stinking pile of you know what. That is for sales to figure out.
> 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.
I think that you have a basic grasp of the word "dimension" but use the word "euclidean" without understanding what it means just because you heard it in conjunction with "dimension".
If you think that e.g. building a bridge is a three dimensional problem in the sense that you are actually talking about (which has nothing to do with euclidean geometry), you lack the basic understanding of what you are talking about from which you could draw any conclusion like that with any sense of intellectual honesty.
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.
I do agree that you can hide a lot of shit in code. But I think something often overlooked is that code is simply text, and we have general rules on how to write good text. Code is in the end of the day basically applied philosophy and expression of ideas.
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.
I do agree that software is by far the most complex things humans have created and much of that complexity is hidden.
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.
This comment is weird, but typical of HN. Most of the off-balance-sheet shenanigans of pre-2008 world are gone. There is now a global regulator that covers all systemically important financial institutions, that also includes very large insurers. The world of financial engineering is much lower risk and higher transparency than pre-2008.
You say shenanigans don't really happen, I posit they are routine in business and consultants are paid a lot of money to uncover the next shenanigan every day. The law is always lagging the action it is designed to stymie and we certainly don't have a utopia going on outside the window today.
> Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious
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.
I personally though it was a very interesting analogy.
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.
> However, when designing real world things, economics rapidly culls the design tree
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.
I was once considered a 10X. I would work all night. Rewrite code simply because I found it objectionable - lots of things I'd never do now. Mostly after working those long hours I return after a long rest and spend most of my time fixing all the new and ridiculous problems I created while working tired. Things may have gotten done a little faster. Never once did it even matter - there was no material benefit to the company. Projects still got canceled - team deadlines still missed - products still had bugs - company focus changed blah blah blah.
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.
Tbh this seems to be implementing a demo of something he had complete understanding of prior.
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.
Yes - Dr Norvig is exactly the type of expert I would often engage to figure out difficult problems. Ask him how to configure a Nomad cluster and he would likely say "What is a Nomad cluster do?"
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.
Just because he's brilliant at writing green field code to solve problems like this one, doesn't imply he's incapable of producing production code when required.
Never meant to imply that he could not. He is a far more accomplished programmer than myself. Simply pointing out that he is an expert and his skill set is unique and in someways quite specialized. He may be considered 10X in his domain - maybe not so much outside of it. Programmer/Software Engineer are broad terms.
I use his sudoku solver design to learn new languages and as an example of intrinsic versus accidental complexity.
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.
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.
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.
effectiveness, professionally, is creating value for your clients and employers. the ratio of value to cost is how efficient you are as an engineer. it is all efficiency.
I think you need to pay more attention to the contexts in which your coworkers and bosses use the word efficiency. You’ve got a good definition there but you’re not often in good company.
To management the two directions look the same. They probably held a ceremonially ritual where they fired the person who was dragging things back 1x in the right direction.
My experience is that people tend to fill the time they give themselves to do things. Give yourself 12 you take 12 hours. But humans have a limit to the focused productive work they can do. Lets say it is 4 hours. So of that 12 hr - 4 was really productive and 8 not so much. When I was at my tiredest I often spent hours trying to debug issues that literally took me minutes when I was rested.
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.
3. There's always that one person whose only ability to contribute is to cheerlead the others... and some nerdy types take a long time to figure out you don't need to listen to them or tie your fate to them.
If you work twice as long as most, make code which is dubious/broken, take initiative out of sheer personal opinions and have to spend time the next day fixing your mess, that would be the definition of a 0.25X programmer.
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.
10x is mostly theater. I’ve worked with 3x engineers that made everyone else better, and 3x engineers that make everyone else much worse. 4 times out of 5 a manager will point to the latter as 10x because he is getting so much more done than the people he has crippled and been loud about it the entire time. The former does well when their boss is that 1 in 5 person, but they are often fucked if the boss leaves.
This sounds like a management failure more than your failure. You should have had someone who would have steered you in the right direction, getting you to focus your energy on things that mattered.
I like to think of my ideal mythological 10x as someone that does less.
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.
I’ve had too many experiences of starting a project at noon on one day and getting fixated on finishing it and failing, then after some sleep and reflection ripped half of it out and finishing the new idea before lunch, which isn’t even my most productive time of day.
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.
>I was once considered a 10X. I would work all night.
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.
Couldn't agree more. I read a book (okay, I half read a book...I couldn't finish it, it was so bad) where the author (a marketer!) argued that software engineers are the most skeptical audience, and I was like, "Um, have you ever met an investigative journalist? Or people in the many many other professions that require skepticism and analytical thinking?"
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!
>
Couldn't agree more. I read a book (okay, I half read a book...I couldn't finish it, it was so bad) where the author (a marketer!) argued that software engineers are the most skeptical audience, and I was like, "Um, have you ever met an investigative journalist? Or people in the many many other professions that require skepticism and analytical thinking?"
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.
Very few software engineers are working in novel design spaces. Even 1:1000 is probably being generous. FWIW, this is true of conventional engineering too, but even more so.
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.
> The ratio of software engineers working in novel design spaces compared to plumbing style work is best guess ~1:5
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.
> You think Google has 5,000 people working on novel design spaces?
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.
Novelty is a byproduct of immaturity. To take another field that matured recently, mechanical and in particular aerospace. You can see a lot of crazy airplane designs from the 1920s through the 1940s. There was a lot of novelty back then and it was an exciting field to work in. Now airplane designs look very standard, and for good reason. The field matured and figured out the best and most economical designs. Novelty is a temporary state, and most novel designs are figuring out how not to do things.
I think one thing that is very different about software engineering is that it's the only form of engineering I'm aware of where a very substantial fraction of the people employed to do it lack basic fundamentals like "being able to do it". Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day. They don't have a sense of what makes sense and what is weird. They can't debug problems they run into without help.
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.
I don't think, excluding some scenarios at well-disciplined firms that anything like "engineering" exists in programming.
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've worked mostly in Silicon Valley. At bigger tech companies I found that the minimum level of competence is a bit higher, maybe because of the aggressive stack ranking and PIP/firing pressure. At small companies either low bar is very high, or it's nonexistent, I've seen both.
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.
I can confirm that some (30%?) mechanical and biomedical engineers follow the described problem "solving" strategy exactly. It's not just software engineers.
>Most software engineers can't write a program without google. They can't remember basic facts about the language they use every day.
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.
> I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field.
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.
I spend at least half of my best days working on making our bad days better.
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.
> something unique and different about software engineering
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.
This is exactly what the leads in my team not only thought but said to my face gratuitously. I'd be in my 69th hour of work on a Thursday and they would pass by my desk and say stuff like "what's important is not the time you dedicate to a task but that you complete it".
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.
I assume here that you mean investment banks, more specifically: M&A and capital markets, where the lion's share of profits are made by few people. Post-2008, the industry has cleaned-up so much. What is toxic about finance today?
>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.
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.
I always thought anyone can learn to program and gently scolded and encouraged the folks who would predictably say , “oh you do software? I could never do that. So complex.” No, I’d say, you definitely could!
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 ;)
There is something toxic about calling arbitrary things toxic.
>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.
> Then the only way to get stuff done is go 10x during the time you have whenever you have it.
I believe PP is correct: the cost of "going 10x" is greater than its benefit in the long run, and often in the short run.
Henry Ford lowered the Ford company work week from 48 hours to 40 hours to improve cars manufactured per labor-hour, and to give employees leisure time to drive places (increasing demand for cars). Wages were raised to compensate, further increasing loyalty to the company while enabling employees to buy more cars.
For software, a 40-hour week may not be optimal, I tend to think that it may be too high rather than too low.
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.
If it’s so easy and not unique, how come engineers with supposedly 7-10 years of experience, that I work with, write absolute braindead code that breaks if you sneeze at it?
Yet, it is trivial to find "competent engineer" in other fields and software engineering is filled with mediocre ones at best.
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.
I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B players hire C players etc. Building a team from the ground up is very much an iterative process of fighting complacency and mediocrity all day every day, and this guys pitch is just "give in, its not so bad".
In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 10x programmer, but only if you ignore everyone else on the team that allows the QB to shine. Same with software. Software is a team sport, and if you don't get that, you should get that.
> but great teams makes great software, not great individuals.
For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals along with the contributions of a small number of itinerant volunteers. While teamwork can be an important if fickle instrument, it tends to be a lightning rod for inviting too many cooks into the kitchen. What is often downplayed or goes unsaid in these commendations of teamwork is the place of an individual mind as the wellspring, the sine qua non, of great ideas and projects, including software. As is often the case, one person can solve an issue that has stumped thousands of others. Such individuals tend to work at a faster pace alone than the de facto committees that teams often become as they lose their agility, foresight, and focus. Unlike a football team, coding doesn't require a minimum number of people to achieve greatness. On the contrary, the opposite appears to be true - that there's a Dunbar's number for doing good work.
> 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.
that's a bad analogy because a single football player cannot ever deliver a match entirely on his own. A single developer can absolutely deliver a full product on his own, it's not inherently a team sport whatsoever. You could make this claim about many things, "blacksmithing is a team sport!" Nonsense.
While a single talented developer can conceptually complete a whole project (of some kind) on their own, the concrete reality is that they're often being tasked to do so in the context of some time and resource bounded opportunity.
There's only so much code they write per unit time, only so many designs they can consider, only so many meetings they can attend, only so many demonstrations they can perform, only so many regressions they can debug, and really, only so many domains they can master.
Solo projects written by excellent engineers can be stunning works of craft. Many of us prefer to work that way, and accept the compromises of scale or time that are associated with it.
But most projects that you're familiar with need a team to produce them in a way that meets their real-world time and resource requirements. That's where the sports analogy comes in.
(And the same is true for the blacksmith and tailor. One master blacksmith or tailor might do stunning work, but they can't outfit and army or dress a court ball on their own. They need support, and that support often needs to be of a different level of mastery than themselves, if for no reason but to facilitate needed coordination and deference.)
Nobody is seriously claiming that all work on earth can be done by individuals. Obviously the master blacksmith that designs and leads the outfitting of the entire king's army with superior weaponry thanks to his personal leadership and expertise and care ... is not hammering every sword himself. But to call it a team sport is also highly misleading and to say that he hasn't been x10 is also just flat out wrong.
I think it is more like an NBA situation where a single superstar player can pull up the whole team just look Nuggets but still most likely thing is that the Cavs, Boston, or OCK wins the championship because those teams have a superstar player + a great team.
The big question is, can we find counterexamples to your model of reality in actual reality. And if we can easily do that, what does your apparent over-confidence about your statement say about you?
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.
Fabrice Bellard is not a counterexample you think he is. He is brilliant, but he doesn't stick around the projects he starts off. Someone has to triage bugs, setup CI, tag releases, keep the website running and all the other boring stuff.
I have contributed to one of the projects he originally authored, and my mundane contributions along with other volunteers not as brilliant as him have ensured the continued success of the project. I'm with gp: teams ship software, not individuals. Individuals may ship bug-fixes or largish features, but for software in the large, that is the realm of teams.
I've been there & done that: I've been the person that crunches and turns around impossible situations, and I have also spent months cleaning up after a 10x engineer who shipped a feature in "record time" that made the company lots of money but caused countless support calls and bugfixes for months on end until it stabilized. Many so-called 10x aren't, and rely a lot on a supporting cast of regulars to enable their "outstanding" work
My main frustration with the person I was responding to is that a lot of the terms we are arguing about are ill-defined, and yet he's arguing them with a lot of vigor.
There is also a time dimension to software. I have been on some occasions the only developer of pieces software that were tackling hairy problems that teams of "normal" developers would avoid. I always wanted to solve those problems in a way that would make everyone's life easier. To do that I had to spend a ton of deep focus time on modeling the problems effectively, and if I was successful, people who were put off by the problem space would come and contribute, because they found the model amenable. Or they thought it'd benefit them to be a part of a project that's picking up steam. A lot of these people would fix small issues here and there, but some of them actually donated a lot of focus and helped take these projects to new levels. The ones making the deep changes always cared deeply about the problem space, or brought a lot of knowledge from another subset of cs, and I wouldn't call them "normal". I think it is a disservice to the sacrifices they made to do what nobody else felt like doing and throw a blanket statement like "teams of mundane contributors do the really important work".
This is not a dig at "normal" devs - I have been the "normal" dev on many projects, but because of my experiences I try to give credit where credit is due.
I also detest the 10x thing exactly for the reasons you pointed out.
Great teams are made of great individuals. All of the policies and trust and rituals and expectations are based on the performance of the bottom quintile of the team. If the bottom quintile of the team is still the top quintile of "engineers applicable to this problem" you will have a radically different and improved culture and performance than if the bottom quintile of the team is a median engineer, and especially a bottom quintile of "engineers applicable to solving this problem".
A great quarterback with an otherwise average team is still going to beat an average quarterback with an otherwise average team every time. That a team is more than the sum of its parts just means that adding great team members can lead to more overall gain than their skill alone would imply as they boost those around them.
Even in the examples he gives, I'm sure Linus would be the first to admit that Linux has a lot of maintainers that have been essential for the project.
Yeah, the OP is utterly delusional. Linus himself has said that he spends most of his day merging patches. Each subsystem, example: file system or USB, has multiple highly skilled owners/gate-keepers. I am sure that the file system gurus know far more about it than Linus does, and I say that with no disrespect to Linus.
There's truth to what you're saying, but just as in sports teams, you ultimately need a certain number of players to play the game and exceptional people characteristically have an ego that only allows so many of them in the locker room. If you have too many, they get starved for the individual recognition and validation they're used to receiving, leading to crises and clashes and quittings.
Unless your project's scale is reasonably small and focused -- representing the equivalent of a true solo or duo sport like tennis -- you need committed, professional "normal" team members to flesh out the team or you'll just never have enough resources to get done everything that needs to get done.
Comforting yet false assertions. Great engineers tire of working with “normal” engineers, they want to work with others who they respect. A team of only great engineers can have a completely different culture than a team of “normal engineers”. Teams of great engineers are magnets that attract others. Building a great team weirdly does not become harder over time, as your project is derisked you get access to larger and larger pools of talent. Talent concentration pays an enormous dividend and is a worthy investment. Maybe things change when you hit like Facebook/google scale, but at that point… we’ve won anyway, wouldn’t be arguing online anymore.
Even before you hit big scale, there's a lot of boring work that great engineers won't want to do. And what really makes someone a great engineer is the ability to transform a hard problem to something regular engineers can handle the rest of. So I agree that 10x engineers are real and it's often 2 out of 12, but all-star teams don't work, which is why those people often get moved to run new teams/projects instead.
The reason people aren't motivated to do boring work is because of a poor culture of ownership, it has nothing to do with skill or "10x" stuff. Having a team of only great people allows a much deeper culture of ownership and its much easier to get people to work on the boring stuff. Allstar teams absolutely work and are the best way to work.
Uhh, I think it's becsuse boring stuff is boring. If you start to do repetitive plumbing aren't much "greater" than the ones working assembly lines, no?
People who describe themselves as "great" feel such work is beneath one and know there's only so many hours on earth. Easier to pay a grunt to do that instead. And hence power dynamics are established.
That ego alone is why a team of only "great" engineers is bound to fail. You have a bunch of strong but negative polarity magnets trying to stick together. It simply won't be allowed.
Every team doesn't need to have "great" engineers; I don't want "clever" solutions to my bog standard business application, just people to write sane, clean and maintainable code.
This might be a definitions issue, but my assertion is not that a "great engineer" is someone who can complete leetcode hards in 15 minutes for 8 hours in a row without stopping. My assertion is that about 1 in 5 people have 5-10x the business impact of the median software developer, and if you are recruiting or managing a team you should have the goal of having your team be entirely composed of these top quintile folks. The article specifically says that you should not have this goal, and I extremely strongly disagree with that assertion in the article.
Some years ago, Google published a paper whose conclusion was that high-trust teams were the most productive - not the ones with the 10x developers. This obsession with the "great man" theory as applies to software is harmful to software engineering.
Computers are all about synergy and understanding the hardware you're working with. No one algorithm will work optimally on every chip. One of the harder problems is in. Fact getting optimal hardware use by coordinating multiple threads, chips, or entire clusters to work on the same problem together.
It's a shame some can't apply such metaphors tk humans and think "no, sure, there are single processors thst outperform entire distributed networks" we're different".
A great engineer isn't the one writing the most "brilliant" code; it's the one who understands the problem, picks the simplest solution that works, and makes life easier for the next person who touches it.
In my experience, the person you're describing is hardly ever the one perceived as having "5-10x business impact". Specifically, "making life easier for the next person who touches it" is unproductive use of company time.
Which is why I have learned to stay away from people who use that metric.
No, what's toxic is building an environment like 99% of companies where juniors are told that everybody is the same and there's no point doing anything other than copy pasting whatever dogshit the "senior" next to them is typing into VSCode.
Have you ever worked on large projects? I'm talking about projects which involve hundreds of people, thousands even, and those that stretch over many years.
In the grand scheme of things, the 10x-100x engineers work gets attenuated - think of it as some kind of averaging filter.
Do you think some 10x engineer carried the moon landing? or the Large Hadron Collider?
Sure, if you work on some dinky team single-digit number of workers, the contribution from the 10x engineer will be more apparent - but as the number of people involved increases, the more important the average is.
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.
10x is not literal - the origins is from the 60s, and stem from some study where the best engineer was found to be 10x more productive than the worst engineer.
Average, is of course relative to the sample. If some "elite" company only hires 10x engineers, there's likely not going to be any 10x engineers there. The most productive engineer will probably only be slightly more productive than the worst.
If some other company has zero standards for hiring, to a degree where you can basically pick anyone off the streets and put them to code, the best will probably Nx (where N is very large) more productive than the worst.
But even then, there are so many dimensions and aspects to this.
Being 10x as productive then has more to do with your position than your skills.
The Roman emperor could make or break entire regions by vaguely wagging a few fingers. If and when he made a good decision - which could often easily be attributed to good luck - he could be, and was, heralded as the best thing since sliced bread because he saved millions. Such power surely must be divine. I don't think so.
Not saying Linus or Guido aren't competent engineers. I'm just saying that I don't think they are the sliced bread many make them out to be. They are good. Lots of people are good, but not many people get to be the first to create Python.
And, to be frank, Python - and its ecosystem - and me are through the honeymoon phase. Let's just say the chemistry has worn off and I'm not quite so sure Guido is the net positive we think he is. Maybe Python replaced some other upcoming far superior language. We can't know. (I suspect it did.)
In general I don't think individual/personality worship is a net positive on any axis.
In a lot of cases, some of those who carry all the water are doing it to themselves, and it hurts the team (and themselves).
In the organization I work in we have an operations team to take care of day to day failure. Write a run book, set up ticketing, hand it off, good to go. I treat this work and hand off as a high priority, as it frees up my time to work on other things. The ones who are chronically busy and appear to be “carrying the water” don’t do it. Their time is dominated my support, they are constantly busy, and it looks like they are doing a lot… but they’re doing work that can and should be handed off.
I’ve been the water carrier as well, but always tried to skill up people any time I had the opportunity. Or I’d build tools to make it easier for people to help, or find a niche where they could be useful doing something that would really improve things that I either didn’t have the time or interest for.
you are not describing someone who is "carrying water for the team". Someone who is carrying water for the team is, for instance, working on reliability improvements so that the errors or things requiring support occur with less frequency. Its not about being busy, its about having impact.
You’re over optimizing for engineering skill. The majority of projects don’t need a team full of A players, and trying to get that is going to limit you.
Get rid of team members that make your life harder. Keep the ones that make it easier.
> Individuals ship software not teams
I can’t see how this is remotely true outside of contorting some definitions of “ship”.
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
so in every key project you've worked on, a one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"?
I think it says more about the size of the project and the complexity of the task that you've worked on, rather than "10x engineer vs normal engineer". Not even at a 10 person startup have I seen "one" person done everything. Unless you're talking about someone just forking OSS and gluing it together, to make a carbon-copy application of something that already exist(for free) then sure.
Edit:
>key person took charge and made it happen
person - singular.
made it happen - it's hard to call an engine a car. to make something happen, you need all the component (contributions).
> one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"?
I didn’t say that. Read it again.
It’s not even the same person every time, people trade off being that key person.
> I think it says more about the size of the project and the complexity of the task
You have no idea. Please address the ideas rather than making personal assumptions.
No, I’m optimizing for making customers happy. I dgaf about your ability to leetcode. I strongly care about the rate and quality of the things you ship to prod. This is what a 10x engineer does 10x of.
This comment is spot on. I would add that it's not only 1 super smart person, or only 2 people per team, it's a power law. 1 person does the most, a few people do almost as much, then you start getting out into the tail of "normal" people. You can try to hard partition the tail and create an 80/20 rule, but it's fundamentally continuous, and the shape parameter will be different for each organization.
Understanding this distribution of productivity is a great litmus test for a manager. If they say the distribution of productivity is shaped much differently than this, that is a red flag. They probably can't tell who is contributing, and you can't trust them to do the basic functions of hire, retain, fire.
The article reads like it was written by a manager with tunnel vision. A manager's value-add comes from making a bunch of "normal" people productive, while staying out of the way of the few engineers who will deliver >50% of the value anyways. If you only focus on making the normal people productive, you are only doing the additive part of your job, and neglecting the negative part, which is to recognize and not interfere with the high performers. I would imagine this guy goes around creating lots of least-common-denominator systems/processes, which drive away talent and make the high performers less productive.
IME people who say this in the workplace tend to overestimate the importance of one aspect (usually the product development itself) and ignore the importance of things like taking a product to manufacturing, getting technical costing under control, or adapting to user needs. There's a lot of fluff in the article, but this part in the conclusion and your statements about "A people hiring A people" or the example of Linus' place in the kernel all align:
> It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams
There's plenty of otherwise "10x" programmers who go outside of their strengths and suffer for it.
Thank you. Every software is essentially being built by a few greats fighting against a dozen morons. 10x doesn't even get close to reality.
We're currently in deep shit because a long term dev was under the assumption that you can only instantiate objects once. He built an insanely complex system around the belief, which shipped. Our users used that system to write configuration files that now drive a machine that cost about half a billion dollars. So we can barely change anything because the data must be supported for 25 years.
The cost of such fools is orders of magnitude higher than their salary. I'm convinced that the world would be a better place without bad devs. Everything would be faster with less people, too.
The skill gradient is steep. Broadly speaking a top quintile dev will have 5-10x the productivity of the median dev, but only 110-150% of their salary. A bottom quintile dev will have zero impact, negative impact, or .1x impact relative to a median. The goal is to have the top quintile for your project, whether that is product engineers working on b2b saas, or graphics devs working on improvements to game rendering.
I think this varies a lot with the type of software you’re building and composition of the team. If you are making a very typical CRUD web app in a structured environment (eg a shop that cranks these out one after another, or with strong project/product managers and designers who do a good job speccing things out) you do not need some rockstar 10xer to get it shipped. In fact, that kind of environment might bore or not be rewarding enough for someone like that to stick around even if they do show up.
But you still need people to actually care about their work and get it done even when it’s not “hard”. Someone who could be a solid engineer on one team could be a “10xer” on another team just from caring about the project and consistently putting in the hours on it, if their team is mostly coasting by doing the bare minimum or highly underskilled. In fact I think many so-called 10xers may just be solid engineers who found themselves in workplaces with a culture of “not my problem” or “I can probably stretch this ticket out a few weeks”.
Conversely if you take someone who might be a wizard on one team and drop them into some super complex “engineering catnip” project they might just be seen as a solid engineer there. I think cases like that demonstrate the author’s point pretty well: if you design the project’s processes and tooling around the wizard’s wizards who eg dont use debuggers because they have some insane skill with tracing running binaries you are missing out on the productivity you might gain from the less skilled engineers.
A lot of people will agree with you and a lot of people will disagree with you because the subject might as well be food and for some people that’s coleslaw and for others that’s master chef.
Both have their place. On the topic of greatness (your example, Linux, as opposed to say a build script for vending machine firmware) I couldn’t agree more with both you and the people disagreeing with you.
I don’t think I agree with your level of cynicism, but I definitely think my biggest enemy at work is complacency. I joined a company in the last few months, and it seems like this codebase lost the war against complacency years ago, and it’s such a hard hole to climb out of
I claim that being able to work alone or in a small high-performance team is a _luxery_. It's comparatively easy to be performant in those circumstances. The realities of business are what we are usually fighting.
The "complacency" and "mediocrity" you mention have deep roots in politics and human psychology and I'd wager less than 1% have anything to do with tech. One of the many things you do in a business is wrestling with such monsters as capitalism and its various types of dysfunction and a plethora of other nice human factors such as hunger for prestige, power and social status.
To give a concrete example: at the moment I am quite ineffectual at work and the core reason is that I just don't give a flying F. I wasn't always like this. I distinctly remember not being like this. I was made into this and I'm sick and tired to pretend it's actually my own fault.
It's sad to see us engineering types being herded by power hungry psychopaths into arenas where we fight eachother to the death like roosters to see who is the "10x".
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_.
While you may need an individual or two to carry things, you will also need other little things to get done that would slow down the "super stars". It's a team effort, always (when you get outside of personal projects).
when people talk about a players I feel like a lot of times it's really just the person who knows the project best or maybe they wrote a lot of the original code so they have the best idea of how it works. My point being who's an A player in my opinion is not reflective of actual skill per se but rather other factors.
Knowledge of the domain helps a lot! But software engineering and dev tools are also domains that are transferable. I have outperformed coworkers with much more code domain familiarity because I had more engineering/debugging/tooling domain performance, or better ability to design and communicate etc etc.
Or maybe they aren't pushing flaky shit into prod and actually thinking about their work. Maybe they did 1k lines (counting lines LOL!) of code reviews, fixed some bugs, helped on an outage etc. Fuck. This one dimensional view of things. Look how any company makes money. Let's say Google. It is not by the number of lines of code.
I don't know how many engineers and different engineering teams you've worked with. But I see this all the time.
I worked once with a young engineer that spent 3 weeks for 2 lines of code. We celebrated him as a fucking superstar, because those 2 lines were in a low-level linux library, and he went so deep to find that bug, it was insane. He earned the reputation as one of the top problem-solvers in a multi-hundred person org.
So that's not what I'm talking about. I'm talking about the developers (so many of them) who spend 2+ weeks in standups saying they're "working on automating the deployment", and when it's done you look at their code, and it's an argparse block followed by 6 lines of calling docker with trivial parameters. You've seriously never seen this? Lucky you, then.
When a developer takes weeks to come up with trivial code, they are not productive.
I understand that complex problems can (should) be solved with simple code. That's not what I'm talking about.
Simple problems should be solved with simple code, and good developers do this quickly. If someone takes 3 days to figure out how to make a one-line REST api to a well-documented service, they are not productive.
Maybe I just unfairly expect developers at top companies to be able to not get stuck at every step and to not get confused by basic programming. I probably just need to recalibrate and understand that what I consider to be slow developers (certainly by comparison to the many excellent people I've worked with), are actually the norm, and I should just be OK with that.
As a 10x engineer, hard disagree. The modern stack is just too large. Sure, building out an MVP can be done by one 10x engineer, because basically any prototype can be built by a single engineer. But making the UX aesthetically beautiful, adding a test suite (at least for automatic dependency updating), adding observability and alerting, performance optimization, persistence optimization, cost/deployment optimization, day-to-day maintenance automations, architecture and network diagrams, tutorial/how-to/explanation/reference documentation.... you are delusional if you think that can all be delivered, at consistently high quality, by a single engineer.
You can have a single genuinely senior 10x engineer oversee all those efforts, executed by "normal" engineers. But no, not execute them all by the 10x engineer's self.
It is teams in a functional organisation. Once everyone is performing then how you organise work: how you communicate complex ideas, how you order work, how you set up each other for success matters a whole deal.
If you measure something meaningful it's teams. If it's LOC or some macho measure of productivity (rewrites in Rust using the hardest frameworks) then yeah it's those "tenexxers".
When did IEEE become host to clickbait nonsense? This whole take feels like an editorial by a junior engineer going off vibes. It's all off-base, from the misunderstanding of how to measure productivity, to what output matters, to the idea that there is such a thing as a "normal" software engineer. It's kind of embarrassing.
Yeah, it's really a poor quality post, but these terrible arguments and affirmed my bias toward believing 10x engineers exist and there are many great reasons to want to continue hiring them.
Reasons why it's not a good idea to look for a "10x engineer":
- There is no "10x race horse", as there's different kinds of horses who win different kinds of races (and those horses don't win consistently). Similarly, "10x engineer" would imply there's only one kind of engineer, one kind of engineering, or only one way they can be productive. You can certainly find a "person who is very productive under certain circumstances". "10x engineer" is an extreme oversimplification of a generic person doing a generic job; but people aren't generic, and this job isn't generic. There just is no "10x engineer". It would be the coder equivalent of the Übermensch.
- It's not a good idea to bet the farm on one lone genius. They could get hit by a bus, be hired away somewhere else, or just not be "inspired" by your company or team and end up not producing. Instead build a team of competent and diverse individuals led by a decent leadership/management team who can create consistent results without having to find a magic wizard coder. (Personally, if I found out someone in my org was risking the business on a single person that was impossible to replace, I would be upset)
- There's just not that many super-talented people out there. The few that are, pick where they want to work; you don't hire them, they hire you, so to speak. And even when you think you've met one, it may actually just be bluster or a false reputation.
The flaw in this article is the assumption that 10x engineers are just more productive, and several "normal engineers" can do the work of a 10x engineer. This may be true if you're building "normal software".
But for certain kinds of software development, a team of "normal engineers" can't do what a single 10x engineer can do. For example, how many "normal engineers" would you need to replace an Ilya Sutskever? The answer is you can't. Because intelligence is not stackable.
How many companies out there genuinely need an Ilya Sutskever to achieve their goals? Everything in this article is accurate for the 99.9% of companies and teams that aren't working at the bleeding edge of the industry. The mythical "10x engineer" is always a net negative on teams building a boring CRUD app. You always want a handful of "normal" engineers instead.
Intelligence is the easy part. That’s not what makes a 10x engineer. The 10x comes from consistency, persistence, creativity, resourcefulness, patience, focus, communication, drive, empathy, and a bunch of other traits that are rarely found all together in a single individual.
No, intelligence is not the easy part. We are talking about uncommon intelligence and it is the hard part. And they ones that have it are often lacking in other areas, such as social skills. And the ones that have social skills, and other traits often aren't 10x.
Put it this way: of the handful of 10x engineers I’ve met in my life, it was never intelligence that was the differentiator or what impressed me. That’s a commodity as far as I’m concerned. Once you pass 140 IQ it’s mostly diminishing returns, compared to the outsized impact of the other dimensions. It’s always been the persistence and consistency that has stood out the most to me.
> For example, how many "normal engineers" would you need to replace an Ilya Sutskever?
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.
There are plenty of hard problems that are unrelated to scientific research where you need more than just "normal" engineers. Look at the number of failed projects at big companies such as Amazon and Microsoft, they failed because "normal" engineers couldn't pull it off.
hah. i'm sorry but this is extremely naive. projects don't succeed of fail solely on the technical chops of the engineers. it's a whole "ecosystem" that has to work and most projects I've seen failing are due to politics/bikeshedding at upper management level.
Your experience is different from mine. I have worked at big tech companies and have seen too many projects fail due to lack of technical chops. Do they fail for other reasons too? Sure, such as not finding product-market fit, but at some companies they start with guaranteed product-market fit because they are copying a competitor!
> 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
Systems thinking isn't a political belief, it's a model for the world that is incredibly useful in a lot of contexts. Some political factions may be more likely to engage in systems thinking than others, but that doesn't make it a political topic.
my rule of thumb is that the average startup has no more than one novel piece of code, and it is usually one of the first things written. Then after that there’s enough plumbing and UI work to keep a few hundred regular engineers busy
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.
Someone imagining they are brilliant doesn’t make them brilliant.
More so if in the light of day their work sucks.
Discussions about 10x engineers are not about “wannabe 10x engineers”.
—
I have yet to come across an intellectual area where there isn’t a long tail of higher talent.
As the “x” goes up they just get more rare in reality, and even rarer to see. Because they are not always being optimally challenged. Most problems are mundane. And optimally challenging workers isn’t really a business plan for anything.
I think there is such thing as a 10x problem, which you have to find before your 10x engineer really shines. Identifying hard but exceptionally valuable problems to solve takes 10x vision. And time and luck.
If by “create some” you mean “Identify a major new revenue stream” or “Investigate something everyone else considers great, improve it 10x and save hundreds of millions of dollars”, then yeah, that’s what I do.
I've seen more of what someone called "wannabe 10x" making a career of turning non-10x problems into a series of 2 year Greenfield project pitches and failures to launch across multiple firms. You can actually see people pull this off for 6-10 years before they need to do something more productive.
Oh for sure. I’ve seen people get promoted based off the possibility of the bullshit idea they’ve come up with, and then move on before reality kicks in.
Wait... "Most" 1x engineers? "Most" in any profession will be average. Which is completely normal and fine.
This kind of reply is just flipping the stereotype and going in another insane extreme without any evidence at all, just conflating productivity with recklessness...
Their very next line also used "Most 10x engineers". Neither of those are talking about "most" in the profession, it's "most" in the subgroup. Average in the profession will be somewhere in between.
If 1x is the absolute rock-bottom lowest possible productivity, are them really the precious angels who care deeply about the user while making amazing code?
Are there any open source repositories where this is an example? I keep hearing the 10x people ruin everything but I wouldn’t call that person 10x. I don’t understand how it’s objectionable that some people are more productive than others.
I have a buddy that helped me out with some DIY/construction projects. He thinks he is a 10x as well since he gets so much done so quickly. He will finish up and sit down saying its done. I go look and every tool is literally everywhere, garbage and debris thrown about, and half the stuff is incorrectly installed as he didn't think he needed to read the instructions and missed key details.
You're fine no worries. I think you are making my point.
People who claim they are 10x'ers are often not. They are mess makers or wannabes. They appear 10x to those who do not take messes or tech debt into account.
You screaming (to use your lingo) that my buddy above is not a 10x is what the rest of us have been screaming about our co-workers!
I'm not claiming people can't be 10x'ers. Nor am I saying being good is actually bad.
Katt from trpc, mantine lead developer, Tanner from tanstack, Anders from typescript, Jose from elixir, antires from redis. There plenty of 10x dev examples.
In any creative industry Price's is well known phenomen. 50% of work is done by square root of people. But in reality there large number of problems that cannot be solved by average developer.
That why people that build tooling, compilers, important libraries and frameworks make often 100 times more impact. They increase productivity of everyone
The question is in how they're productive. If they're productive because they're effectively cutting corners and leaving a wake of tech debt others have to clean up then they are productive while slowing down their team (or worse, the company) as a whole.
Anyone that has been doing this job knows that the majority of average developers in any workplace will also cut corners every once in a while and leave a lot of tech debt to others, with very few exceptions.
This myth that more productive developers are somehow worse and will ruin projects is just rationalization without any ground in reality.
And lets not talk about the 0.1x developers who are probably also a thing. If you get enough of those together, team productivity completely collapses. I've seen that happen.
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.
> And lets not talk about the 0.1x developers who are probably also a thing. If you get enough of those together, team productivity completely collapses. I've seen that happen.
> 1x is normal.
IIRC the post that came up with the 10x and 1x terminology used 1x as the worst performer. Normal/average was somewhere in between 10x and 1x.
The change to 1x being average in the common understanding seems to have happened because even the people criticizing it have an intuitive understanding that it's correct, they just want the boundaries somewhere else.
I've rarely seen those 10x engineers to bring massive long term added value. Most are/were well aware of their skills and detested working on anything but newest and shiniest, desperately trying to make work a fun park for them regardless whether its actually a good idea for the company giving them paychecks.
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.
> I've rarely seen those 10x engineers to bring massive long term added value.
I've seen it first-hand. We ended up building a support team around the 10x:er to keep things working, but it was easily worth it. It worked very well for the life span of the product - about a decade.
Many eventually graduated to pretty fancy places. They learned a lot. This particular 10x:er loved sharing knowledge via pair-programming.
Well, he was always in command of the keyboard (typing insanely fast), but you'd sit next to him and he'd delight in explaining. Eventually you would challenge him on something and then the collaboration/adventure began.
I have had the most intellectually exhilarating times of my life working with this guy.
So yeah, 10x:ers can bring massive value if they are wired to be really nice.
I'm a bit jealous. I currently work with an exceptional engineer but he is very condescending and acts somewhat pissed off by "simple" questions or people asking for help. The product is fantastic thanks to his work and I am learning, I think, what it really means to attempt to write excellent code - he really nit picks the hell out of my PRs - but to be honest I wish I didn't have to work with him. He has really demotivated me.
>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.
Does the company have my best interests at the center of their efforts or I can be shown the door at any given moment to please shareholders? No hard feeling pls, it's just business and I have only one life to enjoy.
I like 5x developers that get the job done and don’t spend the additional 5x over engineering the work — causing the 1x engineers to disengage.
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.
Fuck this constant dehumanisation and categorisation of the working class.
The key to a great team is great leadership.
Most people are terrible leaders, and they think that what they are worth is what makes them leadership material, even though they didn’t earn that worth themselves and didn’t put in a hard graft.
The key to a great team is a fucking team. Only then can there be a leader.
Let’s talk about ‘normal’ CEOs, 10x CEOs, and for that matter, ‘retarded’ CEOs, considering a particular one of them favours that insult. That’s the implication of ‘normal’ in scare quotes no?
I agree with your intent to introduce the angle of leadership and in particular the CEOs since it is well established that people can't properly evolve and thrive under a leadership that is rotten.
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
There are no "normal" engineers. There are many terrible developers who can't fizzbuzz, a bunch of decent programmers, and a few software engineers who understand what they are doing. And then... the 100xers like Linus. It's pyramid-shaped.
If the author is referring to people who understand what they are doing as "normal" engineers, granted, you can make a great team out of these... but how do you find many of them in the first place without bumping into the others?
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?
"There exist exceptions to a trend" does not mean the trend is not a valid proxy (see [1]), and "refuses to do fizzbuzz" is different from "can't do fizzbuzz".
I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank.
Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way.
But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.
Fine with you for your tech candidate question, if that works for you.
Maybe I never encountered your perspective; in 20 years in the industry, in about 10 significant software prod/consulting companies, we never outsourced hiring or pre-hiring. From my experience and perception, minor coding tests are a hiring filter than does not gives good results, for both sides of the interview.
You want to hire junior candidates? that test is fun and maybe ok an indicator. Having them live comment/describe/solve existing pieces of code is much more effective and fast. They will still demonstrate ability once on the job, that's what juniors are for.
You want to hire experienced (or even senior) candidates and filter for domain knowledge? 1. Filter on experience & referrals. 2. Conversations: same approach as with the juniors, but much deeper and wider, relevant to your domain. 3. Call at least one reference to counter-check.
A generic fizzbuzz/minesweeper (remember also "code a functional basic blog engine with comments in 30min" back in 2006) coding test demonstrates (in my very subjective and limited opinion) laziness and kind of a lack of interest in the candidate from the hiring person/company.
I understand that when you screen 1000s of people, it gets massive and more basic filters may apply, at least at first contact, though.
> But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.
I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.
> You want to hire experienced (or even senior) candidates and filter for domain knowledge? 1. Filter on experience & referrals. 2. Conversations: same approach as with the juniors, but much deeper and wider, relevant to your domain. 3. Call at least one reference to counter-check.
The reason I don't believe in (1) is that the candidate I described in my previous post claims nearly fifteen years of experience, some of it as a lead, and completely bombed our entire interview. Referrals are another matter (and they are indeed an excellent channel when you can get them), but they tend to be pretty low-volume - if you're hiring from the general public at all, presumably referrals didn't get you what you wanted.
By the same token, the majority of people we've placed so far were people whose resumes didn't particularly shine - but who turned out to be very good engineers when given an opportunity to actually work on a problem. (That isn't just my opinion, it's the opinions of the companies that hired them.)
For (2), I agree. We do do that as well (coding's one of three parts of our interview, not the whole thing).
For (3), have you ever had a reference give a negative review? A lot of companies make it outright policy to do so, and iirc there are legal restrictions on employers doing so in a lot of places. I wouldn't trust that with any reliability (although it's still good practice 'cause it's cheap).
> I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.
Of course soft-skills matter! I never meant to imply otherwise. But soft skills will only get you so far if you don't know how to do the fundamental responsibilities of your job.
As for (3), I never got _negative_ reviews, rather confirmations or hints that confirmed what emerged through the interviews and either lead us to stop the process (rare, but happened) or helped adjusting the position and onboarding to better fit the hire.
You also have force multipliers. Which can be some managers: people whose presence on a project will make decent software engineers produce like a 2x one.
To start with, there are engineers who deserve the title engineer. You are probably better of to hire a former civil/electrical engineer that can fizz-buzz than someone that can just fizz-buzz.
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.
Agree. The required abilities multiply rather than add so the right tail extends much further than a normal distribution. The gap between median and top performers is extremely large.
Please read that the right way. Deliberate practice compounds exponentially. Those extra hours refactoring, contributing to OSS, or mastering systems design create 10x impact through learned architectural intuition that median devs never develop. Your new skills will go a long way.
The 10x programmer is based on research cited in the Mythical Man Month, and there the most productive programmer was 10 times more productive than the least productive, as far as time taken to complete a coding task. The most productive were ~3x faster than the mean/median programmer.
Yes, but it's way more on the can't fizzbuzz side. Our view is skewed because of the people we work with. If you have an extreme Pareto distribution, talking about "normal" is not helpful.
Engineering work, like many other branches of intellectual work, does not have many of the properties of other jobs. So I don't share the ideal of a normal engineer doing normal work in their office hours.
I also don't buy into the 10x pushback, there's not only 10x engineers, there's 100x engs. Easy to prove, can you think of an engineer that adds negative value? That deletes tests, or breaks stuff? That adds left-pad to package.json? Or log4j? The bigger the org the bigger the damage. Boom, you have a -1x engineer, and conversely a +1x engineer. If they do a lot of damage that's a -10x engineer. If they do some damage and contribute a little bit maybe they can get into positive numbers, and you have a 0.1x engineer, therefore there exist 10x engineers (and 100x and 1000x and inf and -10x engineers.)
I do agree that performance is not quantifiable (or very hard to quantify) and that it is not a property of an engineer ( although the article suggests performance is a variable of teams or the org, but I would say it's a property of the engineer-product pair)
These are terrible examples that don't prove a single thing. Babel, Webpack, and React all used leftpad as dependencies. Blaming someone for using an Apache project is absurd.
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.
It sounds like you don't have an appreciation for software complexity.
What starts off as a simple write() call balloons into a complex system as it evolves to meet your needs. Only then will we know if a great developer was behind the wheels, by how easy it is for the next person in job of maintaining and extending the system to fuck something up due to a lack of context and experience.
Another sign of a real 10x engineer is an even temperament and a lack of arrogance, as being a team player is important in any environment. You can't be a 10x engineer in a vacuum.
Yeah, the warzone will be the final judge, no doubt, this is just cheap talk.
> a real 10x engineer is an even temperament and a lack of arrogance
Super subjective, but I see the 10x engineer as being arrogant, you have got to if you are really 10 times above your peers. Although it's true that some arrogance might come from a place of insecurity. Someone who is truly leagues above someone else will not berate them for being below, they will encourage them to improve or palliate them. Pointing out how the other is worse and they are better is argumentative, which usually a 10x anything doesn't need.
You're confusing confidence and arrogance. Confidence can be misplaced, or maybe hard-won through experience. But arrogance never has a place in a team. If you go around thinking you're 10x better than your peers, you're massively selling yourself short and I can bet you the rest of the engineers do not feel the same way about you.
> Pointing out how the other is worse and they are better is argumentative, which usually a 10x anything doesn't need
I'll be honest, this post is a bit incomprehensible. You say a good engineer has to be arrogant, then go on to claim how such an attitude can be combative. Pick one argument, not two conflicting arguments.
You sound young. I understand that youth can sometimes lead to the kind of arrogant thinking in your comments, but real wisdom will start coming whenever you realize how this kind of thinking looks to others, stop making comparisons, and try to learn from everyone on your team.
>Easy to prove, can you think of an engineer that adds negative value?
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.
I'll change the perspective so that we can look further.
Have you ever seen a product that got worse over time instead of better?
I find that it's the majority. Even if they get sales and more users. I'll list the exceptions: whatsapp, and even they succumb to bloat features like ai slop or stories or "communities".
If you take a wider period, all software gets worse with time(they die, nothing is forever).
No, and neither will a software engineer wash her hands of a bug, but a construction engineer isn't responsible for the layout of a building being overly labyrinthine—that's on the architect.
Likewise, product managers and designers who are talking to customers and conducting user experience research have the context to make decisions that engineers can't reasonably second guess.
We may be thinking of two different roles, which might fall under the engineer umbrella. When I think of an engineer (and especially so a 10x or elite engineer), they design and invent and create and have absolute control over what they do.
If an engineer doesn't have control or follows the designs of an architect, they are merely in an executor role, and their engineering skill is put to use not in inventing or solving a problem but merely executing.
There's a time and place for that, but it's definitely not the dream when I think of the engineer I would want to be.
> they design and invent and create and have absolute control over what they do.
In this dream, what is the role of UX researcher? Of product manager? How many such "elite" engineers are working on the product at one time? What's her relationship with the customer or end user? Are all the engineers on her team "elite", or is there only one? How does she interface with stakeholders? At what stage of her design process does she submit wireframes, prototypes, or plans for review? How much of her time is spent accessibility testing? How does she receive feedback about the product?
Like you, I've been happiest in my role when invited to share in the full discovery, design, and implementation processes from end to end; as a software engineer, I always look forward to engaging with customers/users and participating in--even leading!--research and design activities. But I also recognize that should our team be so lucky as to acquire a person more expert in those methods than I, the artifacts of their intelligence are only more grist for the mill.
> their engineering skill is put to use not in inventing or solving a problem
As Feynman put it, "there is plenty of room at the bottom," and as Cook said, "all ambiguity is resolved by actions of practitioners at the sharp end of the system," but if the first seven layers bore you, by all means, hack the eighth!
I think 10x is an exaggeration but I've found its really common to have 1-2 people who do a big bulk of the work
The thing I don't understand personally with these people is why they care so much about work when the rewards are not proportionate to doing so much extra work.
I get it if you're a founder of a startup but not if you're at a big company
Yet every big company I've worked at there are always 1-2 people on the team who seem completely obsessed with the project, like its their main hobby/purpose
It makes me wonder, if someone is so smart that they can do "10x" the work, would they not use that smartness to look at the meta of it all and wonder why they don't get 10x the rewards?
> It makes me wonder, if someone is so smart that they can do "10x" the work, would they not use that smartness to look at the meta of it all and wonder why they don't get 10x the rewards?
It is hard to understand other people with freakishly high intrinsic motivation. They look like aliens to the normies.
Maybe because they enjoy the work they do because they love programming and are very happy that they are getting paid well, relative to most professions, for their hobby? Sample size of 1 tho.
I feel the same when I read about a career staff engineer for NASA. They work on many cool projects, but the pay is average compared to the tech industry. When they talk about their work, you can see that they have very high intrinsic motivation.
> why they care so much about work when the rewards are not proportionate
Some people are just work horses by nature. They're too busy fulfilling their idea of a "job well done" to worry about the relative fairness of their employment.
Not to mention being a 10x coder doesn't mean you can simply parlay your skills into the greatest possible rewards. There's a lot of important context that makes a 10x possible in the first place.
Because it's rewarding in its own right. I can't imagine doing the bare minimum at work -- pretty sure I'd melt of boredom within a week. "Owning" a project/component/whatever keeps things interesting and keeps me engaged, and extrinsic rewards aren't that important if you're making a healthy salary in the first place.
So only if you're hating your job then you are a bastion of free will and free thinking among us mortal capitalist slaves?
What about truly enjoying your job and getting paid handsomely for it (compared to almost all other jobs) being sufficient to one's happiness?
Also, if you don't realise that being the one running the show is orders of magnitude harder than following the lead and doing your stuff then you never really done it before. Having ALL the control has advantages and many less obvious disadvantages.
Taking pride in your craft would mean having enough self-respect to both not burn your soul out for the sake of a corporation that wants to make you redundant and using it in a direction that directly benefits you.
I've been in the industry long enough now to see those 10x engineers having pride in their work get their mindset shattered because John from financials thinks they can juice the next quarter by laying them off.
If you want to have pride in your work as a supposed 10x engineer, work at 2x or 3x and save the remaining for yourself.
A lot of commenters seem not to work with very skilled individuals.
One (engineer-turned) manager I have in mind: show up at 10am, leave at 4pm, solve a zillion hard problems in the mean time. Are they 10x? If they save me 2 weeks of work with their insight then I guess I have to admit yes.
That honestly doesn't matter if you (no longer) pursue riches yourself, have enough already and enjoy your hobbies. Besides, not everyone working in IT is working in a chique billionarie mill. A lot of IT is just plumbing. Majority even.
I'd love to hear your take on those dumbass medical research scientist slaves who haven't figured out life. Probably wasting their time looking for cures, when they could be starting their own crypto or podcast or innovation-firm instead.
The do work, at 10x efficiency. Or maybe I misunderstood the 10x engineer idea all along!
And that efficiency can translate in 10x output, but it's not guaranteed.
My opinion on the 10x engineer principle, always was that these people have their best development/debug environment setup. And they can traverse, run, and explore code faster than most. Like world record pizza makers in under a minute.
Through my career I've seen some engineers that were stumbling their way around their tooling after years of use, and some that weren't even touch typing. Factor that in.
It’s been described before that this mythical unicorn is instead 10% more efficient- as well as works 10% harder, does 10% more of the right things (e.g. less waste), understands everything 10% better… the multipliers stack. You get the idea.
it's sorta like, why doesn't everyone just kill themselves you know?
sometimes, you just find fun in things and it's cool.
other times, it's like what other other thing you gonna do? fish or hang with people or do drugs or dance? software's a hobby really. sometimes its more fun.
This dynamic is hard to avoid. If you have 1 or 2 people who have more institutional knowledge than the rest of the team, they can burn through more tickets and gain more knowledge through exposure to other people’s problems, which they help with. Then everybody ends up relying on the “hero”, and nobody is really happy about it.
That’s my experience, at least. Cleaner code, separation of responsibilities, and good documentation seem to help though. But I do think a lot of the time people are mistaking “more productive developers” with “devs who got stuck with knowing all the random shit that our horrible codebase relies on” lol
>The thing I don't understand personally with these people is why they care so much about work when the rewards are not proportionate to doing so much extra work.
The reward is there allright, it just isn't monetary.
> if someone is so smart that they can do 10x the work, would they not use that smartness to look at the meta of it all and wonder why they don’t get 10x the rewards
I think this is kind of a nasty attitude. I absolutely cannot stand working with people like this. Why would you insinuate that someone is stupid because they get more done? To me it sounds like you are just insecure about others’ output, so you have to tell yourself that it’s stupid and pathetic to be fully engaged at work.
Depending on the company and person they often are compensated much more down the line when they get fancy titles or apply what they spent more time learning/practicing.
It's only a regular 9-5. Family is #1 priority, but that doesn't mean I don't take pride in my work. What I get in return is the ability to work remotely in my hometown while the manager wants the rest of the team coming into the office in the Bay Area.
Sometimes it isn't even that I like to do something, I just have a very strong feeling it has to be done. The code is asking to be written, the energy has to be spent to lower the entropy. But at least nowdays I can close the damn work laptop at time and not open it until the morning, unlike some a decade or two ago.
Sometimes I feel useless compared to other people - usually while I'm struggling with something and seem to be achieving nothing. This talk of xN programmers absolutely hits on all my insecurities.
Then other days I solve 3 problems for other people which are easy for me because I have bashed my head against those particular kinds of walls before. I suddenly feel worthy again.
I'm productive when I know exactly what I'm going to do but getting to that point is hard and looks like I'm doing nothing. I find that people who are more productive than me often just don't hesitate and take all the easy exits that I waste time worrying about. I can't give up on my style because I always feel happier with the result.
Sometimes they're just faster because they're repeating a successful pattern they've used before.
I have often had to fix code written by "reputedly" very productive people and it's not a rule but more than a few times it has been very brittle and unmaintainable.
What I'm saying is that speed is usually NOT magic. It's achieved in a particular way and that is sometimes not good....but you tend to find out later.
Thanks for your candor. Your experience is extremely common.
Who benefits from rhetoric about xN programmers? It's about extracting the most value out of you in an unsustainable way. It's shortsighted. If you're going to be productive while maintaining your sanity, it is an uphill battle. This is especially true for people who are especially sensitive to this kind of pressure, and can drive themselves into a wall if they aren't careful.
Yes, I have felt it worse with the kinds of managers who try to drive you by making you feel insecure. They're always making sneaky or not-so-sneaky comparisons.
Systems tend to ossify over time. Thoughtful solutions to problems usually stand the test of time better than rapid fire solutions. On my team, we often take an extra day to verify and validate design decisions before binding ourselves to them. Yes, some may deliver faster, but developing with intention is the road to sanity in my book.
Every 10x engineer I've known has carried entire teams of normal engineers. ymmv but I've seen probably 5 instances of this and 0 instances of teams of normal engineers being super productive.
I’ve seen the opposite: plenty of examples of very productive teams with really no standout “10x engineer”, and several examples of unproductive teams purely due to poor team decision making. IME, productivity is a measure of past investment, not current skill.
What are the details of this? Any engineer that built most of the stuff is not a 10x engineer. It's someone that really knows their way around their own house.
>"A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week."
I don't think decent skills and ordinary expertise gets you that, especially "move fast" on top of the other things. But the convenient thing about "normal" is I can move the goal posts wherever and it sounds valid.
The article also did not say how often the normal engineers produce bugs of varying severity, so I guess it's possible to move fast and create a manageable amount of bugs?
Decent skills and ordinary expertise requires a good process and a healthy team/work environment, and then it's totally possible. I've never worked with rock stars, and I'm not one myself. The difference between getting things done at a good, steady pace without building technical debt (which is all that moving fast really is) has always been process and product owner.
Imagine there was a team that can take ordinary levels of talent and produce extraordinary results. If it could exist, this would be a great engineering organization, no?
Some of the problem in the conversation around this is that many people take "1x engineer" to mean "not particularly competent engineer" and some take it to mean "baseline, solid contributor who isn't exceptional", and the bar for what we regard as exceptional can differ drastically.
I've been on teams where everyone is pretty good and felt like I was a genius, I've been on teams with really remarkable people and felt unworthy.
Nobody knows or agrees what 'x' is or that it can even be reasonably measured, so all conversations about 'x' multipliers tend to be unproductive.
I feel like this article completely misunderstands the point.
Their two big arguments are that 1) people aren't 10X at everything, they are at most 10X at specific things and 2) what good is a 10X engineer if they are on a team that can't perform at that level?
There isn't something magical about 10X engineers, but the fact is there are engineers who have developed the skills to greatly exceed their peers and work in those sub disciplines at which they have this skill. Who cares if your 10X mobile app engineer would be no better than anyone else at microprocessors, they aren't working on microprocessors. Likely anyone could become a 10X engineer, but most don't. It's like great athletes or great musicians - whom no one would question are 10X better than average even if quantifying skill in those domains is hard - maybe there is some level of god given talent but for the most part it's years of effort that other people just don't put in.
Then yes, engineering is often a group effort and a bad team can certainly hold someone back, but just as in sports a strong player can certainly elevate an otherwise mediocre team particularly if well utilized, a 10X engineer can massively improve the output of those around them. No one on earth would say it doesn't matter if our band had a great cellist because the rest of the orchestra probably isn't exceptional. If a team holds its high performers back, that's a problem with the team, not a limitation of high performance.
The orchestra analogy is actually pretty good. An orchestra with a few great instrumentalists will perform so much better than one without them, even if most instrumentalists are very mediocre. Anyone who's ever played in an orchestra will know that experience.
I have had many colleagues who produce more code and functionality at a constant rate than me. But I have also had that the experience that some of those colleagues were trying to reproduce a certain customer bug for weeks and not being able to reproduce it and that when I finally decided to also have a look at the code, within half a day found the bug and a two click way to reproduce it. When I told them about this two click way to reproduce it, they at first did not believe me that it was that simple to reproduce it. They had so see it several times with their own eyes before they believed it.
I also have had the experience that some colleagues had worked on optimizing an algorithm for months and months. I too had looked at the algorithm and one day, almost out of the blue, I came up with a short cut that totally avoided said algorithm and implemented the required functionality with some calls to a function in standard library we were already using. Again, I was met with disbelieve when I presented the solution.
I feel that I am the guy who about once per year comes up with an idea that no one else had thought about and that most of the time I am just not very productive and often find myself daydreaming and not being very productive.
I also feel that often I am far ahead of other with respect to ideas and that I fail to convince others about a my '(too) advanced' approach. I several times have been in the situation that I proposed a solution to a problem and that some kind of manager decided to go for a simpler solution and that after months of develop time, it came to be that certain functionality did not work and that it was simply decided that that functionality was not going to be supported anymore.
This reminds me of the time I did a fait accompli.
Due to changes in the input data, a simulator was crashing completely and very early in the simulation, making it unusable. We had to solve this quickly. The underlying module that was crashing had been written by a non-software engineer, and it showed. The project manager was trying to understand it and do the most minimal fix to it as possible. My solution was to rewrite the module from the ground up; this solved the bug, the whole thing is going 2x faster than the previous version and is much simpler. This day I should have been working on a bullshit, internal politics-driven license module, and thus I disobeyed the manager. I couldn't think of anything else anyway, the code has to "get out".
A few days after, I showed my thing and the client royally ignored it, preferring to continue with fixing the older, shittier solution. After 10 or 20 minutes they finally caved and accepted to merge my thing. I don't understand the initial reaction at all.
I find that the true "10x" engineers are staff-level engineers that a) have strong technical ability and b) are really good at communicating and mentoring. They are 10x because they are able to make all of the "normal" engineers around them better and thus level up the productivity of the entire team. Engineers like this are worth their weight in gold and far more valuable than the infamous "brilliant jerks" who can easily design an excessively complex system by themselves that magically only they are able to maintain effectively.
I think kind, industrious, and smart people make great teams.
I once took up a lot of space to be a super productive engineer and only ended up being isolated. The business saw that some engineers were saying things worked great and were easy, so more responsibility was thrown on me and the other engineers moved to another project that needed headcount. Me and another guy ended up building on and maintaining what used be a reasonably sized team. It got on me because I made sure to know everything so I could make it as great as I could. This sounds good, but this particular business didn't care about me at all, I was just another gear.
I've met "productive" engineers that got things done really quickly from the business perspective, then moved on to being awesome somewhere else. But, they also took shortcuts, didn't write documentation, and made things unmaintainable. When I joined the team after they were being awesome somewhere else, I had to do things like guess hostnames and find out how and where things were running..
The people I've liked working with the most have been parents. The boundaries are more clear, they value stability, and aren't heros.
> I had to do things like guess hostnames and find out how and where things were running..
This isn't the worst thing in the world. I'd rather inherit something with little/no documentation that followed the standard business practices (e.g naming conventions, nothing crazy bespoke) and have to do an afternoon of investigation than have to read documentation that's inaccurate. Of course the best option is full documenation but due to the nature of business that isn't always possible.
So I think the title of this post is a bit off. The article is not saying "Normal" engineers are better than 10x. But your organization should not be depending on the 10x to operate, and it should work well with "normal" engineers.
And the key to great teams and organization is the "process", and not the presence of specific, 10x people.
But that means in such an org, you are just a replaceable cog. So from the point of a 10x engineer, you absolutely want your org to be dependent on you.
I agree wholeheartedly with this article, and wrote about the same thing back in 2018 [0]. The Hero (or 10x) Programmer is a seductive archetype and I can see why managers and leaders and teams are attracted to the idea. The simple fact is, tho, that just about anything worth doing requires more than one person these days and the toxic negative side effects of “10x disease” on a team ends up outweighing any positive productivity effects a single person can bring.
Do people really question the existence of "10x engineers". It follows from Pareto distribution that some people are just exceptionally productive. That doesn't mean that its good or beneficial (depending on what the scope is). That also doesn't mean that its good to only have them, because they often carry their own baggage.
It is worth noting that the original 10x was a reference to the best engineer being 10x more productive than the worst engineer. Not 10x more productive than the average engineer, no the median engineer.
I question the usefulness of that way of thinking. 10x isn't an unchanging skill level, it's comparative performance over a period of time, and that extremely high level of performance likely has many contributing factors. Saying "oh, John is a 10x engineer" stops you from exploring how John is doing ten times the work of his colleagues.
There are good answers, like John is an expert in the specific technology you're using and he was hired through a meet-up you sponsor; there are bad answers, like John has found a way to game the ticket system; and there are debatable answers, like John's team has a high support burden which he never helps with. If you insist on seeing him as a 10x developer through innate skill or divine fiat, then you're not going to look for the root cause of why he's doing more work than everyone else.
People disagree on what it looks like. If you think it’s an engineer who types 10x more lines of code, or makes 10x less bugs, there is someone ready to argue that person doesn’t exist or is actually a boat anchor.
Once you define it as an engineer who ships 10x as much business impact (ships fewer bugs, builds the right features, etc), it’s less contested but also less glamorous and harder to measure. In fact you start to develop an inkling that such people may not even be the same coders you once idolized.
I appreciate the overall point of the article, but have a gripe. The author (and others) gets it wrong on the original meaning of 10x. A 10x engineer isn't someone who is 10x as productive as their peers, they are 10x as productive as their worst performing peer. The original study the author links to compares the difference of work between the fastest code and the slowest code. The fast debugger and the slow debugger.
When we talk about 10X, it should be about comparing it to the least productive team member - the 1X. There is always going to be a 1X person on the team. That's not bad if the team average is 1.5-2X, but if the average and discrepancy gets large enough, you're going to have the 10-100X team member who gets a lot done.
Also, not all work is equal. The 10X engineer who is only 10X in programming may be a 1X in collaboration or documentation. That's not a good dynamic, either. Again, appreciate the point of the article, "build great teams", but we need the 10X person in each task to do that. If the build pipeline is slow and costing us money, I need the best people on the team to go figure that out. And, I need our worst engineer who is still learning to be involved so that they can grow their skills. Become a 1.1x, 1.2x, etc.
Who cares if the term "10X dev" was derived from a misunderstanding of actual studies (that may or may not be legitimate), the term itself is very clearly about superhuman rock stars.
If you want to move the discussion of 10X devs away from the 10X dev then stop using the term "10X dev".
How do you define a "superhuman rock star"? Is it someone that competes at 10x the capacity of the average performance or 10x the capacity of the worst performance? Someone who is 10x the average is likely 25-100x more than the worst performer. You're selling their superhuman rock star ego short.
In any event, it doesn't really matter because engineering managers should just hire the best fit for their team. The unicorns are rare and expensive and may not be the best fit compared to just a stallion who likes to run.
10x engineers don’t spend half their lives trying to argue against the existence of 10x engineers to protect their fragile feelings, maybe that’s where the productivity comes from.
> 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
> "Engineers don’t own software, teams own software"
This is often the opposite of the truth. That is, teams are much more often formally-owning software, but "owning" in the sense of actually being responsible and feeling responsible for its functioning, well-being, and strive towards polish and realization of potential - more often than not, it's one or a few individuals. If it's a large software system, a lot of people have to put in their work as well, but still.
I am occasionally in a situation where I feel more "ownership" towards a software project I have no formal responsibility for than I believe the formal owners do, and find the, to be poor stewards of that software. Not that I have the time to take over for them, but I have the motivation, and it pains me to see them mistreat it and mar it with unworthy merges.
PS - I am not speaking as a supposed "10x engineer".
"If you must 10x something, build 10x engineering teams"
This is a healthy perspective that hopefully avoids some of the controversy around the 10x label. Any improvement you make to how the team works together, be it CI process, sharing/evaluating ideas, code reviews, design, anything, is multiplied by the team size/responsibilities. Maybe high-functioning teams are part of what enable the 10x outputs that perpetuates the meme.
From what I remember in mythical man month it's sort of addressed there (different roles/support roles being just as critical as others) and recently reading "soul of a new machine" it was clear how dependent even the most skilled roles were on the other members.
How to hire and build a 10x engineering team remains a challenging problem however!
Having worked in "traditional engineering" and software dev / tech, I've always found it fascinating how much tech people obsess over the 10x engineer, and how polarized their view is - there's certainly a strong polarized view that you're either a 10x engineer that's carrying the whole product, or a mediocre (to poor) engineer that's holding back the rest - seemingly nothing between.
Hell, even by engineering standards, tech has a lot more extremely opinionated people - with more extreme views on pretty much everything. I've always wondered why it is like that.
I worked for a couple companies during my career whose main product was incredibly complex and difficult to understand. Making a minor change in one component could send ripples through the whole product.
One or two 'superstar' engineers who had been with the project for more than a decade were the only ones who understood the bulk of it. They had job security!
I often wondered if they intentionally created it to be that way out of self interest. It made things rough for all the 'normal' engineers who wanted to improve things but got pushback from them and management.
Why shouldn’t there be a continuous range of skill? Why should we want normal engineers instead of you know “good” ones, or even “really good” ones?
Oh and also, it wouldn’t hurt to qualify those skills to the specific domain to which they apply. Like “he’s a really good database engineer” or “he’s a great C# guy, but terrible at DevOps”
These articles are polarizing because they take for original assumption that the real world is discontinuous. That’s stupid.
Let’s praise the engineer that’s in the 2.5x to 7x range.
The thing that bugs me with this article is that a lot of regular software engineering is plagued by a lack of ambition. 10x engineers bring that ambition (I hate the term 10x, but let's just stick with it). Because of the scaling effects in software, if you work on the right project, that ambition can significantly increase your impact on the market/world/field you're working in.
The costs associated to managing teams without an ambition for excellence are substantial. As far as scaling an org goes, building average teams scales better than having exceptional teams, because by definition, exceptional teams are the exception. But if you work on a project that has winner-takes-it-all dynamics, the costs of average teams are immense.
I really don't get why people argue so much against it. Nobody debates it in sports or music. Not every software project is like the world cup championship. But if you're in a VC market where the winner takes it all, yeah, then it's a lot like music or sports. You want your team to have the ambition to win.
you are making a whole lot of assumptions here that might be true in your experience but might be far from truth as a whole. over the almost 3 decades hacking I have had the pleasure of working with many 10x-ers and all but one were the least ambitious people you will ever meet. not sure how you can in general relate someone being awesome at what they do with being ambitious?
the winner-takes-all dynamics also would be such a terrible place to work, “the winner” is seldom-to-never a person actually doing the work but VCs and owners and… what is my ambition here? maybe minority in USA but people do not define their lives by their job, it is means to an end. go to work, do your job and then head home for important parts of life. I have always looked for meaningful work that matters and have largely succeeded later in my career but none of that success had anything to do with ambition.
Agree with that, but for employers to understand that it’s worth paying it’s necessary to understand that you would actually get more value in return as an employer than the extra you have to spend on a great engineer.
Again, depends on whether your product has that much upside. Many products don’t. But as an example: German car makers have long ignored that great software engineers have a vastly bigger impact in a team than great mechanical engineers. As a result, they for a long time failed to build great software engineering orgs.
Volkswagen gave in eventually and is now licensing from Rivian. Their failure was caused by a structural problem of not seeing how SW works at scale, and how that should influence your hiring.
As a manager, you want a report who does not require handholding, cajoling, or close supervision. You want someone who makes problems disappear. It's fine if they're 1x engineer. It's fine if they pick up their shit at 5PM no matter what and leave for dinner. Just do what you're supposed to do, at a predictable cadence. That's all that's really required in 90% of the teams.
>A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week.
Agree completely, and 10X engineers build such organizations.
The closest to "10x" engineer that I knew wasn't necessarily the best or fastest programmer but he would see what we needed before we needed it and already have it done. A manager would say we will need something to which they would reply they've already done it.
They would read the play like Gretzky to know where they had to be ahead of time.
I do agree with this article; I just think there is a time and place for each type of engineer.
There are companies where 10x engineers make sense, and there are companies where normal engineers are better to have.
One good example is the Commandos, Infantry and Police article from 2004 Coding Horror. (you can look it up, not going to link) Typically the commandos are the 10x engineers. Having them on early in a startup is tremendously helpful. As a company grows to stages where you want infantry and police, having commandos / 10x engineers might hurt more than they help. Of course this isn't always true but this is more likely true than not, in most cases.
We as humans, and particularly in America, like to quantize people and use a single variable to rate how good people are. In reality different people are good at different situations. It's not always the best option to hire for the 10x engineers.
This stuff is that self-indulgent pablum that comes from the genre of "poor are happier than rich" and such. It's always reinforced by the mediocre because everyone wants to believe they're key to something. The long and short of it is that the people who are buying your work are adequate determiners of how key you are.
There definitely are 10x engineers and they're invaluable, but they're not (necessarily) those who write 10x more good code, but those who understand the requirements and write the right code. And directs others to write the right code.
Most time is wasted when you throw away and rewrite what you did.
I think it's more like 80% of your team should be normal engineers, but they will collectively pull 50% of the weight. the top 20% should be "10x" (hate the term) and carry the other 50%. This just happens to be the most optimal, healthy and sustainable distribution.
The other important thing to consider is that 10x engineers are deemed so based on productivity. But productivity isn't necessarily the be all end all.
In fact, an arguably more important skill is know when not to do something and how to avoid tech debt. Building towards a north star sustainably and incrementally in such a way that pivots along the way don't require major bandaids or rewrites is how a good engineering org operates.
In the real world a lot of 10x engineers end up just launching a bunch of hacky garbage to frontload impact and leave the cleanup for everyone else. This can work for some time in organizations with phenomenal build and test infrastructure; however, it eventually becomes crippling and hinders everyone's velocity.
I'm sure everyone has worked with engineers who might be 10x on their own but drag the team down being inflexible or insisting on solving the wrong problem.
I like the saying that "engineering is a team sport" and agree that the multiplier should be on the productivity of the entire team as mentioned in the article. The concept of whole being greater than the sum of its parts applies to both engineering systems and technical teams (which we'd probably say is a type of system on its own).
Not meaning to downplay the role of great engineers... I suppose the best scenario would be 10x engineers who can also help the rest of the team perform better.
The 10x trope was something Steve Jobs really learned from his days at Atari.
If you look at virtually all the games programmed from 1975 to around 1995, the programming "teams" were incredibly small. Until the Sony Playstation came out, virtually every videogame was written in assembly with no source control whatsoever. Even PC games like Starcraft (released in 1998) had code review done by printing out the physical code and going over it with a marker [this was about the last time Elon Musk had a programming job cough). There was no source control and graphics APIs (if they existed at all) came in thick manuals.
For context, the credits to the Sonic the Hedgehog, a multimillion (now billion) dollar franchise, had just one "Chief Programmer" Yuji Naka, and 2 "assistant" programmers. Most of the time the assembly code would be incomprehensible to anyone but the person who wrote it. I believe there was very little actual "collaborative" programming going on. The gulf between a programmer who could merely code (which meant moving sprites around in assembly), and someone who could ship an actual game, let alone a decent one, was quite immense. When it came time to develop the first 3d Sonic game for the Sega Saturn, Yuji Naka was busy, and an American team was set to the task. Working 14-20 hour days, and forced to write a 3d game engine on Saturn hardware in assembly (due to the crappy state of C compilers at the time), this team could not ship an acceptable game in the 1 year timespan needed by the company.
I think quiet advances in tooling have made both collaborative software engineering more feasible and more effective compared to the 80s and 90s, where entire multi-million dollar industries by necessity sat on the shoulders of a handful of high skilled software engineers.
It's not necessarily true that a "team owns software." Sometimes there are more projects than people. There can be a lot of libraries or small apps that are in maintenance mode that nobody really owns.
IMO the problem isn't 10x engineers. The problem is that the workplace is flooded with 0.1x "engineers" that we have to tiptoe around. These people can barely implement Fizzbuzz, and if we write any code that they find complicated then we're not "team players". Well guess what, if we want to be ahead of the competition then we sometimes have to use quicksort instead of bubble sort and if you hire people who don't get that then you're part of the problem.
The key to great teams is the key to great teams. Anything else is context dependent (what, who, when), nuaced, unpredictable, stochastic, often non repeatable, sometimes contradicting, changing with time (as in maturity of projects), requires adaptability, differs for different people etc.
I'm not giving up on answering the question. It's an aid for you to answer this question by yourself now from where you are.
Argument in this article feels like advice that key to writing best programs lies in writing functions with average LoC.
What ratio of time spent coding to time spent doing code review is conventional in industry, anyway?
If it is around 1 (which doesn’t seem too unreasonable given that multiple people might review a single commit), and a 10x engineer really is 10x as productive as a normal one, then I guess a team of less than 10 people will have trouble keeping up with these 10x engineers.
Unless the company only hires 10x engineers. But then we should at least consider the possibility that they are just hiring 1x engineers, and have a low opinion of engineers outside the company.
> Individual engineers don’t own software; engineering teams own software.
the portion "software; engineering" -- just because the words are adjacent here, even though they belong to separate phrases, are treated as one term and hyper-linked to articles tagged with "software engineering" :
In my mind, the important distinction isn’t so much about the developers themselves, but more the environment that they are developing in.
If your codebase is an inscrutable mess, you don’t have agency to make even minor decisions without slacking 6 people for an afternoon, and there is no documentation on a service you suddenly own, then guess what? You have no chance of being a 10x engineer. You probably can’t even be a 1x engineer!
With engineers (in software and engineering) i found out that a lot of people are there just for the money. Those have no passion and will never be great regardless of the skill.
Then there are also different individual skills (like magnus carlsen is more skilled in chess than me) that are influcened by practice and talent.
Also for a lot of problems experience might be more helpful than intelligence so you dont need to be einstein to engineer a dishwasher (probably).
Good leaders are the key to great teams. Good leaders know how to deal with excessively productive people, and underperforming people, and to harmonize them. A 10x engineer under good management will actually distribute their weight to others, and meet the definition. Without that they're just one highly skilled engineer, engineering.
> But someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are average (or below average). I know a lot of world-class engineers, but I’ve never met anyone who is 10 times better than everyone else across the board, in every situation.
I think a lot of it depends on what domain you are in. If you're competing to build the world's best AI model, then you better have a lot of 10x engineers working for you. But if you're building some boring, niche SaaS app, then you better know how to get the most out of normal engineers.
What a bunch of nonsense. The article flattens the "10x" definition to mean quantity, where as in reality the most talented people can reach hights, qualitatively, the 1x cannot. The Infinite Monkey Theorem - no amount of 1x'ers would have produced Einstein's contributions. The same applies to software, in many ways.
> Charity Majors is cofounder and CTO at Honeycomb.io, a platform that helps engineering teams debug and improve their software applications.
> https://charity.wtf/ Blog, latest article an apologia for DEI, "The diversity of your teams over the long run rests on your ability to build an inclusive culture and equitable policies."... "Don’t underestimate what a competitive advantage diversity can be"
Hmm. Why does no one argue for equitable balance of political views, or religions, or anything to do with ideas at all? Is anyone even measuring ideational diversity? Power-sharing in most countries is principally concerned with it, for example. How many 'inclusive' teams are extremely politically, and ideologically, homogenous?
Clearly there's a apologia for a certain worldview at work here: some sunk-cost investment in a certain notion of inclusion, which is entails (if not aims for) moral and ideological uniformity. Offensive to this notion of 'inclusion' is excellence, since excellence isn't uniform nor even normal -- it's pareto distributed. An excellent runner is exponentially better than a normal one, and sampling uniformly from all groups ("inclusively") produces bad runners.
According to experience, and all evidence, the best talent arises out of healthy competition and cooperation with the best talent -- it does not arise out of uniform, nor even, normal distributions.
If you sample uniformly, then race all against all eventually a powerlaw arises -- and almost everyone is excluded if you want the best. Discrimination based on talent is a ruthless process which cares little for what ought be.
Yes, systems produce excellence by exaggeration of abilities, but this process of exaggeration quickly leaves the normal behind, and is anyhting but inclusive.
Diversity tends to work best when there's alignment to a common goal, and diversity is adding perspectives on how to get there. Consider creating a product that will be used by people from different cultures or backgrounds. But when there's significant difference of opinion about the directional goal, as is often the case with political/ideological differences, then that diversity can be adding friction rather than insight.
Republicans will never be good at leading the EPA, basically.
> Hmm. Why does no one argue for equitable balance of political views, or religions, or anything to do with ideas at all? Is anyone even measuring ideational diversity?
Probably not, no.
About a decade ago, I worked with a woman who had a PhD in psychometric assessment / quantitative psych. She was crazy smart. She said there have been lots of studies of high performing teams, and of course one of the conclusions people have taken from these studies is that "more diversity is better".
But she said if you actually go and read the studies, its far more complex than that. She said the data actually shows:
- A diversity of backgrounds makes a team more effective.
- A diversity of values makes a team less effective.
It makes sense. Imagine your company sells breakfast cereal. You will be more effective if you have people from a lot of backgrounds because they will understand issues your customers will face. If everyone on your team is wealthy, you might price your product too high. If everyone on your team is poor, you might never consider having a premium version of your product for wealthy areas. If your team only speaks English, you might accidentally give your product a name that plays really badly for Spanish speakers or something. And so on. These mistakes can be avoided by having a team with diverse backgrounds.
But if your team members have different values, they won't get along and your team will become less effective. Say, some people on your team want to make a product thats good for the environment. And other people on the team just want to maximise profit. Then they'll spend their energy fighting about that, and the result is a low performing team, making a confused product thats probably expensive and bad for the environment at the same time. Or, one person on the team wants everyone to like each other and someone else on the team loves competition. They'll inevitably clash. The conflict might result in personal growth - but it'll probably be bad for the team's KPIs this quarter.
In essence, nobody talks about diversity of values because nobody wants it. Ironically, not even DEI proponents.
My point wasn't that we should expect high performing teams to have a diversity of relevant values -- rather, that "diversity" is just a means of smuggling people of the same values in together under the guise of inclusion. In other words, its a kind of radical exclusion of those who do not prioritise this sort of diversity -- which is the vast majority of people. Looking around to see if the ethnic mix matches population statistics is bizarre to almost everyone.
This is a problem when these values become extremised in a population such that to select for them is to quite significantly narrow the plurality of values which would otherwise well-coexit. Consider, eg., religious communities living together before and after liberalism -- before = civil war, after = human rights. Classical liberalism is an ideology of values pluralism which thereby permits great diversity of ideas.
We should expect high-performing teams to have a diversity of relevant ideas (, and perhaps, ) of irrelevant values.
The concern arises when the benefit to team cohesion arises from an echo-chambre of shared values, at a great expense, of disruptive innovation and ideational diversity. And also, on my part, just honesty about what this sort of moralist is really aiming for -- to be surrounded by people who wish for a very narrow sort of values-homogeneity.
If "diversity and inclusion" were part of the pluralist fabric of liberal tolerance shared by the vast majority of people this issue wouldn't arise -- since then there could be a great actual diversity of opinon whilst values were shared. The issue is how peripherial prioritising these values is, de facto -- and hence how self-regulatingly narrow the "team" has to be.
If the chief value being pushed were "tolerance", such that we had, "tolerance, respect, effort" (, say) as the new moralist fashion -- then almost none would be excluded.
Consider what the impact of making "racism" a team value would be in these terms: how narrowing, homogenising, and the like. And yet, I suspect the number of people keen to work with "people as racist as they are" is not so different than "people as obsessed by diversity as they are".
I've heard people talking about diversity three ways;
The first is the idealistic one that employers would like to be the default interpretation: A global hiring pool allows for the best possible experts, with the widest experience. And you need an inclusive culture to ensure that the talent is happy to stay.
The second is the more realistic: A global hiring pool allows for cheaper labour: And you need a culture where speaking out against "inclusivity" is dangerous to the individual, in order to prevent unionist sentiment or political barriers to cheap labour emerging.
The third is a bit more cynical, it's similar to the second but considering a wider scale: If an employer with an easy problem can't access a low cost low skill workforce, then they have to compete in hiring from the high skill one. This means that development is tied up with the financial impact of the work. (You only hire someone if there is expected return). Access to a cheaper labour market makes the price of the work more tied to the difficulty, removing the perception that development is a high value activity.
An average engineer with solid problem-solving skills and a good manager is like a ~3x engineer. It's way easier to hire a few of those than a 10x engineer. But you need to match them up with a good manager, and that isn't easy.
When I think of a 1x engineer, I think of all the guys I've worked with that had a decade plus of experience but were advanced beginners at best. If you don't work for a FAANG company, you will be surrounded by those types. They make the same mistakes over and over and write the same unreadable code, year after year.
I think productivity isn't just about speed; it's about long-term sustainability, resilience... And it seems for many businesses it's hard to understand
Those were quite some claims about 10x engineers, made with zero evidence.
We also need to decide what we mean by a “10x engineer”. Many people here are describing engineers who “appear to be productive, spewing out shitty code that makes things worse”. The infamous industrious incompetent. This is not a useful definition of a 10x engineer. There is a reasonable definition of a 10x engineer: a 10x engineer creates 10x the value of a 1x engineer over the same period of time. This is the only meaningfully useful definition. Anyone who wants to understand 10x as “damaging spew” is choosing an unproductive definition. I assume such people are 1x engineers. To be a 10x engineer is to be the kind of person who believes that some engineers can be 10x, and then goes about find out how to be that themselves. 1x engineers get caught up misidentifying bad engineers as “10x engineers who are shit” so they can continue to be mediocre.
Well I honestly think "10x" Engineers exist... even 10,000x ones.
It's about creating leverage.
So, the great ones aren't lone mercurial artists.
They are the ones who are, in fact, very good at the craft. AND they also got good at writing things down for self/other, and teaching other people what they know, and creating a culture of enthusiastic open-minded curiosity, whether on an IRC channel or in a packed fancy conference auditorium.
Once-in-a-generation brilliance is optional. The rest is not.
e.g. Brian Kernighan will be the first one to tell you that Ken Thompson was in a league of his own compared to Brian. But Brian himself is a 10,000x programmer. How much leverage have his book(s) and software and generous public education created in the world?
Anyone can become a 10x version of themselves (next-year you is radically better than today-you) if they think about that and learn to be like Brian (think, do, self-teach, other-teach, spread infectious enthusiasm).
Edit: clarify prose, and fix embarassing name snafu
>Not really. How do you quantify tech debt? How do you quantify the tradeoffs that someone made to add new functionality?
Time is quantifiable and comparable. Time spent on making things happen and then dealing with the consequences. The percentage of people leaving the organization in their first year is quantifiable.
Tech debt and tradeoffs from the previous feature will show up either as time spent on adding the next one or time spent on fixing bugs. Estimating is difficult, but measuring and figuring out post factum what amount of time was spent on yak shaving isn't exactly impossible. It maybe be uncomfortable and self incriminating, but that's a culture problem.
totally agree
a team with full of 10x engineers would just introduce new techs every month, if not they would get bored pretty fast and leave the team anyway.
most of the time normal engineers are more suitable, especially during maintenance phase where there are many boring/ repetitive tasks
What the heck is going on here with people's understanding of what 10x means.
Listen, a 10x engineer is someone who does the work of 10 other engineers, not closes 10 times the tickets, not pretends to do 10x the work but really it's just making things more complicated.
Sometimes being 10x means you are extremely careful and you don't have to go back and rework stuff.
Sometimes it means your work unlocks 0.1 extra value out of 100 other engineers.
You can say that 10x engineers just flat out don't exist but it's a whole lot of cope to say that someone who actually gets 10 times as much work done is actually bad because you knew one special boy that was really a disaster.
I wish people at my cccurent company would understand this. Right now even bringing what you think is good idea to improve project in any way seems like kind of like dragging yourself through barbed wire.
Whole company seems to be built around group of 10 people and if you idea differs from what they think they, in best case scenario, thet will just simply ignore you. On better days you will get lengthy discussion that will lead to exactly nothing. On worst days they will just simply make fun of you or say something like 'this is just wrong' without going into details what is wrong exactly.
There are plenty of good engineers there that learned to be just complicit, indifferent or afraid to speak up.
This article adds to the conversation of the 10x engineer. They are only 10x because 1x engineers exist.
They are only proud 10x because their narcissistic self looks proudly at 1x engineer in smudge fashion that they are better than someone else.
They are 10x because the system is stable enough and beautiful enough to allow for them to be 10x, and also allow for the 1x engineers to be good enough.
So lets champion the system and the normal engineers out there.
I'm seeing more reactions like this. I wonder if it's a consequence of reading AI generated drivel and not being able to tell content apart. Or perhaps people is asking for more action and less reaction. I don't know.
My reaction is due to influx of empty shower thoughts about generalizing large swaths of people and putting them into “normal”, “10x” or whatever bullshit author wants to identify themselves with. For some reason those articles attract a lot of discussion online, but thankfully they don’t leak into real life.
I find them very counterproductive, because instead of discussing actual issues and problems, people spend time justifying by all means that they’re in the “right camp”. Go outside, touch grass and actually talk to people you work in your org. Though I suspect most of those are written by ”influencers”(barf) that easier never worked with real people or don’t work anymore and want to sell their snake oil as ultimate truth.
> 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers
If you think a great (10x) engineer has bad social skills, isn’t a good mentor, and isn’t a strong teammate… you’ve never actually worked with one. What truly makes someone a great engineer is being technically impeccable and having next-level soft skills.
I once worked with a 10x engineer who I could hand new backend APIs to and have a brand new ui component that supported the behavior in less than a day, consistently. I have worked with 10x engineers who spend hours on calls walking junior engineers through problems they're having. That's part of being a 10x engineer – what this article is talking about is random 1x engineers with a chip on their shoulder and unshakeable arrogance.
Not sure if this was your intention, but you’ve pulled these words out of context, making it seem like the author is making this claim, when in fact the author writes that to describe what others claim.
> Most of us have encountered a few software engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to nonobvious yet elegant solutions, or emit waves of high-quality code at unreal velocity.
> I have run into many of these incredible beings over the course of my career. I think their existence is what explains the curious durability of the notion of a “10x engineer,” someone who is 10 times as productive or skilled as their peers. The idea—which has become a meme—is based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (for example, 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers) or blatantly double down on stereotypes (“we look for young dudes in hoodies who remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.
> I don’t have a problem with the idea that there are engineers who are 10 times as productive as other engineers. The problems I do have are twofold….
Exactly. While 10x (or whatever) is possible on pure technical ability, I would argue that the majority of engineers who provide outsized value do so through enabling others to do their best work and unblocking the wave that raises all the boats, rather than coding by themselves in a dark room.
That is a nice theory. But if someone is doing 10x more work, they get 10x more emails, and 10x more mentoring. They are not rude, just very very tired!
10x devs do not do mentoring and "social skills", because it does not scale. They write readme, maybe record a video, and move on to next task. If you have a question, send email and you get response latter! Sitting all day on meetings kills productivity very fast!
Buttering someone up, just because they are lazy to study documentation, and somehow they have power over you, is not a team work!!!
"A truly great engineering organization is one where perfectly normal, workaday software engineers, with decent skills and an ordinary amount of expertise, can consistently move fast, ship code, respond to users, understand the systems they’ve built, and move the business forward a little bit more, day by day, week by week."
This is the key message in my opinion. I've worked with wonderful software developers who can accomplish far more than others (as well as a few who are a net drain on the team.) The key is to craft an organization that allows anyone with a minimum skillset to be successful. At least on the team that I'm currently in, this means a well-defined organization with clearly defined limits of what they should and should not do. This is with respect to customers and also internally.
I have twice, but it's always huge companies ($billions and 100k employees) who has an established business, and some kind of monopoly which could not threaten the survival of the company.
> “10x engineer” makes it sound like productivity is an immutable characteristic of a person.
Because it is. Traits like intelligence or dedication really fluctuate during person's lifetime.
> If you have services or software components that are owned by a single engineer, that person is a single point of failure.
If you have a service owned by a person, you have a single entity responsible for this service. If you have a team of 10 people owning a service, each person gives only one tenth of a fuck, making any change take ten times as much time as it should, and there are ten different visions of the project playing out at once.
> The best engineering organizations are the ones where normal engineers can do great work
Strong agree. As an 10x engineer in an organization of 1x engineers, my life is perfect, because I get my shit done in one hour and go home and nobody gives a fuck. In an environment of 10x engineers I'd need to actually work 40h a week.
> Build sociotechnical systems with “normal people” in mind
Valid point. My manager asks me how do I do this that I deliver projects on time, they work correctly, and people are happy to work with me. The answer is simple: I treat everyone like an incompetent lazy fuck. This assumption allows me to create designs that are much less likely to fail.
You can see example of this by studying how big tech works. Usually they replace individual creativity with processes for people who can't think.
> A great engineering organization is one where you don’t have to be one of the best engineers in the world to have a lot of impact.
Not possible. Either you're a 10x engineer, or you're a cog in a big machine. Can't eat a cake and have a cake.
> Don’t hire the “best” people. Hire the right people
Even Google eventually realized that if all you incentivize is 10x engineers, you end up with a sack of cats clawing at each other for advancement perpetually and spend a fortune on trying to retain enough institutional knowledge to do the keep-the-lights-on work. They removed the "Engineers at this level are expected to continuously improve and seek more responsibility" language from several higher rungs of their expectations ladder.
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.
You have just written down a partial solution to this dilemma: make these high-paying jobs less attractive in terms of status for these wealthy families. :-)
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...
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
And that's why all applications are laggy as shit these days.
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
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.
As a reminder: Bill Gates, who is certainly old school tech, was born and raised in an objectively wealthy, well-connected family, then went to Harvard. This is nearly made-for-TV silver spoon stuff.
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.
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.
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.
Even for the folks that have an ecological focus, there's quite a few methods developed with limited degradation of the landscape, and reclamation of the mining sites into alternative uses (park, forestry, entertainment, tourism). The Wieliczka saltmine in Poland's an especially impressive example [1]
[1] https://www.wieliczka-saltmine.com/individual-tourist/touris...
And these days, there's also a huge number of resources in terms of mineral identification and site mapping. The EMIT Imaging Spectrometer from NASA's a cool example that does remote satelite mineral identification from orbit. [2]
[2] https://earth.jpl.nasa.gov/emit/instrument/overview/
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.
You could have an indoor pool in a detached building. You could keep horses. You could have a 6 car garage. All the upgrades from the builder too. All for a song in comparison to a home a fraction of all that in the bay. I mean just start looking on zillow between these sorts of homes in say indiana or ohio and it is absurd the difference in cost of living. How much you'd have to pay to rent a tiny old boat on lake tahoe for the day vs buying a boat outright and even paying to winterize and store it in a yacht club on a great lake. SF country club fees vs midwest, literally exclusive fuck you old money rates vs only a couple thousand initiation fee for the same sort of course conditions and probably a nicer appointed newer constructed clubhouse in the midwest. Same is true for the private schools too, the nicest ones nationally recognized in the area can only charge so much because there's just so many people with kids and wealth in the private school market so they aren't absolutely stupid like in the bay. Even the public schools go up to bat with those in some districts.
I don't think "the data" you might cite are considering all of these factors of the lived experience. Maybe one or two economic indicators but not how life actually plays out with even the half dozen or so things I've laid out above.
But that is blatantly not wealth? For a topic so humorously numerical, this entire comment is decided not.
> You want actual property, with some setbacking from your neigbors
First, not everyone wants these things, and even quality-of-life is not one size fits all. Second, this is also not what wealth is.
> You could have an indoor pool in a detached building. You could keep horses. You could have a 6 car garage. All the upgrades from the builder too. All for a song in comparison to a home a fraction of all that in the bay.
Uh, duh the midwest is cheaper than the most economically productive region in human history. Thanks for explaining.
As an ex-Cleveland resident who now lives in San Francisco, I can confidently say that these trappings are not available to most midwesterners nor Californians; neither tradesmen not high skill workers; and its also still not wealth, although it is certainly more closely correlated.
Anecdotally, you couldn't pay me to own a horse, nor do I even have use for my single car - owning 6 seems like a waste when on-demand self-driving vehicles will shuttle me effortlessly around San Francisco.
> I don't think "the data" you might cite are considering all of these factors of the lived experience
Because that's not what the words in this conversation mean.
> Maybe one or two economic indicators
That's what these it means. And they're not in the favor of a tradesman in the midwest.
> not how life actually plays out with even the half dozen or so things I've laid out above.
But what you laid out (quite condescendingly btw) is farcically not the meaning of wealth, and not the indicators of a good quality of life. I can name a long list of things that the midwest can't provide to the wealthy that are readily available to working class people in California (eg. an extra 100 days of sunlight a year). But I won't because it's obvious and not the definition of wealth.
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.
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.
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.
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
This joke is like a decade old at this point https://xkcd.com/1172/
Namely, what does the following code do?
If the compiler truncates, x will be 2 (assuming it allows variable reassignment), and you've probably introduced at least two bugs. It's doing some sort of lookup against the source, well, all bets are really off.“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?
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 I was designing a software system, I could introduce a time constraint. An imagined conversation: "How long will it take to get an answer? Between half a second and the heat death of the universe. OK. Can we just issue a timeout error after 1 second?"
This is putting controls in place so the system doesn't exceed its constraints and although hypothetical it might be able to do a job for any input, it can't because we haven't been able to find a more efficient solution for certain known and unknown scenarios.
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).
I think that you have a basic grasp of the word "dimension" but use the word "euclidean" without understanding what it means just because you heard it in conjunction with "dimension".
If you think that e.g. building a bridge is a three dimensional problem in the sense that you are actually talking about (which has nothing to do with euclidean geometry), you lack the basic understanding of what you are talking about from which you could draw any conclusion like that with any sense of intellectual honesty.
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.
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.
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.
Different jurisdictions have different tax rates.
Where did I say that? There are definitely people who straight up break the relevant laws and don't pay their taxes.
Of course, whether someone breaks a law or not, is an issue independent of 'fairness'. But I don't know what you mean by 'fair'.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I believe PP is correct: the cost of "going 10x" is greater than its benefit in the long run, and often in the short run.
Henry Ford lowered the Ford company work week from 48 hours to 40 hours to improve cars manufactured per labor-hour, and to give employees leisure time to drive places (increasing demand for cars). Wages were raised to compensate, further increasing loyalty to the company while enabling employees to buy more cars.
For software, a 40-hour week may not be optimal, I tend to think that it may be too high rather than too low.
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.
For a long time, OpenSSL, the standard encryption library used in everything from global banking systems to embedded devices, was built and maintained by two full-time engineers. It took the Heartbleed episode in 2014 to publicly acknowledge that potentially millions of technical projects stood (at least in part) on the backs of two nameless individuals along with the contributions of a small number of itinerant volunteers. While teamwork can be an important if fickle instrument, it tends to be a lightning rod for inviting too many cooks into the kitchen. What is often downplayed or goes unsaid in these commendations of teamwork is the place of an individual mind as the wellspring, the sine qua non, of great ideas and projects, including software. As is often the case, one person can solve an issue that has stumped thousands of others. Such individuals tend to work at a faster pace alone than the de facto committees that teams often become as they lose their agility, foresight, and focus. Unlike a football team, coding doesn't require a minimum number of people to achieve greatness. On the contrary, the opposite appears to be true - that there's a Dunbar's number for doing good work.
OpenSSL was made by a team, just read the history.
> For the first 15 years, OpenSSL membership was mostly a small collection of individuals working on a part time basis and the membership fluctuated and changed through those years.
I never claimed OpenSSL was the product of a lone wolf or that teams have no place in coding. The essence of my point is that the invocation of "teamwork", often as a concept and practice distinct from the sum of its parts, obscures the significance of individual contributors who making great software. After all, code is a mirror of the mind. That one can distinguish between great and not-so-great code implies that one can distinguish between a great and not-so-great coder.
There's only so much code they write per unit time, only so many designs they can consider, only so many meetings they can attend, only so many demonstrations they can perform, only so many regressions they can debug, and really, only so many domains they can master.
Solo projects written by excellent engineers can be stunning works of craft. Many of us prefer to work that way, and accept the compromises of scale or time that are associated with it.
But most projects that you're familiar with need a team to produce them in a way that meets their real-world time and resource requirements. That's where the sports analogy comes in.
(And the same is true for the blacksmith and tailor. One master blacksmith or tailor might do stunning work, but they can't outfit and army or dress a court ball on their own. They need support, and that support often needs to be of a different level of mastery than themselves, if for no reason but to facilitate needed coordination and deference.)
E.g. https://bellard.org/
To add to the insult, I'd challenge you to think of how many "great teams" of "normal" engineers, whatever any of these terms means, could pull off most of these projects in any amount of time.
Great professionals exist. They produce great work that is tough to reproduce. Your "helping" them does not mean they couldn't have done it without you.
I have contributed to one of the projects he originally authored, and my mundane contributions along with other volunteers not as brilliant as him have ensured the continued success of the project. I'm with gp: teams ship software, not individuals. Individuals may ship bug-fixes or largish features, but for software in the large, that is the realm of teams.
I've been there & done that: I've been the person that crunches and turns around impossible situations, and I have also spent months cleaning up after a 10x engineer who shipped a feature in "record time" that made the company lots of money but caused countless support calls and bugfixes for months on end until it stabilized. Many so-called 10x aren't, and rely a lot on a supporting cast of regulars to enable their "outstanding" work
There is also a time dimension to software. I have been on some occasions the only developer of pieces software that were tackling hairy problems that teams of "normal" developers would avoid. I always wanted to solve those problems in a way that would make everyone's life easier. To do that I had to spend a ton of deep focus time on modeling the problems effectively, and if I was successful, people who were put off by the problem space would come and contribute, because they found the model amenable. Or they thought it'd benefit them to be a part of a project that's picking up steam. A lot of these people would fix small issues here and there, but some of them actually donated a lot of focus and helped take these projects to new levels. The ones making the deep changes always cared deeply about the problem space, or brought a lot of knowledge from another subset of cs, and I wouldn't call them "normal". I think it is a disservice to the sacrifices they made to do what nobody else felt like doing and throw a blanket statement like "teams of mundane contributors do the really important work".
This is not a dig at "normal" devs - I have been the "normal" dev on many projects, but because of my experiences I try to give credit where credit is due.
I also detest the 10x thing exactly for the reasons you pointed out.
strange example, considering that the super-smart owner is purely a delegator at this point, and there are thousands of contributors.
Unless your project's scale is reasonably small and focused -- representing the equivalent of a true solo or duo sport like tennis -- you need committed, professional "normal" team members to flesh out the team or you'll just never have enough resources to get done everything that needs to get done.
People who describe themselves as "great" feel such work is beneath one and know there's only so many hours on earth. Easier to pay a grunt to do that instead. And hence power dynamics are established.
That ego alone is why a team of only "great" engineers is bound to fail. You have a bunch of strong but negative polarity magnets trying to stick together. It simply won't be allowed.
It's a shame some can't apply such metaphors tk humans and think "no, sure, there are single processors thst outperform entire distributed networks" we're different".
The guy who can roll his own probably also has a better idea than most what easy off the shelf solutions are out there.
Which is why I have learned to stay away from people who use that metric.
In 3-4 years when you need to make a drastic change, that’s when the actual business impact comes into play, but this is never measured.
In my experience with some groups, waiting another 2-3 months to do things correctly would have saved years in future work.
What a great environment to train juniors. Does not sound toxic at all.
Junior does not mean incompetent, it means unexperienced.
In the grand scheme of things, the 10x-100x engineers work gets attenuated - think of it as some kind of averaging filter.
Do you think some 10x engineer carried the moon landing? or the Large Hadron Collider?
Sure, if you work on some dinky team single-digit number of workers, the contribution from the 10x engineer will be more apparent - but as the number of people involved increases, the more important the average is.
It is about programming languages and tools, about database design/schemas.
Choose the wrong language/tool for the job and the amount of work needed to solve the job easily expands 10x.
Guido van Rossum and James Gosling and Anders Hejlsberg likely have reduced the amount of work by 10x for a lot of projects compared to implementing them in a lower level programming language.
Average, is of course relative to the sample. If some "elite" company only hires 10x engineers, there's likely not going to be any 10x engineers there. The most productive engineer will probably only be slightly more productive than the worst.
If some other company has zero standards for hiring, to a degree where you can basically pick anyone off the streets and put them to code, the best will probably Nx (where N is very large) more productive than the worst.
But even then, there are so many dimensions and aspects to this.
The Roman emperor could make or break entire regions by vaguely wagging a few fingers. If and when he made a good decision - which could often easily be attributed to good luck - he could be, and was, heralded as the best thing since sliced bread because he saved millions. Such power surely must be divine. I don't think so.
Not saying Linus or Guido aren't competent engineers. I'm just saying that I don't think they are the sliced bread many make them out to be. They are good. Lots of people are good, but not many people get to be the first to create Python.
And, to be frank, Python - and its ecosystem - and me are through the honeymoon phase. Let's just say the chemistry has worn off and I'm not quite so sure Guido is the net positive we think he is. Maybe Python replaced some other upcoming far superior language. We can't know. (I suspect it did.)
In general I don't think individual/personality worship is a net positive on any axis.
In the organization I work in we have an operations team to take care of day to day failure. Write a run book, set up ticketing, hand it off, good to go. I treat this work and hand off as a high priority, as it frees up my time to work on other things. The ones who are chronically busy and appear to be “carrying the water” don’t do it. Their time is dominated my support, they are constantly busy, and it looks like they are doing a lot… but they’re doing work that can and should be handed off.
I’ve been the water carrier as well, but always tried to skill up people any time I had the opportunity. Or I’d build tools to make it easier for people to help, or find a niche where they could be useful doing something that would really improve things that I either didn’t have the time or interest for.
Get rid of team members that make your life harder. Keep the ones that make it easier.
> Individuals ship software not teams
I can’t see how this is remotely true outside of contorting some definitions of “ship”.
For a lot of stuff, one guy who knows what he is doing is worth infinitely more than any number of engineers, because this job is mostly about knowledge, not labor hours.
Even in a regular enterprise web application, one guy whose just more skilled in architecting solutions is insanely valuable. You dont need a bunch of engineers writing a bunch of inconsistent/unthought out apis and architecture, you need one guy to lead it
I think it says more about the size of the project and the complexity of the task that you've worked on, rather than "10x engineer vs normal engineer". Not even at a 10 person startup have I seen "one" person done everything. Unless you're talking about someone just forking OSS and gluing it together, to make a carbon-copy application of something that already exist(for free) then sure.
Edit: >key person took charge and made it happen
person - singular.
made it happen - it's hard to call an engine a car. to make something happen, you need all the component (contributions).
I didn’t say that. Read it again.
It’s not even the same person every time, people trade off being that key person.
> I think it says more about the size of the project and the complexity of the task
You have no idea. Please address the ideas rather than making personal assumptions.
> It’s not even the same person every time, people trade off being that key person.
So it's the role that delivers software? I think I agree with that. Even so, that role cannot function without its support system (the team).
Understanding this distribution of productivity is a great litmus test for a manager. If they say the distribution of productivity is shaped much differently than this, that is a red flag. They probably can't tell who is contributing, and you can't trust them to do the basic functions of hire, retain, fire.
The article reads like it was written by a manager with tunnel vision. A manager's value-add comes from making a bunch of "normal" people productive, while staying out of the way of the few engineers who will deliver >50% of the value anyways. If you only focus on making the normal people productive, you are only doing the additive part of your job, and neglecting the negative part, which is to recognize and not interfere with the high performers. I would imagine this guy goes around creating lots of least-common-denominator systems/processes, which drive away talent and make the high performers less productive.
> It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams
There's plenty of otherwise "10x" programmers who go outside of their strengths and suffer for it.
Indeed this is one of the hard problems for a manager.
We're currently in deep shit because a long term dev was under the assumption that you can only instantiate objects once. He built an insanely complex system around the belief, which shipped. Our users used that system to write configuration files that now drive a machine that cost about half a billion dollars. So we can barely change anything because the data must be supported for 25 years.
The cost of such fools is orders of magnitude higher than their salary. I'm convinced that the world would be a better place without bad devs. Everything would be faster with less people, too.
But you still need people to actually care about their work and get it done even when it’s not “hard”. Someone who could be a solid engineer on one team could be a “10xer” on another team just from caring about the project and consistently putting in the hours on it, if their team is mostly coasting by doing the bare minimum or highly underskilled. In fact I think many so-called 10xers may just be solid engineers who found themselves in workplaces with a culture of “not my problem” or “I can probably stretch this ticket out a few weeks”.
Conversely if you take someone who might be a wizard on one team and drop them into some super complex “engineering catnip” project they might just be seen as a solid engineer there. I think cases like that demonstrate the author’s point pretty well: if you design the project’s processes and tooling around the wizard’s wizards who eg dont use debuggers because they have some insane skill with tracing running binaries you are missing out on the productivity you might gain from the less skilled engineers.
Both have their place. On the topic of greatness (your example, Linux, as opposed to say a build script for vending machine firmware) I couldn’t agree more with both you and the people disagreeing with you.
LoL?
By that logic CEOs are super humans too, cuz they own the companies? :D
>A players hire A players, B players hire C players etc
Where did you hear it?
The "complacency" and "mediocrity" you mention have deep roots in politics and human psychology and I'd wager less than 1% have anything to do with tech. One of the many things you do in a business is wrestling with such monsters as capitalism and its various types of dysfunction and a plethora of other nice human factors such as hunger for prestige, power and social status.
To give a concrete example: at the moment I am quite ineffectual at work and the core reason is that I just don't give a flying F. I wasn't always like this. I distinctly remember not being like this. I was made into this and I'm sick and tired to pretend it's actually my own fault.
It's sad to see us engineering types being herded by power hungry psychopaths into arenas where we fight eachother to the death like roosters to see who is the "10x".
This is true at time T. But over time (can be as short as a matter of weeks), it is not anymore. Team work, interactions, support, resiliency takes over, in a good way.
And that's a good thing, because that's how you build relevance for your work.
If your take on managing your team is fighting complacency and mediocrity, maybe it's the hiring/training/managing process that ought to be reviewed _first_.
The number of times I've reviewed someone's code that's been "in progress" for 3 weeks, to see it's 200 lines of simple python code... ugh
"oh, but it was really actually complex and you just don't get it" --> Incorrect
I worked once with a young engineer that spent 3 weeks for 2 lines of code. We celebrated him as a fucking superstar, because those 2 lines were in a low-level linux library, and he went so deep to find that bug, it was insane. He earned the reputation as one of the top problem-solvers in a multi-hundred person org.
So that's not what I'm talking about. I'm talking about the developers (so many of them) who spend 2+ weeks in standups saying they're "working on automating the deployment", and when it's done you look at their code, and it's an argparse block followed by 6 lines of calling docker with trivial parameters. You've seriously never seen this? Lucky you, then.
Which is completely wrong.
I understand that complex problems can (should) be solved with simple code. That's not what I'm talking about.
Simple problems should be solved with simple code, and good developers do this quickly. If someone takes 3 days to figure out how to make a one-line REST api to a well-documented service, they are not productive.
Maybe I just unfairly expect developers at top companies to be able to not get stuck at every step and to not get confused by basic programming. I probably just need to recalibrate and understand that what I consider to be slow developers (certainly by comparison to the many excellent people I've worked with), are actually the norm, and I should just be OK with that.
You can have a single genuinely senior 10x engineer oversee all those efforts, executed by "normal" engineers. But no, not execute them all by the 10x engineer's self.
If you measure something meaningful it's teams. If it's LOC or some macho measure of productivity (rewrites in Rust using the hardest frameworks) then yeah it's those "tenexxers".
- There is no "10x race horse", as there's different kinds of horses who win different kinds of races (and those horses don't win consistently). Similarly, "10x engineer" would imply there's only one kind of engineer, one kind of engineering, or only one way they can be productive. You can certainly find a "person who is very productive under certain circumstances". "10x engineer" is an extreme oversimplification of a generic person doing a generic job; but people aren't generic, and this job isn't generic. There just is no "10x engineer". It would be the coder equivalent of the Übermensch.
- It's not a good idea to bet the farm on one lone genius. They could get hit by a bus, be hired away somewhere else, or just not be "inspired" by your company or team and end up not producing. Instead build a team of competent and diverse individuals led by a decent leadership/management team who can create consistent results without having to find a magic wizard coder. (Personally, if I found out someone in my org was risking the business on a single person that was impossible to replace, I would be upset)
- There's just not that many super-talented people out there. The few that are, pick where they want to work; you don't hire them, they hire you, so to speak. And even when you think you've met one, it may actually just be bluster or a false reputation.
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…
But for certain kinds of software development, a team of "normal engineers" can't do what a single 10x engineer can do. For example, how many "normal engineers" would you need to replace an Ilya Sutskever? The answer is you can't. Because intelligence is not stackable.
No disagreement there at all. "Normal engineers" are all you need for "normal software" such as CRUD apps.
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 developers just care about getting the job done regardless of care or code quality, which in my experience has led to conflict.
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.
More so if in the light of day their work sucks.
Discussions about 10x engineers are not about “wannabe 10x engineers”.
—
I have yet to come across an intellectual area where there isn’t a long tail of higher talent.
As the “x” goes up they just get more rare in reality, and even rarer to see. Because they are not always being optimally challenged. Most problems are mundane. And optimally challenging workers isn’t really a business plan for anything.
I think there is such thing as a 10x problem, which you have to find before your 10x engineer really shines. Identifying hard but exceptionally valuable problems to solve takes 10x vision. And time and luck.
If a "10x engineer" is not given 10x problems, they will.. create some.
A 10x engineer that pushes a problem to prod is not a 10x. You get to 10x by not making mistakes, any issue you create sets you back ten squares.
This kind of reply is just flipping the stereotype and going in another insane extreme without any evidence at all, just conflating productivity with recklessness...
If 1x is the absolute rock-bottom lowest possible productivity, are them really the precious angels who care deeply about the user while making amazing code?
This is even more absurd.
You understand the original meaning of the term. This is not how most people use it nowadays.
The assertion made by GP is absurd regardless of the definition, period.
But can we stop saying people who are good at there job are actually bad at their job and being mediocre actually means you are great?
Like I know I'm being pedantic but this kind of culture is toxic to everyone.
Edit: sorry for ranting under your comment. I'm sure you are a normal person just trying to get through your day. I just had to scream somewhere
People who claim they are 10x'ers are often not. They are mess makers or wannabes. They appear 10x to those who do not take messes or tech debt into account.
You screaming (to use your lingo) that my buddy above is not a 10x is what the rest of us have been screaming about our co-workers!
I'm not claiming people can't be 10x'ers. Nor am I saying being good is actually bad.
In any creative industry Price's is well known phenomen. 50% of work is done by square root of people. But in reality there large number of problems that cannot be solved by average developer.
That why people that build tooling, compilers, important libraries and frameworks make often 100 times more impact. They increase productivity of everyone
This myth that more productive developers are somehow worse and will ruin projects is just rationalization without any ground in reality.
This is just rationalization.
e.g. Linus is a classic 10x or 100x engineer and his code(Linux, Git etc) has been maintained by a completely uncoordinated team for decades.
And the 10x you mentioned are not 10x. They are 1x with frenzy.
If one is not multiplying the team output, they are simply 1x or lower (maybe a few exceptions)
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.
> 1x is normal.
IIRC the post that came up with the 10x and 1x terminology used 1x as the worst performer. Normal/average was somewhere in between 10x and 1x.
The change to 1x being average in the common understanding seems to have happened because even the people criticizing it have an intuitive understanding that it's correct, they just want the boundaries somewhere else.
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.
I've seen it first-hand. We ended up building a support team around the 10x:er to keep things working, but it was easily worth it. It worked very well for the life span of the product - about a decade.
Many eventually graduated to pretty fancy places. They learned a lot. This particular 10x:er loved sharing knowledge via pair-programming.
Well, he was always in command of the keyboard (typing insanely fast), but you'd sit next to him and he'd delight in explaining. Eventually you would challenge him on something and then the collaboration/adventure began.
I have had the most intellectually exhilarating times of my life working with this guy.
So yeah, 10x:ers can bring massive value if they are wired to be really nice.
I've met that an instance of that kind of 10x:er (well, 5x:er, in this case). He defaulted to dismissing everyone until they had proven themselves.
I don't think there is much you can do to "improve him".
Does the company have my best interests at the center of their efforts or I can be shown the door at any given moment to please shareholders? No hard feeling pls, it's just business and I have only one life to enjoy.
Anyone wanting to improve their resume or have fun from 9 to 5 is in the right here. Life is short.
However it is my responsibility as a manager to ensure the team is working towards its goals and nobody is making anyone's life difficult.
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.
The key to a great team is great leadership.
Most people are terrible leaders, and they think that what they are worth is what makes them leadership material, even though they didn’t earn that worth themselves and didn’t put in a hard graft.
The key to a great team is a fucking team. Only then can there be a leader.
Let’s talk about ‘normal’ CEOs, 10x CEOs, and for that matter, ‘retarded’ CEOs, considering a particular one of them favours that insult. That’s the implication of ‘normal’ in scare quotes no?
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
It doesn't happen very often, but when it does...
It's never an execution problem, it's a management.
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?
I run a technical recruiting company, and we ask candidates a question like [2] on our interview (EDIT: we ask other stuff too, this is only part of it). It's not exactly fizzbuzz, but it's really not far beyond it. A candidate we interviewed just a couple days ago took that problem and couldn't even complete the first step. This is the equivalent of asking someone applying for a job as a statistician what the distribution of the sum of two normals is, or asking someone applying for a job as a con-law lawyer what the fifth amendment is, and having them go totally blank.
Is it conceivable that they were just having a rough day and their brain hiccuped really badly? Sure, I suppose. If we did ten thousand interviews, we'd probably have at least one person who is objectively great perform that way.
But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.
-----
[1] https://news.ycombinator.com/item?id=43006330 [2] https://www.otherbranch.com/shared/practice-coding-problem
Maybe I never encountered your perspective; in 20 years in the industry, in about 10 significant software prod/consulting companies, we never outsourced hiring or pre-hiring. From my experience and perception, minor coding tests are a hiring filter than does not gives good results, for both sides of the interview.
You want to hire junior candidates? that test is fun and maybe ok an indicator. Having them live comment/describe/solve existing pieces of code is much more effective and fast. They will still demonstrate ability once on the job, that's what juniors are for.
You want to hire experienced (or even senior) candidates and filter for domain knowledge? 1. Filter on experience & referrals. 2. Conversations: same approach as with the juniors, but much deeper and wider, relevant to your domain. 3. Call at least one reference to counter-check.
A generic fizzbuzz/minesweeper (remember also "code a functional basic blog engine with comments in 30min" back in 2006) coding test demonstrates (in my very subjective and limited opinion) laziness and kind of a lack of interest in the candidate from the hiring person/company.
I understand that when you screen 1000s of people, it gets massive and more basic filters may apply, at least at first contact, though.
> But would you bet on that? Bet your team, your product, your company, your mission, whatever is important to you, on their ability to get things done? I don't think you would. And hiring (and everything else in business) is about making good bets, not about batting 1.000.
I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.
The reason I don't believe in (1) is that the candidate I described in my previous post claims nearly fifteen years of experience, some of it as a lead, and completely bombed our entire interview. Referrals are another matter (and they are indeed an excellent channel when you can get them), but they tend to be pretty low-volume - if you're hiring from the general public at all, presumably referrals didn't get you what you wanted.
By the same token, the majority of people we've placed so far were people whose resumes didn't particularly shine - but who turned out to be very good engineers when given an opportunity to actually work on a problem. (That isn't just my opinion, it's the opinions of the companies that hired them.)
For (2), I agree. We do do that as well (coding's one of three parts of our interview, not the whole thing).
For (3), have you ever had a reference give a negative review? A lot of companies make it outright policy to do so, and iirc there are legal restrictions on employers doing so in a lot of places. I wouldn't trust that with any reliability (although it's still good practice 'cause it's cheap).
> I've seen more rejected candidates because of "soft skills" failures than because of technical skills. And much more fired for behaviour than for technical/performance issues. Domain knowledge can be trained, fixed and integrated within the company. Behaviour cannot.
Of course soft-skills matter! I never meant to imply otherwise. But soft skills will only get you so far if you don't know how to do the fundamental responsibilities of your job.
As for (3), I never got _negative_ reviews, rather confirmations or hints that confirmed what emerged through the interviews and either lead us to stop the process (rare, but happened) or helped adjusting the position and onboarding to better fit the hire.
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.
I also don't buy into the 10x pushback, there's not only 10x engineers, there's 100x engs. Easy to prove, can you think of an engineer that adds negative value? That deletes tests, or breaks stuff? That adds left-pad to package.json? Or log4j? The bigger the org the bigger the damage. Boom, you have a -1x engineer, and conversely a +1x engineer. If they do a lot of damage that's a -10x engineer. If they do some damage and contribute a little bit maybe they can get into positive numbers, and you have a 0.1x engineer, therefore there exist 10x engineers (and 100x and 1000x and inf and -10x engineers.)
I do agree that performance is not quantifiable (or very hard to quantify) and that it is not a property of an engineer ( although the article suggests performance is a variable of teams or the org, but I would say it's a property of the engineer-product pair)
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.
What starts off as a simple write() call balloons into a complex system as it evolves to meet your needs. Only then will we know if a great developer was behind the wheels, by how easy it is for the next person in job of maintaining and extending the system to fuck something up due to a lack of context and experience.
Another sign of a real 10x engineer is an even temperament and a lack of arrogance, as being a team player is important in any environment. You can't be a 10x engineer in a vacuum.
> a real 10x engineer is an even temperament and a lack of arrogance
Super subjective, but I see the 10x engineer as being arrogant, you have got to if you are really 10 times above your peers. Although it's true that some arrogance might come from a place of insecurity. Someone who is truly leagues above someone else will not berate them for being below, they will encourage them to improve or palliate them. Pointing out how the other is worse and they are better is argumentative, which usually a 10x anything doesn't need.
> Pointing out how the other is worse and they are better is argumentative, which usually a 10x anything doesn't need
I'll be honest, this post is a bit incomprehensible. You say a good engineer has to be arrogant, then go on to claim how such an attitude can be combative. Pick one argument, not two conflicting arguments.
You sound young. I understand that youth can sometimes lead to the kind of arrogant thinking in your comments, but real wisdom will start coming whenever you realize how this kind of thinking looks to others, stop making comparisons, and try to learn from everyone on your team.
I don't have it all figured out and I might use these posts to think aloud rather than espouse a consistent message
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?
Have you ever seen a product that got worse over time instead of better?
I find that it's the majority. Even if they get sales and more users. I'll list the exceptions: whatsapp, and even they succumb to bloat features like ai slop or stories or "communities".
If you take a wider period, all software gets worse with time(they die, nothing is forever).
If a bridge falls, will the engineer wash his hands?
Likewise, product managers and designers who are talking to customers and conducting user experience research have the context to make decisions that engineers can't reasonably second guess.
If an engineer doesn't have control or follows the designs of an architect, they are merely in an executor role, and their engineering skill is put to use not in inventing or solving a problem but merely executing.
There's a time and place for that, but it's definitely not the dream when I think of the engineer I would want to be.
In this dream, what is the role of UX researcher? Of product manager? How many such "elite" engineers are working on the product at one time? What's her relationship with the customer or end user? Are all the engineers on her team "elite", or is there only one? How does she interface with stakeholders? At what stage of her design process does she submit wireframes, prototypes, or plans for review? How much of her time is spent accessibility testing? How does she receive feedback about the product?
Like you, I've been happiest in my role when invited to share in the full discovery, design, and implementation processes from end to end; as a software engineer, I always look forward to engaging with customers/users and participating in--even leading!--research and design activities. But I also recognize that should our team be so lucky as to acquire a person more expert in those methods than I, the artifacts of their intelligence are only more grist for the mill.
> their engineering skill is put to use not in inventing or solving a problem
As Feynman put it, "there is plenty of room at the bottom," and as Cook said, "all ambiguity is resolved by actions of practitioners at the sharp end of the system," but if the first seven layers bore you, by all means, hack the eighth!
The thing I don't understand personally with these people is why they care so much about work when the rewards are not proportionate to doing so much extra work.
I get it if you're a founder of a startup but not if you're at a big company
Yet every big company I've worked at there are always 1-2 people on the team who seem completely obsessed with the project, like its their main hobby/purpose
It makes me wonder, if someone is so smart that they can do "10x" the work, would they not use that smartness to look at the meta of it all and wonder why they don't get 10x the rewards?
Pareto principle.
> why they care so much about work when the rewards are not proportionate
Some people are just work horses by nature. They're too busy fulfilling their idea of a "job well done" to worry about the relative fairness of their employment.
Not to mention being a 10x coder doesn't mean you can simply parlay your skills into the greatest possible rewards. There's a lot of important context that makes a 10x possible in the first place.
I think you figured it out.
What about truly enjoying your job and getting paid handsomely for it (compared to almost all other jobs) being sufficient to one's happiness?
Also, if you don't realise that being the one running the show is orders of magnitude harder than following the lead and doing your stuff then you never really done it before. Having ALL the control has advantages and many less obvious disadvantages.
I've been in the industry long enough now to see those 10x engineers having pride in their work get their mindset shattered because John from financials thinks they can juice the next quarter by laying them off.
If you want to have pride in your work as a supposed 10x engineer, work at 2x or 3x and save the remaining for yourself.
One (engineer-turned) manager I have in mind: show up at 10am, leave at 4pm, solve a zillion hard problems in the mean time. Are they 10x? If they save me 2 weeks of work with their insight then I guess I have to admit yes.
Lots of people are happy to just do whatever, go home and not work on personal projects. Plenty of people here defend it.
Why should productive engineers change their habits just not to be called a sucker?
I mean more that the optimal amount of work to put in is still above average but way below 10x
This is about how capitalism is structured it's not at all a matter of personal choice.
And that efficiency can translate in 10x output, but it's not guaranteed.
My opinion on the 10x engineer principle, always was that these people have their best development/debug environment setup. And they can traverse, run, and explore code faster than most. Like world record pizza makers in under a minute.
Through my career I've seen some engineers that were stumbling their way around their tooling after years of use, and some that weren't even touch typing. Factor that in.
Most of the >1x engineers I met can’t help themselves and be their best version.
sometimes, you just find fun in things and it's cool. other times, it's like what other other thing you gonna do? fish or hang with people or do drugs or dance? software's a hobby really. sometimes its more fun.
but really it's all preference.
That’s my experience, at least. Cleaner code, separation of responsibilities, and good documentation seem to help though. But I do think a lot of the time people are mistaking “more productive developers” with “devs who got stuck with knowing all the random shit that our horrible codebase relies on” lol
The reward is there allright, it just isn't monetary.
I think this is kind of a nasty attitude. I absolutely cannot stand working with people like this. Why would you insinuate that someone is stupid because they get more done? To me it sounds like you are just insecure about others’ output, so you have to tell yourself that it’s stupid and pathetic to be fully engaged at work.
Depending on the company and person they often are compensated much more down the line when they get fancy titles or apply what they spent more time learning/practicing.
Then other days I solve 3 problems for other people which are easy for me because I have bashed my head against those particular kinds of walls before. I suddenly feel worthy again.
I'm productive when I know exactly what I'm going to do but getting to that point is hard and looks like I'm doing nothing. I find that people who are more productive than me often just don't hesitate and take all the easy exits that I waste time worrying about. I can't give up on my style because I always feel happier with the result.
Sometimes they're just faster because they're repeating a successful pattern they've used before.
I have often had to fix code written by "reputedly" very productive people and it's not a rule but more than a few times it has been very brittle and unmaintainable.
What I'm saying is that speed is usually NOT magic. It's achieved in a particular way and that is sometimes not good....but you tend to find out later.
Who benefits from rhetoric about xN programmers? It's about extracting the most value out of you in an unsustainable way. It's shortsighted. If you're going to be productive while maintaining your sanity, it is an uphill battle. This is especially true for people who are especially sensitive to this kind of pressure, and can drive themselves into a wall if they aren't careful.
How can you meaningfully separate these?
I don't think decent skills and ordinary expertise gets you that, especially "move fast" on top of the other things. But the convenient thing about "normal" is I can move the goal posts wherever and it sounds valid.
The article also did not say how often the normal engineers produce bugs of varying severity, so I guess it's possible to move fast and create a manageable amount of bugs?
Their two big arguments are that 1) people aren't 10X at everything, they are at most 10X at specific things and 2) what good is a 10X engineer if they are on a team that can't perform at that level?
There isn't something magical about 10X engineers, but the fact is there are engineers who have developed the skills to greatly exceed their peers and work in those sub disciplines at which they have this skill. Who cares if your 10X mobile app engineer would be no better than anyone else at microprocessors, they aren't working on microprocessors. Likely anyone could become a 10X engineer, but most don't. It's like great athletes or great musicians - whom no one would question are 10X better than average even if quantifying skill in those domains is hard - maybe there is some level of god given talent but for the most part it's years of effort that other people just don't put in.
Then yes, engineering is often a group effort and a bad team can certainly hold someone back, but just as in sports a strong player can certainly elevate an otherwise mediocre team particularly if well utilized, a 10X engineer can massively improve the output of those around them. No one on earth would say it doesn't matter if our band had a great cellist because the rest of the orchestra probably isn't exceptional. If a team holds its high performers back, that's a problem with the team, not a limitation of high performance.
I also have had the experience that some colleagues had worked on optimizing an algorithm for months and months. I too had looked at the algorithm and one day, almost out of the blue, I came up with a short cut that totally avoided said algorithm and implemented the required functionality with some calls to a function in standard library we were already using. Again, I was met with disbelieve when I presented the solution.
I feel that I am the guy who about once per year comes up with an idea that no one else had thought about and that most of the time I am just not very productive and often find myself daydreaming and not being very productive.
I also feel that often I am far ahead of other with respect to ideas and that I fail to convince others about a my '(too) advanced' approach. I several times have been in the situation that I proposed a solution to a problem and that some kind of manager decided to go for a simpler solution and that after months of develop time, it came to be that certain functionality did not work and that it was simply decided that that functionality was not going to be supported anymore.
Due to changes in the input data, a simulator was crashing completely and very early in the simulation, making it unusable. We had to solve this quickly. The underlying module that was crashing had been written by a non-software engineer, and it showed. The project manager was trying to understand it and do the most minimal fix to it as possible. My solution was to rewrite the module from the ground up; this solved the bug, the whole thing is going 2x faster than the previous version and is much simpler. This day I should have been working on a bullshit, internal politics-driven license module, and thus I disobeyed the manager. I couldn't think of anything else anyway, the code has to "get out".
A few days after, I showed my thing and the client royally ignored it, preferring to continue with fixing the older, shittier solution. After 10 or 20 minutes they finally caved and accepted to merge my thing. I don't understand the initial reaction at all.
I once took up a lot of space to be a super productive engineer and only ended up being isolated. The business saw that some engineers were saying things worked great and were easy, so more responsibility was thrown on me and the other engineers moved to another project that needed headcount. Me and another guy ended up building on and maintaining what used be a reasonably sized team. It got on me because I made sure to know everything so I could make it as great as I could. This sounds good, but this particular business didn't care about me at all, I was just another gear.
I've met "productive" engineers that got things done really quickly from the business perspective, then moved on to being awesome somewhere else. But, they also took shortcuts, didn't write documentation, and made things unmaintainable. When I joined the team after they were being awesome somewhere else, I had to do things like guess hostnames and find out how and where things were running..
The people I've liked working with the most have been parents. The boundaries are more clear, they value stability, and aren't heros.
This isn't the worst thing in the world. I'd rather inherit something with little/no documentation that followed the standard business practices (e.g naming conventions, nothing crazy bespoke) and have to do an afternoon of investigation than have to read documentation that's inaccurate. Of course the best option is full documenation but due to the nature of business that isn't always possible.
And the key to great teams and organization is the "process", and not the presence of specific, 10x people.
But that means in such an org, you are just a replaceable cog. So from the point of a 10x engineer, you absolutely want your org to be dependent on you.
[0]: “The Myth of the Hero Programmer” https://matthewsinclair.medium.com/0061-the-myth-of-the-hero...
[1] http://mikhailian.mova.org/node/284
There are good answers, like John is an expert in the specific technology you're using and he was hired through a meet-up you sponsor; there are bad answers, like John has found a way to game the ticket system; and there are debatable answers, like John's team has a high support burden which he never helps with. If you insist on seeing him as a 10x developer through innate skill or divine fiat, then you're not going to look for the root cause of why he's doing more work than everyone else.
Once you define it as an engineer who ships 10x as much business impact (ships fewer bugs, builds the right features, etc), it’s less contested but also less glamorous and harder to measure. In fact you start to develop an inkling that such people may not even be the same coders you once idolized.
When we talk about 10X, it should be about comparing it to the least productive team member - the 1X. There is always going to be a 1X person on the team. That's not bad if the team average is 1.5-2X, but if the average and discrepancy gets large enough, you're going to have the 10-100X team member who gets a lot done.
Also, not all work is equal. The 10X engineer who is only 10X in programming may be a 1X in collaboration or documentation. That's not a good dynamic, either. Again, appreciate the point of the article, "build great teams", but we need the 10X person in each task to do that. If the build pipeline is slow and costing us money, I need the best people on the team to go figure that out. And, I need our worst engineer who is still learning to be involved so that they can grow their skills. Become a 1.1x, 1.2x, etc.
Hat tip to these articles on 10x engineer studies: https://jasoncrawford.org/10x-engineers https://www.construx.com/blog/productivity-variations-among-...
If you want to move the discussion of 10X devs away from the 10X dev then stop using the term "10X dev".
In any event, it doesn't really matter because engineering managers should just hire the best fit for their team. The unicorns are rare and expensive and may not be the best fit compared to just a stallion who likes to run.
Wise words for hiring managers.
This is often the opposite of the truth. That is, teams are much more often formally-owning software, but "owning" in the sense of actually being responsible and feeling responsible for its functioning, well-being, and strive towards polish and realization of potential - more often than not, it's one or a few individuals. If it's a large software system, a lot of people have to put in their work as well, but still.
I am occasionally in a situation where I feel more "ownership" towards a software project I have no formal responsibility for than I believe the formal owners do, and find the, to be poor stewards of that software. Not that I have the time to take over for them, but I have the motivation, and it pains me to see them mistreat it and mar it with unworthy merges.
PS - I am not speaking as a supposed "10x engineer".
This is a healthy perspective that hopefully avoids some of the controversy around the 10x label. Any improvement you make to how the team works together, be it CI process, sharing/evaluating ideas, code reviews, design, anything, is multiplied by the team size/responsibilities. Maybe high-functioning teams are part of what enable the 10x outputs that perpetuates the meme.
From what I remember in mythical man month it's sort of addressed there (different roles/support roles being just as critical as others) and recently reading "soul of a new machine" it was clear how dependent even the most skilled roles were on the other members.
How to hire and build a 10x engineering team remains a challenging problem however!
Hell, even by engineering standards, tech has a lot more extremely opinionated people - with more extreme views on pretty much everything. I've always wondered why it is like that.
One or two 'superstar' engineers who had been with the project for more than a decade were the only ones who understood the bulk of it. They had job security!
I often wondered if they intentionally created it to be that way out of self interest. It made things rough for all the 'normal' engineers who wanted to improve things but got pushback from them and management.
Oh and also, it wouldn’t hurt to qualify those skills to the specific domain to which they apply. Like “he’s a really good database engineer” or “he’s a great C# guy, but terrible at DevOps”
These articles are polarizing because they take for original assumption that the real world is discontinuous. That’s stupid.
Let’s praise the engineer that’s in the 2.5x to 7x range.
The costs associated to managing teams without an ambition for excellence are substantial. As far as scaling an org goes, building average teams scales better than having exceptional teams, because by definition, exceptional teams are the exception. But if you work on a project that has winner-takes-it-all dynamics, the costs of average teams are immense.
I really don't get why people argue so much against it. Nobody debates it in sports or music. Not every software project is like the world cup championship. But if you're in a VC market where the winner takes it all, yeah, then it's a lot like music or sports. You want your team to have the ambition to win.
the winner-takes-all dynamics also would be such a terrible place to work, “the winner” is seldom-to-never a person actually doing the work but VCs and owners and… what is my ambition here? maybe minority in USA but people do not define their lives by their job, it is means to an end. go to work, do your job and then head home for important parts of life. I have always looked for meaningful work that matters and have largely succeeded later in my career but none of that success had anything to do with ambition.
Am I working hard at Meta? You bet I am.
For median SWE salary and 0.001% in “options” that will likely never have a liquidity opportunity? I’m not so sure…
Again, depends on whether your product has that much upside. Many products don’t. But as an example: German car makers have long ignored that great software engineers have a vastly bigger impact in a team than great mechanical engineers. As a result, they for a long time failed to build great software engineering orgs.
Volkswagen gave in eventually and is now licensing from Rivian. Their failure was caused by a structural problem of not seeing how SW works at scale, and how that should influence your hiring.
Agree completely, and 10X engineers build such organizations.
They would read the play like Gretzky to know where they had to be ahead of time.
There are companies where 10x engineers make sense, and there are companies where normal engineers are better to have.
One good example is the Commandos, Infantry and Police article from 2004 Coding Horror. (you can look it up, not going to link) Typically the commandos are the 10x engineers. Having them on early in a startup is tremendously helpful. As a company grows to stages where you want infantry and police, having commandos / 10x engineers might hurt more than they help. Of course this isn't always true but this is more likely true than not, in most cases.
We as humans, and particularly in America, like to quantize people and use a single variable to rate how good people are. In reality different people are good at different situations. It's not always the best option to hire for the 10x engineers.
If that was the case then people wouldn’t need to engage in political games the way they do.
One of the traits of this work is that it is almost impossible to measure.
Most time is wasted when you throw away and rewrite what you did.
Very assertive, but almost always incorrect.
In fact, an arguably more important skill is know when not to do something and how to avoid tech debt. Building towards a north star sustainably and incrementally in such a way that pivots along the way don't require major bandaids or rewrites is how a good engineering org operates.
In the real world a lot of 10x engineers end up just launching a bunch of hacky garbage to frontload impact and leave the cleanup for everyone else. This can work for some time in organizations with phenomenal build and test infrastructure; however, it eventually becomes crippling and hinders everyone's velocity.
I like the saying that "engineering is a team sport" and agree that the multiplier should be on the productivity of the entire team as mentioned in the article. The concept of whole being greater than the sum of its parts applies to both engineering systems and technical teams (which we'd probably say is a type of system on its own).
Not meaning to downplay the role of great engineers... I suppose the best scenario would be 10x engineers who can also help the rest of the team perform better.
If you look at virtually all the games programmed from 1975 to around 1995, the programming "teams" were incredibly small. Until the Sony Playstation came out, virtually every videogame was written in assembly with no source control whatsoever. Even PC games like Starcraft (released in 1998) had code review done by printing out the physical code and going over it with a marker [this was about the last time Elon Musk had a programming job cough). There was no source control and graphics APIs (if they existed at all) came in thick manuals.
For context, the credits to the Sonic the Hedgehog, a multimillion (now billion) dollar franchise, had just one "Chief Programmer" Yuji Naka, and 2 "assistant" programmers. Most of the time the assembly code would be incomprehensible to anyone but the person who wrote it. I believe there was very little actual "collaborative" programming going on. The gulf between a programmer who could merely code (which meant moving sprites around in assembly), and someone who could ship an actual game, let alone a decent one, was quite immense. When it came time to develop the first 3d Sonic game for the Sega Saturn, Yuji Naka was busy, and an American team was set to the task. Working 14-20 hour days, and forced to write a 3d game engine on Saturn hardware in assembly (due to the crappy state of C compilers at the time), this team could not ship an acceptable game in the 1 year timespan needed by the company.
I think quiet advances in tooling have made both collaborative software engineering more feasible and more effective compared to the 80s and 90s, where entire multi-million dollar industries by necessity sat on the shoulders of a handful of high skilled software engineers.
> The best engineering organizations are the ones where normal engineers can do great work
But this is entirely compatible with the notion of superstars pulling the whole team forward
I'm not giving up on answering the question. It's an aid for you to answer this question by yourself now from where you are.
Argument in this article feels like advice that key to writing best programs lies in writing functions with average LoC.
If it is around 1 (which doesn’t seem too unreasonable given that multiple people might review a single commit), and a 10x engineer really is 10x as productive as a normal one, then I guess a team of less than 10 people will have trouble keeping up with these 10x engineers.
Unless the company only hires 10x engineers. But then we should at least consider the possibility that they are just hiring 1x engineers, and have a low opinion of engineers outside the company.
> Individual engineers don’t own software; engineering teams own software.
the portion "software; engineering" -- just because the words are adjacent here, even though they belong to separate phrases, are treated as one term and hyper-linked to articles tagged with "software engineering" :
https://spectrum.ieee.org/tag/software-engineering
In my mind, the important distinction isn’t so much about the developers themselves, but more the environment that they are developing in.
If your codebase is an inscrutable mess, you don’t have agency to make even minor decisions without slacking 6 people for an afternoon, and there is no documentation on a service you suddenly own, then guess what? You have no chance of being a 10x engineer. You probably can’t even be a 1x engineer!
Then there are also different individual skills (like magnus carlsen is more skilled in chess than me) that are influcened by practice and talent.
Also for a lot of problems experience might be more helpful than intelligence so you dont need to be einstein to engineer a dishwasher (probably).
Good leaders are the key to great teams. Good leaders know how to deal with excessively productive people, and underperforming people, and to harmonize them. A 10x engineer under good management will actually distribute their weight to others, and meet the definition. Without that they're just one highly skilled engineer, engineering.
And this is why some people fear AI
> Charity Majors is cofounder and CTO at Honeycomb.io, a platform that helps engineering teams debug and improve their software applications.
> https://charity.wtf/ Blog, latest article an apologia for DEI, "The diversity of your teams over the long run rests on your ability to build an inclusive culture and equitable policies."... "Don’t underestimate what a competitive advantage diversity can be"
Hmm. Why does no one argue for equitable balance of political views, or religions, or anything to do with ideas at all? Is anyone even measuring ideational diversity? Power-sharing in most countries is principally concerned with it, for example. How many 'inclusive' teams are extremely politically, and ideologically, homogenous?
Clearly there's a apologia for a certain worldview at work here: some sunk-cost investment in a certain notion of inclusion, which is entails (if not aims for) moral and ideological uniformity. Offensive to this notion of 'inclusion' is excellence, since excellence isn't uniform nor even normal -- it's pareto distributed. An excellent runner is exponentially better than a normal one, and sampling uniformly from all groups ("inclusively") produces bad runners.
According to experience, and all evidence, the best talent arises out of healthy competition and cooperation with the best talent -- it does not arise out of uniform, nor even, normal distributions.
If you sample uniformly, then race all against all eventually a powerlaw arises -- and almost everyone is excluded if you want the best. Discrimination based on talent is a ruthless process which cares little for what ought be.
Yes, systems produce excellence by exaggeration of abilities, but this process of exaggeration quickly leaves the normal behind, and is anyhting but inclusive.
Republicans will never be good at leading the EPA, basically.
Probably not, no.
About a decade ago, I worked with a woman who had a PhD in psychometric assessment / quantitative psych. She was crazy smart. She said there have been lots of studies of high performing teams, and of course one of the conclusions people have taken from these studies is that "more diversity is better".
But she said if you actually go and read the studies, its far more complex than that. She said the data actually shows:
- A diversity of backgrounds makes a team more effective.
- A diversity of values makes a team less effective.
It makes sense. Imagine your company sells breakfast cereal. You will be more effective if you have people from a lot of backgrounds because they will understand issues your customers will face. If everyone on your team is wealthy, you might price your product too high. If everyone on your team is poor, you might never consider having a premium version of your product for wealthy areas. If your team only speaks English, you might accidentally give your product a name that plays really badly for Spanish speakers or something. And so on. These mistakes can be avoided by having a team with diverse backgrounds.
But if your team members have different values, they won't get along and your team will become less effective. Say, some people on your team want to make a product thats good for the environment. And other people on the team just want to maximise profit. Then they'll spend their energy fighting about that, and the result is a low performing team, making a confused product thats probably expensive and bad for the environment at the same time. Or, one person on the team wants everyone to like each other and someone else on the team loves competition. They'll inevitably clash. The conflict might result in personal growth - but it'll probably be bad for the team's KPIs this quarter.
In essence, nobody talks about diversity of values because nobody wants it. Ironically, not even DEI proponents.
This is a problem when these values become extremised in a population such that to select for them is to quite significantly narrow the plurality of values which would otherwise well-coexit. Consider, eg., religious communities living together before and after liberalism -- before = civil war, after = human rights. Classical liberalism is an ideology of values pluralism which thereby permits great diversity of ideas.
We should expect high-performing teams to have a diversity of relevant ideas (, and perhaps, ) of irrelevant values.
The concern arises when the benefit to team cohesion arises from an echo-chambre of shared values, at a great expense, of disruptive innovation and ideational diversity. And also, on my part, just honesty about what this sort of moralist is really aiming for -- to be surrounded by people who wish for a very narrow sort of values-homogeneity.
If "diversity and inclusion" were part of the pluralist fabric of liberal tolerance shared by the vast majority of people this issue wouldn't arise -- since then there could be a great actual diversity of opinon whilst values were shared. The issue is how peripherial prioritising these values is, de facto -- and hence how self-regulatingly narrow the "team" has to be.
If the chief value being pushed were "tolerance", such that we had, "tolerance, respect, effort" (, say) as the new moralist fashion -- then almost none would be excluded.
Consider what the impact of making "racism" a team value would be in these terms: how narrowing, homogenising, and the like. And yet, I suspect the number of people keen to work with "people as racist as they are" is not so different than "people as obsessed by diversity as they are".
The first is the idealistic one that employers would like to be the default interpretation: A global hiring pool allows for the best possible experts, with the widest experience. And you need an inclusive culture to ensure that the talent is happy to stay.
The second is the more realistic: A global hiring pool allows for cheaper labour: And you need a culture where speaking out against "inclusivity" is dangerous to the individual, in order to prevent unionist sentiment or political barriers to cheap labour emerging.
The third is a bit more cynical, it's similar to the second but considering a wider scale: If an employer with an easy problem can't access a low cost low skill workforce, then they have to compete in hiring from the high skill one. This means that development is tied up with the financial impact of the work. (You only hire someone if there is expected return). Access to a cheaper labour market makes the price of the work more tied to the difficulty, removing the perception that development is a high value activity.
We also need to decide what we mean by a “10x engineer”. Many people here are describing engineers who “appear to be productive, spewing out shitty code that makes things worse”. The infamous industrious incompetent. This is not a useful definition of a 10x engineer. There is a reasonable definition of a 10x engineer: a 10x engineer creates 10x the value of a 1x engineer over the same period of time. This is the only meaningfully useful definition. Anyone who wants to understand 10x as “damaging spew” is choosing an unproductive definition. I assume such people are 1x engineers. To be a 10x engineer is to be the kind of person who believes that some engineers can be 10x, and then goes about find out how to be that themselves. 1x engineers get caught up misidentifying bad engineers as “10x engineers who are shit” so they can continue to be mediocre.
It's about creating leverage.
So, the great ones aren't lone mercurial artists.
They are the ones who are, in fact, very good at the craft. AND they also got good at writing things down for self/other, and teaching other people what they know, and creating a culture of enthusiastic open-minded curiosity, whether on an IRC channel or in a packed fancy conference auditorium.
Once-in-a-generation brilliance is optional. The rest is not.
e.g. Brian Kernighan will be the first one to tell you that Ken Thompson was in a league of his own compared to Brian. But Brian himself is a 10,000x programmer. How much leverage have his book(s) and software and generous public education created in the world?
Anyone can become a 10x version of themselves (next-year you is radically better than today-you) if they think about that and learn to be like Brian (think, do, self-teach, other-teach, spread infectious enthusiasm).
Edit: clarify prose, and fix embarassing name snafu
This is always going to have a critical subjective element to it.
The moment you start treating engineers like factory floor workers, that's what you get.
Time is quantifiable and comparable. Time spent on making things happen and then dealing with the consequences. The percentage of people leaving the organization in their first year is quantifiable.
Tech debt and tradeoffs from the previous feature will show up either as time spent on adding the next one or time spent on fixing bugs. Estimating is difficult, but measuring and figuring out post factum what amount of time was spent on yak shaving isn't exactly impossible. It maybe be uncomfortable and self incriminating, but that's a culture problem.
Listen, a 10x engineer is someone who does the work of 10 other engineers, not closes 10 times the tickets, not pretends to do 10x the work but really it's just making things more complicated.
Sometimes being 10x means you are extremely careful and you don't have to go back and rework stuff.
Sometimes it means your work unlocks 0.1 extra value out of 100 other engineers.
You can say that 10x engineers just flat out don't exist but it's a whole lot of cope to say that someone who actually gets 10 times as much work done is actually bad because you knew one special boy that was really a disaster.
Boring is the key, the commercial says.
We need exceptional people who can push boundaries and do exceptional work in order to progress.
They are only proud 10x because their narcissistic self looks proudly at 1x engineer in smudge fashion that they are better than someone else.
They are 10x because the system is stable enough and beautiful enough to allow for them to be 10x, and also allow for the 1x engineers to be good enough.
So lets champion the system and the normal engineers out there.
I find them very counterproductive, because instead of discussing actual issues and problems, people spend time justifying by all means that they’re in the “right camp”. Go outside, touch grass and actually talk to people you work in your org. Though I suspect most of those are written by ”influencers”(barf) that easier never worked with real people or don’t work anymore and want to sell their snake oil as ultimate truth.
If you think a great (10x) engineer has bad social skills, isn’t a good mentor, and isn’t a strong teammate… you’ve never actually worked with one. What truly makes someone a great engineer is being technically impeccable and having next-level soft skills.
> Most of us have encountered a few software engineers who seem practically magician-like, a class apart from the rest of us in their ability to reason about complex mental models, leap to nonobvious yet elegant solutions, or emit waves of high-quality code at unreal velocity.
> I have run into many of these incredible beings over the course of my career. I think their existence is what explains the curious durability of the notion of a “10x engineer,” someone who is 10 times as productive or skilled as their peers. The idea—which has become a meme—is based on flimsy, shoddy research, and the claims people have made to defend it have often been risible (for example, 10x engineers have dark backgrounds, are rarely seen doing user-interface work, and are poor mentors and interviewers) or blatantly double down on stereotypes (“we look for young dudes in hoodies who remind us of Mark Zuckerberg”). But damn if it doesn’t resonate with experience. It just feels true.
> I don’t have a problem with the idea that there are engineers who are 10 times as productive as other engineers. The problems I do have are twofold….
10x devs do not do mentoring and "social skills", because it does not scale. They write readme, maybe record a video, and move on to next task. If you have a question, send email and you get response latter! Sitting all day on meetings kills productivity very fast!
Buttering someone up, just because they are lazy to study documentation, and somehow they have power over you, is not a team work!!!
I think this is true, but in the metaphorical sense hah. Few with a happy childhood end up this way.
plus plus plus plus plus to this.
Software is much closer to a competitive race where small improvements in ability give completely outsized returns.
Because it is. Traits like intelligence or dedication really fluctuate during person's lifetime.
> If you have services or software components that are owned by a single engineer, that person is a single point of failure.
If you have a service owned by a person, you have a single entity responsible for this service. If you have a team of 10 people owning a service, each person gives only one tenth of a fuck, making any change take ten times as much time as it should, and there are ten different visions of the project playing out at once.
> The best engineering organizations are the ones where normal engineers can do great work
Strong agree. As an 10x engineer in an organization of 1x engineers, my life is perfect, because I get my shit done in one hour and go home and nobody gives a fuck. In an environment of 10x engineers I'd need to actually work 40h a week.
> Build sociotechnical systems with “normal people” in mind
Valid point. My manager asks me how do I do this that I deliver projects on time, they work correctly, and people are happy to work with me. The answer is simple: I treat everyone like an incompetent lazy fuck. This assumption allows me to create designs that are much less likely to fail.
You can see example of this by studying how big tech works. Usually they replace individual creativity with processes for people who can't think.
> A great engineering organization is one where you don’t have to be one of the best engineers in the world to have a lot of impact.
Not possible. Either you're a 10x engineer, or you're a cog in a big machine. Can't eat a cake and have a cake.
> Don’t hire the “best” people. Hire the right people
This paragraph is just ChatGPT slop.