17 ms·

“Normal” engineers are the key to great teams

• ultra-boss 2y ago
  "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." plus plus plus plus plus to this.
  • deleted 2y ago
    [deleted]
  • slindsey 2y ago
    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.
  • mytailorisrich 2y ago
    And to achieve this the organization only requires exceptional leaders...
  • Muromec 2y ago
    I want to believe, but has anymore ever worked at such great organization?
    • JTyQZSnP3cQGa8B 2y ago
      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.
  • rqmedes 2y ago
    And who leads and sets the vision. A committee of “average” engineers?
  • WgaqPdNr7PGLGVW 2y ago
    If this were true then software engineering jobs would have all already been offshored. Software is much closer to a competitive race where small improvements in ability give completely outsized returns.
    • N_Lens 2y ago
      You're both right, but in different contexts.
• nullpoint420 2y ago
  Most 10x engineers I've met are usually very creative and care deeply about the user experience and keeping code maintainable over time. Most 1x developers just care about getting the job done regardless of care or code quality, which in my experience has led to conflict.
  • iwontberude 2y ago
    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.
    • nullpoint420 2y ago
      Agreed. I prefer collaboration between engineers, regardless of Nx they are.
  • n_ary 2y ago
    I believe, you have got the multipliers switched. 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.
    • gmm1990 2y ago
      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.
• jaggederest 2y ago
  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.
  • ultra-boss 2y ago
    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!
    • aleph_minus_one 2y ago
      > 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.
• wiggidy 2y ago
  "Measuring productivity is fraught and imperfect" For the moment, but it's better than it's ever been, and it's getting better.
  • alfalfasprout 2y ago
    Not really. How do you quantify tech debt? How do you quantify the tradeoffs that someone made to add new functionality? 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.
    • Muromec 2y ago
      >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.
• bee_rider 2y ago
  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.
• hnthrow90348765 2y ago
  >"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?
  • fatbird 2y ago
    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.
  • ip26 2y ago
    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?
• beastman82 2y ago
  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.
  • deleted 2y ago
    [deleted]
  • bloomingkales 2y ago
    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.
    • nomel 2y ago
      > 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. How can you meaningfully separate these?
  • cmdli 2y ago
    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.
  • dilyevsky 2y ago
    Oh they are super productive alright when you measure by story points just not in any revenue/profit impacting sense
• jasonthorsness 2y ago
  "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!
• somekyle2 2y ago
  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.
• superconduct123 2y ago
  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?
  • MyOutfitIsVague 2y ago
    Some people just really like the work they do. There's nothing more to it than that.
    • Muromec 2y ago
      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.
  • behrlich 2y ago
    > completely obsessed with the project, like it’s their main hobby/purpose I think you figured it out.
    • booleandilemma 2y ago
      If your main hobby or purpose is to make someone else rich you're a slave.
      • hakaneskici 2y ago
        I worked like this. You could have phrased it better.
• irishloop 2y ago
  Join my startup, where we harness the power of HackerNews arguing about 10x engineers into a new form of renewable energy
• mkl95 2y ago
  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.
  • threatofrain 2y ago
    When people say "average" they're trying to reach for a concept of 1x engineer, not 3x engineer.
    • mkl95 2y ago
      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.
• alfalfasprout 2y ago
  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.
• vrnvu 2y ago
  > 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.
  • romanhn 2y ago
    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.
    • matwood 2y ago
      Exactly. The way a 10x engineer really 10x’s is by leveling up the entire team.
  • jt2190 2y ago
    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….
• TriangleEdge 2y ago
  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.
  • valiant55 2y ago
    > 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.
• bilaldnaya 2y ago
  [flagged]
• shadowgovt 2y ago
  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.
• ein0p 2y ago
  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.
• renewiltord 2y ago
  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.
  • tonyedgecombe 2y ago
    > The long and short of it is that the people who are buying your work are adequate determiners of how key you are. 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.
• bjornsing 2y ago
  There are 10x engineers, and 100x, and 1000x. The only thing required to separate the wheat from the chaff is a hard enough problem. Now deal with it.
