[HN Gopher] "Normal" engineers are the key to great teams
___________________________________________________________________
"Normal" engineers are the key to great teams
Author : jnord
Score : 556 points
Date : 2025-03-13 20:35 UTC (1 days ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| ultra-boss wrote:
| "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.
| slindsey wrote:
| 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 wrote:
| And to achieve this the organization only requires exceptional
| leaders...
| Muromec wrote:
| I want to believe, but has anymore ever worked at such great
| organization?
| JTyQZSnP3cQGa8B wrote:
| 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 wrote:
| And who leads and sets the vision. A committee of "average"
| engineers?
| WgaqPdNr7PGLGVW wrote:
| 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 wrote:
| You're both right, but in different contexts.
| nullpoint420 wrote:
| 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 wrote:
| 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 wrote:
| Agreed. I prefer collaboration between engineers, regardless
| of Nx they are.
| n_ary wrote:
| 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 wrote:
| 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.
| alfalfasprout wrote:
| 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.
| whstl wrote:
| 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.
| alfalfasprout wrote:
| Except it's not a myth. Many of us have encountered the
| _perceived_ more productive developers that ship barely
| passable garbage.
| whstl wrote:
| The myth I'm criticizing is that sloppiness has a
| stronger correlation with being productive. It doesn't.
| Plenty of slow developers who suck.
|
| This is just rationalization.
| pests wrote:
| 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.
| from-nibly wrote:
| That's someone who thinks they are 10x not someone who
| is.
| pests wrote:
| I think that would apply to many of those 10x'ers were
| talking about here tho.
| Chyzwar wrote:
| 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
| YetAnotherNick wrote:
| Hard disagree. If they don't consistently write maintainable
| and reliable code, they are not 10x engineer no matter how
| smart they are.
|
| 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.
| whstl wrote:
| 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...
| Izkata wrote:
| 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.
| whstl wrote:
| Are you really sure?
|
| 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.
| Izkata wrote:
| > If 1x is the absolute rock-bottom lowest possible
| productivity
|
| You understand the original meaning of the term. This is
| not how most people use it nowadays.
| whstl wrote:
| No, I don't. You're reading too much into my post. I
| haven't made any judgement of whether 1x means average or
| rock bottom, because it doesn't matter.
|
| The assertion made by GP is absurd regardless of the
| definition, period.
| CrimsonRain wrote:
| Most "1x" engineers are a drag on the business. Complacent.
| Don't care about business goals.
|
| 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)
| Nevermark wrote:
| 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.
| steveBK123 wrote:
| You really can over-hire and I've seen it happen in many
| shops
|
| If a "10x engineer" is not given 10x problems, they will..
| create some.
| rockemsockem wrote:
| No, they'll leave. You're talking about the wannabes.
| steveBK123 wrote:
| There's easily 10x as many 10x wannabes though
| TZubiri wrote:
| Yes but it will never reach production.
|
| 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.
| lowbloodsugar wrote:
| 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.
| steveBK123 wrote:
| 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.
| jajko wrote:
| 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.
| lysace wrote:
| > 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.
| imetatroll wrote:
| 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.
| Muromec wrote:
| >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.
| whstl wrote:
| Yeah, after joining management I'm 100% behind this
| thinking.
|
| 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.
| TZubiri wrote:
| I think multiple 10x engineers will fight amongst themselves,
| and that is good.
|
| You don't have a 10x without there being a 0.1x engineer. And
| we can't all be right.
| jillesvangurp wrote:
| 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.
| Izkata wrote:
| > 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.
| jaggederest wrote:
| 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 wrote:
| 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!
| lovich wrote:
| >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
| ambicapter wrote:
| 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).
| grandempire wrote:
| It absolutely attracted different people. The inflows are
| much larger and not the same.
|
| For example EE used to be prestige and CS was the backup.
| And that would never compare to finance or law.
| yubblegum wrote:
| 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.
| chasd00 wrote:
| "Call 1-800 beageek". Remember that commercial? That was
| around the time software dev went mainstream, late 90s
| iirc.
| grandempire wrote:
| Mainstream is different than upper middle class and
| ambitious.
| blendo wrote:
| Back in the 90s, they were the "suits".
|
| Andreessen, Scott McNealy, & Ellison were, to me, the
| ones that left a particularly bad taste.
| only-one1701 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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.
| lovich wrote:
| 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
| awesome_dude wrote:
| Yeah - this is a bit like "competition brings out the best
| in people" when the reality is that it also brings out the
| worst in people
| swatcoder wrote:
| 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.
| Swizec wrote:
| 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.
|
| Also money is nice.
| Aeolun wrote:
| > Business constraints make it feel much more interesting
| than writing code in a vacuum.
|
| You never write code in a vacuum do you? You always have
| some kind of goal.
| nicoburns wrote:
| I should hope not. Even if your body could withstand the
| low pressure, you'd suffocate very quickly.
| Swizec wrote:
| I don't know dude, this one time I wrote a LOLCODE
| compiler into a Babel macro.
|
| 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...
| godelski wrote:
| > because our office fridge kept freezing my carrots.
|
| That sounds like a goal to me
| ngneer wrote:
| 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.
| throwaway2037 wrote:
| 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.
| error_logic wrote:
| 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.
| swatcoder wrote:
| 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.
| golergka wrote:
| > 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.
|
| There's nothing good or bad about it.
| grandempire wrote:
| That's why the bill gates story got so much public
| attention. It's surprising. Their Harvard kid is doing
| what?
| antonvs wrote:
| I suppose it may have been surprising to anyone
| completely out of touch with what was happening at the
| time.
|
| I'm only a little younger than Gates, and it seemed like,
| what _else_ would you do? PCs were revolutionizing the
| world.
| araes wrote:
| 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?
| Aurornis wrote:
| > 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.
| lovich wrote:
| > 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
| fsloth wrote:
| 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.
| Dracophoenix wrote:
| https://en.wikipedia.org/wiki/Andy_and_Bill's_law
|
| https://en.wikipedia.org/wiki/Wirth%27s_law
|
| And more generally,
|
| https://en.m.wikipedia.org/wiki/Jevons_paradox
| lovich wrote:
| Seeing this multiple times in a day for multiple,
| articulable reasons in the mid 2010s if my memory doesnt
| fail me
|
| >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
| ginko wrote:
| >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.
| sumtechguy wrote:
| You both are right.
|
| 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.
| bluedino wrote:
| 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"
| godelski wrote:
| 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
| asdff wrote:
| 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.
| lovich wrote:
| 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.
| TeMPOraL wrote:
| 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.
| aleph_minus_one wrote:
| > 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. :-)
| jghn wrote:
| 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.
| asdff wrote:
| 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.
| vineyardmike wrote:
| 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.
| rsanek wrote:
| >Once tech [...] started being a source of wealth and power
|
| this happened "in the early 2010s"? I don't think so.
| Software engineers have no power, and in comparison to
| finance, quite limited wealth.
| golergka wrote:
| 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.
| sesm wrote:
| They are not richest people though, they are biggest
| public shareholders. Real wealth is always well-hidden.
| RUnconcerned wrote:
| The idea that these centibillionaires do not have "real
| wealth" is beyond absurd
| cafard wrote:
| Ballmer has a background in working for a software
| company. Did he ever actually work in software as such?
| psunavy03 wrote:
| 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.
| lovich wrote:
| 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
| antonvs wrote:
| > software engineers have no power
|
| Like that fellow who runs a car company now
| 01HNNWZ0MV43FF wrote:
| I don't think he's any good at programming
| ozim wrote:
| Oh stop narrating like nerds in a basement are cuddly lovable
| bunch.
|
| 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.
| djfivyvusn wrote:
| Yup, this idea that we're in a unique industry or that our
| industry is any different to any other career path is very
| toxic.
|
| Accountants have the same bullshit memes we do.
| DanielHB wrote:
| Remember programming language quizzes? I kinda miss those,
| if you are testing for knowledge they have more value than
| leetcode
| hinkley wrote:
| 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.
| strangattractor wrote:
| 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.
| nntwozz wrote:
| "Focusing is about saying no." -- Steve Jobs
|
| https://www.youtube.com/watch?v=YgL8fpya8BA
| hinkley wrote:
| There was a great article a little while back about how
| "yes, but" is powerful but "no, but" is almost as powerful.
|
| 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.
| awesome_dude wrote:
| > Never once did it even matter - there was no material
| benefit to the company.
|
| 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
| strangattractor wrote:
| 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.
| unconed wrote:
| 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.
| CrimsonRain wrote:
| So you 10x'd in wrong direction. Doesn't mean something else
| can't 10x in the right direction.
| TZubiri wrote:
| If they 10x in the wrong direction and I 1x in the wrong
| direction, I am a 10x engineer.
|
| A null engineer is an inf engineer.
| blitzar wrote:
| 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.
| logsr wrote:
| > Focus is a super power
|
| 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.
| hinkley wrote:
| > engineering is all about efficiency
|
| 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.
| logsr wrote:
| 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.
| grandempire wrote:
| Wasting your enthusiasm was your managements fault. It's
| their job to set up the tasks that will have impact.
| not2b wrote:
| 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.
| TZubiri wrote:
| 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.
| jimbokun wrote:
| > I would work all night.
|
| 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.
| timknauf wrote:
| Egads, that spell checker is absolutely beautiful.
|
| 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.
| Lanolderen wrote:
| 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.
| strangattractor wrote:
| 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.
| jimbokun wrote:
| 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.
| hinkley wrote:
| 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.
| dennis_jeeves2 wrote:
| >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.
| buzzardbait wrote:
| Not just toxic, he's simply wrong. A 10X is someone who
| supposedly completes 10 hours' worth of work in one hour.
| If anything he was a -10X lol...
| hinkley wrote:
| The thing about codependent relationships is that both
| parties are guilty. And this has definitely been a banger
| of a codependent relationship.
| xandrius wrote:
| 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.
| hinkley wrote:
| 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.
| hinkley wrote:
| 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.
| noosphr wrote:
| Software is different.
|
| 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.
| tkahnoski wrote:
| 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.
| noosphr wrote:
| >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.
| magicalist wrote:
| 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.
| shafyy wrote:
| I don't know, man. Your comment is neither here nor there.
| knowsuchagency wrote:
| Disagree.
|
| 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.
| threatofrain wrote:
| 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.
| sunrunner wrote:
| Can you give some examples of things you'd consider fads
| versus classical in software?
| TylerE wrote:
| TDD. Agile.
| throwaway2037 wrote:
| 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).
| TylerE wrote:
| Just to be clear, do you mean full-dogma Rails tutorial
| write a bunch of trivial tests before writing code TDD?
| throwaway2037 wrote:
| 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!
| TylerE wrote:
| 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.
| cylemons wrote:
| > excessively separate concerns (that are actually linked
| and shouldn't be)
|
| you mean concerns that should be seperated but they did
| it in a wrong way?
| lovich wrote:
| When you say TDD do you meant test driven design or the
| test first design actually practice when "doing TDD"
| djtango wrote:
| Not very long at all ago, people waged war over dynamic
| vs lexical function scoping.
|
| 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
| Exoristos wrote:
| The answers so far are pretty damn telling.
| tdeck wrote:
| 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.
| TylerE wrote:
| 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.
| lovich wrote:
| Is there a difference between doing something and
| supporting something?
|
| This joke is like a decade old at this point
| https://xkcd.com/1172/
| TylerE wrote:
| Well, yes.
|
| Namely, what does the following code do?
| patients = 400 patents = 20 x = patients
| / 10
|
| 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.
| lovich wrote:
| You have ignored my question
|
| "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.
| WalterBright wrote:
| 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.
| hakaneskici wrote:
| RE: Quick iteration cycles - definitely agreed.
|
| 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 :)
| sroussey wrote:
| The methodology is unconstrained as another way to put it.
|
| 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.
| sunrunner wrote:
| 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).
| PaulDavisThe1st wrote:
| > 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).
| foota wrote:
| Maybe the real difference is that costs are hidden in
| software engineering, but more obvious in other
| disciplines?
| datadrivenangel wrote:
| 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.
| djtango wrote:
| 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.
| jonfromsf wrote:
| You can hide ANYTHING with financial engineering. Like off-
| books liabilities, systemic risk ... anything.
| throwaway2037 wrote:
| 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.
| asdff wrote:
| Must be why every company pays its fair share of taxes
| right?
| eru wrote:
| What do you mean by 'fair'?
|
| Different jurisdictions have different tax rates.
| magicalist wrote:
| > _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.
| throw1111221 wrote:
| 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.
| magicalist wrote:
| > _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.
| gerdesj wrote:
| "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.
| noosphr wrote:
| Not sure where you're getting that from my post.
|
| 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
| callc wrote:
| 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.
|
| Edit: reduced emotions
| antoniojtorres wrote:
| I don't think the comment was meant derisive like you and
| the other commenter are interpreting... relax?
| callc wrote:
| 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
| noosphr wrote:
| >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.
| lovich wrote:
| 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 think you two are talking past each other
| buzzardbait wrote:
| > I think you two are talking past each other
|
| This is why steelmanning a comment before arguing against
| it should be a rule.
| lovich wrote:
| > 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
| bigtunacan wrote:
| 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.
| callc wrote:
| How are you reading noosphr's comments?
|
| 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).
| bigtunacan wrote:
| 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.
| vacuity wrote:
| 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.
| whstl wrote:
| 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.
| datadrivenangel wrote:
| 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.
| asdff wrote:
| 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.
| AxEy wrote:
| >There's the folklore about half of all math papers giving
| the wrong proof for the right conclusion.
|
| Sorry, what? This is an extraordinary claim.
| p_v_doom wrote:
| 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.
| deadfoxygrandpa wrote:
| actually, if you really think about it, my source code is
| only laid out in 2 dimensions. thats even fewer than
| mechanical engineers have to work with!
| beryilma wrote:
| One might even argue that a Turing Machine (computers) is
| really one dimensional.
| vonneumannstan wrote:
| You'd probably be shocked by the amount of junk hiding in the
| design of the F-35 for example. Complex Systems in 3-d are
| still complex.
| DrScientist wrote:
| 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.
| jhanschoo wrote:
| Software is different.
|
| 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.
| never_inline wrote:
| Hyperbolic space indeed.
| CrimsonRain wrote:
| 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.
| WgaqPdNr7PGLGVW wrote:
| > I like this article particularly because I think the trope
| that there's something unique and different about software
| engineering is pretty toxic
|
| 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.
| freddie_mercury wrote:
| > 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.
| WgaqPdNr7PGLGVW wrote:
| > 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.
| freddie_mercury wrote:
| IBM's S/360 was millions of lines of code in the 1970s.
| Managing millions of lines of tangled code is not novel.
| It is older than most HN readers.
| jackcosgrove wrote:
| 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.
| jonas21 wrote:
| You're mistaking complacency and lack of innovation for
| maturity.
| jandrewrogers wrote:
| 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.
| logsr wrote:
| > 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.
| avs733 wrote:
| > 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.
| throwaway2037 wrote:
| > well known toxic field, finance
|
| 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?
| ltbarcly3 wrote:
| 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.
| jpeloquin wrote:
| I can confirm that some (30%?) mechanical and biomedical
| engineers follow the described problem "solving" strategy
| exactly. It's not just software engineers.
| nyarlathotep_ wrote:
| 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'm totally serious with that question.
| ltbarcly3 wrote:
| 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.
| nyarlathotep_ wrote:
| Genuinely appreciate this response.
|
| 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.
| dennis_jeeves2 wrote:
| >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.
| nodoll wrote:
| 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.
| majkinetor wrote:
| You are so wrong.
|
| 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.
| wiseowise wrote:
| 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?
| eru wrote:
| > These days it feels a bit like another well known toxic
| field, finance, in that people conflate an outsized leverage
| for personal valor.
|
| I'm not sure what you are talking about. Finance people
| regularly talk about risk adjusted returns, not raw returns.
| unconed wrote:
| >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.
| keepamovin wrote:
| 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 ;)
|
| Perhaps i should read the article!
| Xmd5a wrote:
| 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.
| hinkley wrote:
| 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.
| wiggidy wrote:
| "Measuring productivity is fraught and imperfect" For the moment,
| but it's better than it's ever been, and it's getting better.
| alfalfasprout wrote:
| 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 wrote:
| >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 wrote:
| 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 wrote:
| >"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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bloomingkales wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Oh they are super productive alright when you measure by story
| points just not in any revenue/profit impacting sense
| jasonthorsness wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| Some people just really like the work they do. There's nothing
| more to it than that.
| Muromec wrote:
| 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 wrote:
| > completely obsessed with the project, like it's their main
| hobby/purpose
|
| I think you figured it out.
| booleandilemma wrote:
| If your main hobby or purpose is to make someone else rich
| you're a slave.
| hakaneskici wrote:
| I worked like this. You could have phrased it better.
| Muromec wrote:
| 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.
| dnissley wrote:
| if you also make yourself rich in the process, are you
| still a slave?
| incrudible wrote:
| Imagine taking pride in your craft rather than doing only
| the bare minimum to pad your ego, what a crazy approach!
| fzeroracer wrote:
| 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.
| superconduct123 wrote:
| Exactly, I'm not saying do the bare minimum
|
| I mean more that the optimal amount of work to put in is
| still above average but way below 10x
| fn-mote wrote:
| 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.
| hot_gril wrote:
| Save it for myself how, ditch half the work day to go to
| the gym? I'm going to work 9-5 either way.
| whstl wrote:
| Why, though?
|
| 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?
| pydry wrote:
| If you're not making someone with a lot more money than you
| even richer you're probably not earning much yourself.
|
| This is about how capitalism is structured it's not at all
| a matter of personal choice.
| not_a_bot_4sho wrote:
| 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.
| xandrius wrote:
| 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.
| aabdi wrote:
| 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.
|
| but really it's all preference.
| Muromec wrote:
| >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.
| jimmaswell wrote:
| There are big rewards in future pay, referrals, etc. for
| establishing a reputation as a great engineer. If you find
| there aren't then jump jobs.
| hakaneskici wrote:
| You're right. Coming from my own startup to Microsoft, I worked
| the same way for quite a long time. Huge regret.
| parliament32 wrote:
| 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.
| namuol wrote:
| Once you're paid some minimum threshold you stop caring about
| money and start caring about your legacy.
| alexathrowawa9 wrote:
| Ah yes, my legacy: UserOAuthLoginProfileAPIService
| hot_gril wrote:
| // TODO: migrate to UserOAuthLoginProfileAPIService2 by
| Wednesday
| disambiguation wrote:
| Everyday I grapple with the legacy my coworkers left behind..
| disambiguation wrote:
| > 1-2 people who do a big bulk of the work
|
| 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.
| mhitza wrote:
| 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.
| ip26 wrote:
| 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.
| hot_gril wrote:
| 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.
| throwaway2037 wrote:
| > 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.
| noisy_boy wrote:
| 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.
| throwaway2037 wrote:
| > Maybe because they enjoy the work they do
|
| 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.
| weitendorf wrote:
| > 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.
| rosstex wrote:
| Autism? Does it really matter? People have different priorities
| in life. Some people stay in academia because they're afraid of
| the real world.
| chamomeal wrote:
| 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
| xkq8zmqe9-0x wrote:
| > why they care so much about work when the rewards are not
| proportionate to doing so much extra work.
|
| Most of the >1x engineers I met can't help themselves and be
| their best version.
| mkl95 wrote:
| 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 wrote:
| When people say "average" they're trying to reach for a concept
| of 1x engineer, not 3x engineer.
| mkl95 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| Exactly. The way a 10x engineer really 10x's is by leveling
| up the entire team.
| jt2190 wrote:
| 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....
| moffkalast wrote:
| > 10x engineers have dark backgrounds
|
| I think this is true, but in the metaphorical sense hah. Few
| with a happy childhood end up this way.
| lalaithion wrote:
| 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.
| throw833999 wrote:
| 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!!!
| TriangleEdge wrote:
| 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 wrote:
| > 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.
| shadowgovt wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| rqmedes wrote:
| Best take so far
| mook wrote:
| 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...
| mpalmer wrote:
| Republished from a Substack...
| llmthrow103 wrote:
| 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.
| flavio81 wrote:
| >When did IEEE become host to clickbait nonsense? This whole
| take feels like an editorial by a junior engineer going off
| vibes.
|
| Exactly.
|
| I think i'll never click on an IEEE Spectrum article again.
|
| IEEE has jumped the shark.
| didgetmaster wrote:
| 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 wrote:
| > "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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The thread on plain HTML pages comes to mind.
|
| Boring is the key, the commercial says.
| Amorymeltzer wrote:
| Surprised no one here has posted <https://1x.engineer> yet
| 0xB31B1B wrote:
| 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".
| aisisbdidns wrote:
| 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 wrote:
| In every project I have worked in big and small - a key
| person took charge. Others contributed, but that individual
| made it happen.
| NalNezumi wrote:
| 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 (contribution
| _s_ ).
| grandempire wrote:
| > 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.
| whatnow37373 wrote:
| Humans tend to have pyramidal power structures, because
| of [reasons]. I don't see how this relates to the topic?
|
| > 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).
| andoando wrote:
| It really depends on the project no.
|
| 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
| 0xB31B1B wrote:
| 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.
| therealdrag0 wrote:
| Not needing something is different than not benefiting from
| something.
| mdgrech23 wrote:
| 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.
| 0xB31B1B wrote:
| Yes, exactly! And that is good!
| therealdrag0 wrote:
| 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.
| swatcoder wrote:
| 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.
| 0xB31B1B wrote:
| 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.
| thi2 wrote:
| > Comforting yet false assertions. Great engineers tire of
| working with "normal" engineers, they want to work with
| others who they respect
|
| What a great environment to train juniors. Does not sound
| toxic at all.
| BigJono wrote:
| 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.
| systemf_omega wrote:
| Wanting to work with ambitious people that match your
| level is not toxic.
| Seb-C wrote:
| There are great and normal juniors as well.
|
| Junior does not mean incompetent, it means unexperienced.
| hot_gril wrote:
| 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.
| 0xB31B1B wrote:
| 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.
| noisy_boy wrote:
| 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.
| jjk166 wrote:
| You don't need a former fighter jet pilot to fly an
| airliner, but a former fighter jet pilot would probably
| do a very good job flying an airliner.
|
| The guy who can roll his own probably also has a better
| idea than most what easy off the shelf solutions are out
| there.
| 0xB31B1B wrote:
| 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.
| alienthrowaway wrote:
| 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.
| interludead wrote:
| 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.
| tremon wrote:
| 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.
| c_e wrote:
| > Nearly all complex technical projects are owned by one super
| smart person (Ex: linux).
|
| strange example, considering that the super-smart owner is
| purely a delegator at this point, and there are thousands of
| contributors.
| throwaway2037 wrote:
| 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.
| klysm wrote:
| Look at it from the perspective of a scared business owner who
| wants replaceable cogs
| gilbetron wrote:
| 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.
| Nathanba wrote:
| 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.
| swatcoder wrote:
| 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.)
| Nathanba wrote:
| 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.
| antupis wrote:
| 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.
| jjk166 wrote:
| 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.
| 0xB31B1B wrote:
| 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".
| Dracophoenix wrote:
| > 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.
| matthewmacleod wrote:
| This example proves the exact opposite of the point you
| intended to make.
| Dracophoenix wrote:
| In what way?
| gilbetron wrote:
| https://openssl-library.org/post/2018-12-20-20years/
|
| OpenSSL was made by a team, just read the history.
| Dracophoenix wrote:
| As per your own source:
|
| > 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.
| handwarmers wrote:
| 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?
|
| 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.
| alienthrowaway wrote:
| 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
| handwarmers wrote:
| 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.
| __loam wrote:
| 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.
| weitendorf wrote:
| 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.
| chamomeal wrote:
| 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
| gorgoiler wrote:
| 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.
| mvdtnz wrote:
| This is bullshit. I'm sorry you've never had the pleasure of
| working in a high performing team.
| on_the_train wrote:
| 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.
| 0xB31B1B wrote:
| 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.
| al_borland wrote:
| 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.
| 0xB31B1B wrote:
| 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.
| nextts wrote:
| 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".
| Juliate wrote:
| > Individuals ship software not teams
|
| 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_.
| interludead wrote:
| The "two people carrying the team" dynamic does happen, but
| that's often a sign of bad management, not some immutable law
| of engineering
| khazhoux wrote:
| Your post is super offsensive. And true.
|
| 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
| nextts wrote:
| 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.
| khazhoux wrote:
| 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.
| flavio81 wrote:
| So, you think productivity or even quality can be measured in
| "amount of lines of code produced".
|
| Which is completely wrong.
| khazhoux wrote:
| 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.
| TrackerFF wrote:
| 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.
| silvestrov wrote:
| 10x is not about the number of lines produced.
|
| 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.
| TrackerFF wrote:
| 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.
| whatnow37373 wrote:
| 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.
| solatic wrote:
| 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.
| wesselbindt wrote:
| About 15000 engineers have contributed to the Linux kernel. You
| should be more mindful of how facts line up with your feelings.
| alphazard wrote:
| 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.
| 0xB31B1B wrote:
| Spot on. The productivity gradient is extremely steep, and
| calling this out has become impolite.
| nateglims wrote:
| 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.
| flavio81 wrote:
| 100% based.
|
| Indeed this is one of the hard problems for a manager.
| whatnow37373 wrote:
| 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".
| stopyellingatme wrote:
| 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).
| tester756 wrote:
| >Nearly all complex technical projects are owned by one super
| smart person (Ex: linux).
|
| 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?
| grensley wrote:
| > Individual engineers don't own software; engineering teams own
| software.
|
| Very assertive, but almost always incorrect.
| michaelhoney wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/ 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 wrote:
| 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 wrote:
| > 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.
| mjburgess wrote:
| 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".
| typewithrhythm wrote:
| 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.
| anal_reactor wrote:
| > "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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Won't be getting imposter syndrome for sure for this role
| TZubiri wrote:
| 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 wrote:
| 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.
| djeastm wrote:
| >Easy to prove, can you think of an engineer that adds negative
| value? That deletes tests, or breaks stuff?
|
| No. Have you really worked with someone that did this and they
| weren't fired?
| TZubiri wrote:
| 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).
| gavmor wrote:
| It's hardly the fault of the engineer that products are
| poorly managed, or poorly designed.
| TZubiri wrote:
| No. The engineer is ultimately responsible for the
| product.
|
| If a bridge falls, will the engineer wash his hands?
| gavmor wrote:
| 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.
| TZubiri wrote:
| 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.
| soulofmischief wrote:
| Yes. He was the CEO of the company and I have stories that
| would keep you up at night.
| callc wrote:
| Please share. I can only imagine based on TZubiri's
| comments.
| buryat wrote:
| it's like cancer, it keeps replicating
| flavio81 wrote:
| >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.
| thom wrote:
| 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 wrote:
| This is my favorite take on 10x engineers
| https://testdouble.com/insights/the-looming-demise-of-the-10...
| js2 wrote:
| I'm not sure I've ever read a piece while nodding along so
| violently in agreement. Thank you for sharing.
| notepad0x90 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| earthnail wrote:
| 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 wrote:
| 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?
| interludead wrote:
| Yep, you're absolutely right that leadership is often the real
| bottleneck in building great teams
| gtsop wrote:
| 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
| irishloop wrote:
| Join my startup, where we harness the power of HackerNews arguing
| about 10x engineers into a new form of renewable energy
| roncesvalles wrote:
| >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 wrote:
| 10x managers
| paradite wrote:
| 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 wrote:
| 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!
| foweltschmerz wrote:
| yes, because of nothing else we need more in this day and age
| than the praising of mediocrity
| nodoll wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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...
| sam_lowry_ wrote:
| 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
| fmbb wrote:
| The real 10x devs are the ones that just do ten times less
| work than the rest but you cannot tell from their output.
| LarsDu88 wrote:
| 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 wrote:
| 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
| gatinsama wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| arkh wrote:
| 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.
| Juliate wrote:
| Not of that opinion.
|
| 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?
| rachofsunshine wrote:
| "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.
|
| -----
|
| [1] https://news.ycombinator.com/item?id=43006330 [2]
| https://www.otherbranch.com/shared/practice-coding-problem
| Juliate wrote:
| 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.
| rachofsunshine wrote:
| > 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.
| Juliate wrote:
| Thanks for the insights.
|
| 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.
| interludead wrote:
| There's a huge middle ground between "can't FizzBuzz" and "100x
| Linus-level genius," and that middle is where most functioning
| engineering teams live
| gatinsama wrote:
| 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.
| lowbloodsugar wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| One more empty reaction epiphany rambling of another random-god-
| knows-who.
| remoquete wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| A small team of skilled engs hurts managers' careers - they
| want large teams
| bdangubic wrote:
| 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.
| magicmicah85 wrote:
| 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://www.construx.com/blog/productivity-variations-among-...
| mmcromp wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| i think your flaw is conflating scientific research with
| software engineering
| breadwinner wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dilyevsky wrote:
| Author spent a lot of time mulling over "world class" this or
| that. World class engineers working on crud sounds like an
| oxymoron
| breadwinner wrote:
| > _The mythical "10x engineer" is always a net negative on
| teams building a boring CRUD app._
|
| No disagreement there at all. "Normal engineers" are all you
| need for "normal software" such as CRUD apps.
| dilyevsky wrote:
| The key sentence in article imo:
|
| > 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
| lolinder wrote:
| 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.
| chatmasta wrote:
| 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.
| breadwinner wrote:
| 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.
| jes5199 wrote:
| 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
| greazy wrote:
| > 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.
| nashashmi wrote:
| 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 wrote:
| 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.
| adityaathalye wrote:
| 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
| paulddraper wrote:
| Hard disagree
| ike2792 wrote:
| 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.
___________________________________________________________________
(page generated 2025-03-14 23:02 UTC)