• 0xbadcafebee 2y ago
  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.
  • mpalmer 2y ago
    Republished from a Substack...
  • rqmedes 2y ago
    Best take so far
  • mook 2y ago
    It's IEEE Spectrum; it's certainly been subpar for a few years. 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…
  • llmthrow103 2y ago
    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.
    • 0xbadcafebee 2y ago
      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.
• didgetmaster 2y ago
  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.
• einpoklum 2y ago
  > "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".
  • grensley 2y ago
    I agree with you, but in a different directions. Often the software is owned by the company, who are just renting the engineer's labor.
• d--b 2y ago
  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.
• mlhpdx 2y ago
  > 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 Wise words for hiring managers.
• t43562 2y 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.
  • tmountain 2y ago
    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.
  • throw4847285 2y ago
    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.
    • t43562 2y ago
      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.
• smm11 2y ago
  The thread on plain HTML pages comes to mind. Boring is the key, the commercial says.
• Amorymeltzer 2y ago
  Surprised no one here has posted <https://1x.engineer https://1x.engineer> yet
• 0xB31B1B 2y ago
  I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B players hire C players etc. Building a team from the ground up is very much an iterative process of fighting complacency and mediocrity all day every day, and this guys pitch is just "give in, its not so bad".
  • deleted 2y ago
    [deleted]
  • aisisbdidns 2y ago
    You’re over optimizing for engineering skill. The majority of projects don’t need a team full of A players, and trying to get that is going to limit you. Get rid of team members that make your life harder. Keep the ones that make it easier. > Individuals ship software not teams I can’t see how this is remotely true outside of contorting some definitions of “ship”.
    • grandempire 2y ago
      In every project I have worked in big and small - a key person took charge. Others contributed, but that individual made it happen.
      • aisisbdidns 2y ago
        [dead]
      • NalNezumi 2y ago
        so in every key project you've worked on, a one single person took care of the coding from DevOps to frontend/backend, deployment, testing, and all other coding required beyond "key functionality"? I think it says more about the size of the project and the complexity of the task that you've worked on, rather than "10x engineer vs normal engineer". Not even at a 10 person startup have I seen "one" person done everything. Unless you're talking about someone just forking OSS and gluing it together, to make a carbon-copy application of something that already exist(for free) then sure. Edit: >key person took charge and made it happen person - singular. made it happen - it's hard to call an engine a car. to make something happen, you need all the component (contributions).
• grensley 2y ago
  > Individual engineers don’t own software; engineering teams own software. Very assertive, but almost always incorrect.
• michaelhoney 2y ago
  > 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. And this is why some people fear AI
• skybrian 2y ago
  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.
• anon-3988 2y ago
  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.
  • ip26 2y ago
    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.
  • strken 2y ago
    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.
  • TrackerFF 2y ago
    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.
• mjburgess 2y ago
  The author: > Charity Majors is cofounder and CTO at Honeycomb.io, a platform that helps engineering teams debug and improve their software applications. > https://charity.wtf/ 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.
  • viscountchocula 2y ago
    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.
  • josephg 2y ago
    > 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.
• anal_reactor 2y ago
  > “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 This paragraph is just ChatGPT slop.
• from-nibly 2y ago
  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.
• freetime2 2y ago
  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.
• a_square_peg 2y ago
  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.
• m3kw9 2y ago
  Won’t be getting imposter syndrome for sure for this role
• TZubiri 2y ago
  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)
  • mbernstein 2y ago
    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.
    • TZubiri 2y ago
      [flagged]
      • soulofmischief 2y ago
        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.
• thom 2y ago
  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.
• deedubaya 2y ago
  This is my favorite take on 10x engineers https://testdouble.com/insights/the-looming-demise-of-the-10x-developer https://testdouble.com/insights/the-looming-demise-of-the-10...
  • js2 2y ago
    I'm not sure I've ever read a piece while nodding along so violently in agreement. Thank you for sharing.
• notepad0x90 2y ago
  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.
• cyprx 2y ago
  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
• jjk166 2y ago
  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.
  • deleted 2y ago
    [deleted]
  • earthnail 2y ago
    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.
• ljm 2y ago
  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?
  • deleted 2y ago
    [deleted]
  • interludead 2y ago
    Yep, you're absolutely right that leadership is often the real bottleneck in building great teams
  • gtsop 2y ago
    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
    • ljm 2y ago
      Yes, I do, I expect leadership and management to be better. It doesn't happen very often, but when it does... It's never an execution problem, it's a management.
• roncesvalles 2y ago
  >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.
  • nextts 2y ago
    10x managers
• paradite 2y ago
  Normalizing mediocrity is not something I want in STEM fields. We need exceptional people who can push boundaries and do exceptional work in order to progress.
• chamomeal 2y ago
  I’ve never liked the idea of a 10x engineer. 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!
• temptemptemp111 2y ago
  [dead]
• foweltschmerz 2y ago
  yes, because of nothing else we need more in this day and age than the praising of mediocrity
• nodoll 2y ago
  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.
• sibeliuss 2y ago
  This is such a terribly dumb and worn out trope. 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.
• mirekrusin 2y ago
  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.
• kookamamie 2y ago
  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.
• matthewsinclair 2y ago
  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. [0]: “The Myth of the Hero Programmer” https://matthewsinclair.medium.com/0061-the-myth-of-the-hero-programmer-5489c629fec2 https://matthewsinclair.medium.com/0061-the-myth-of-the-hero...
  • sam_lowry_ 2y ago
    See also The Worst Kind of Programmer [1] which talks about how detrimental the work of high performers often is. [1] http://mikhailian.mova.org/node/284 http://mikhailian.mova.org/node/284
    • fmbb 2y ago
      The real 10x devs are the ones that just do ten times less work than the rest but you cannot tell from their output.
      • matthewsinclair 2y ago
        Haha. That made me laugh. I will now go looking for “The Mythical 1/10th Programmer”.
• LarsDu88 2y ago
  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.
• albert_e 2y ago
  OT: funny quirk in the article mark up ... > 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 https://spectrum.ieee.org/tag/software-engineering
• gatinsama 2y ago
  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?
  • alecco 2y ago
    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.
    • alecco 2y ago
      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.
    • datadrivenangel 2y ago
      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.
  • atoav 2y ago
    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.
• lowbloodsugar 2y ago
  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.
• whiplash451 2y ago
  The main premise of the post is this: > 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
• randomNumber7 2y ago
  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).
• interludead 2y ago
  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
• wiseowise 2y ago
  One more empty reaction epiphany rambling of another random-god-knows-who.
  • remoquete 2y ago
    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.
    • wiseowise 2y ago
      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.
• TrackerFF 2y ago
  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.
• fjfaase 2y ago
  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.
  • athanagor2 2y ago
    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.
• Karolis_K 2y ago
  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.
• winternewt 2y ago
  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.
• 2OEH8eoCRo0 2y ago
  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.
• earthnail 2y ago
  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.
  • dinobones 2y ago
    Yeah maybe if my employer has the ambition to pay. 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…
    • earthnail 2y ago
      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.
  • dilyevsky 2y ago
    A small team of skilled engs hurts managers’ careers - they want large teams
• magicmicah85 2y ago
  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. Hat tip to these articles on 10x engineer studies: https://jasoncrawford.org/10x-engineers https://jasoncrawford.org/10x-engineers https://www.construx.com/blog/productivity-variations-among-software-developers-and-teams-the-origin-of-10x/ https://www.construx.com/blog/productivity-variations-among-...
  • mmcromp 2y ago
    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".
    • magicmicah85 2y ago
      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.
• breadwinner 2y ago
  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.
  • ausbah 2y ago
    i think your flaw is conflating scientific research with software engineering
    • breadwinner 2y ago
      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.
      • x86x87 2y ago
        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.
        • breadwinner 2y ago
          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!
  • paxys 2y ago
• nashashmi 2y ago
  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.
• godot 2y ago
  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.
• magwa101 2y ago
  [dead]
• adityaathalye 2y ago
  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
• curtisszmania 2y ago
  [dead]
• paulddraper 2y ago
  Hard disagree
• ike2792 2y ago
  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.
• npodbielski 2y ago
  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.
• jjvlima 2y ago
  Great article!