[HN Gopher] In praise of "normal" engineers
___________________________________________________________________
In praise of "normal" engineers
Author : zdw
Score : 124 points
Date : 2025-06-19 17:36 UTC (5 hours ago)
(HTM) web link (charity.wtf)
(TXT) w3m dump (charity.wtf)
| lysace wrote:
| This is how you maintain/nurture a _mature_ service /product.
|
| It also works when building something new with a captive audience
| (banking, insurance, etc.)
|
| Everything doesn't need to be world-class. Sometimes long term
| development stability/resiliency is what matters.
| acedTrex wrote:
| > The best engineering orgs are the ones where normal engineers
| can do great work
|
| I quite like this. It is absolutely true as well, not all teams
| can be 100% rockstars. How well do you enable the average dev to
| be good, maybe not GREAT but good and reliable.
| lizardking wrote:
| Most great engineers were once good engineers. A healthy
| engineering organization helps its engineers on this path.
| spimmy wrote:
| yes! love this. and many great engineers will go back to
| being "good engineers" as they pick up new skills. rinse and
| repeat++
| AlotOfReading wrote:
| There are large parts of this I really like, but it's hard to
| overstate just how much I disagree with the idea that "The only
| meaningful measure of productivity is impact to the business".
| The natural result of this view is a focus on quantifiable
| changes and short term thinking. The greatest value of
| experienced engineers is in avoiding landmines that will destroy
| a project or even a company. It's difficult to quantify things
| that never happen, or communicate the value in avoiding them in
| terms that don't sound wildly hyperbolic.
| Retric wrote:
| "Impact on the business" isn't inherently a short term
| viewpoint.
|
| Maximum impact is a long term proposition.
| AlotOfReading wrote:
| It's not inherently a short term viewpoint, that's just the
| typical and natural result of adopting this view. Measuring
| long term impacts is hard. Attributing them is even harder.
|
| Here's a real scenario. I worked for a company that evaluated
| by impact. They had a cellular modem with known issues in the
| field. A replacement was designed to fix those issues, but
| couldn't be backwards compatible. The cost to immediately
| upgrade the field units was high, so deployment was delayed
| to a cheaper, later time. One way of looking at this is that
| the decision saved millions of dollars and that argument was
| made. After the evaluation and before the deployment, a set
| of older field units failed in such a way that it made
| headlines across the country, which would have been prevented
| by the new units.
|
| So, was the impact of those decisions negative the whole time
| in an unknowable way? Did their impact become negative as
| soon as the incident occurred? If the incident was still
| possible but hadn't occurred, would the impact be different?
|
| People aren't good at evaluating things that haven't happened
| yet, so they'll tend to focus on the things they can see
| immediately in front of them. That incentivizes engineers to
| build things that have immediate short term impacts and
| discount long tail risks which can't be reliably evaluated.
| tikhonj wrote:
| 100%. I've taken to using intentionally fuzzy phrases to
| describe productivity/impact/effectiveness/whatever. Like, "in
| a holistic accounting, person X did a great job". It's not
| necessarily--in fact, _necessarily not_ --easily quantifiable
| or legible, it requires some human insight and judgement, but
| so does any complex, creative endeavor. Trying to reduce
| management to metrics is inherently short-sighted.
| nonameiguess wrote:
| I'm not sure I totally agree with measuring value by avoiding
| landmines or anything at all related to project management, but
| it definitely bugs me to see everything reduced to business
| impact. There are plenty of things in life that matter to
| individuals, to humanity, to the entire world at large, that
| have nothing to do with selling products for money. When I
| think of the engineers I revere the most, I don't think of
| titans of post-2001 Silicon Valley so much as John von Neumann,
| Robert Oppenheimer, Nikola Tesla, Leonardo DaVinci, whoever the
| hell built the Roman aqueducts and Egyptian pyramids,
| Babylonians and Mesoamericans who figured out how to predict
| eclipses.
|
| Did these people have a business impact? I guess Tesla made
| Westinghouse a lot of money at one point, but that seems far
| from the most distinguishing thing that made him great at what
| he did. If anything, he was mediocre at business.
|
| Even if we want to look at current titans of the computing
| industry, I admire the work done by orgs like Nvidia or humans
| like Geoff Hinton, but they also just got lucky that what they
| were doing for completely different reasons ended up benefiting
| so tremendously from the galaxy-scale data harvesting that has
| been going on due to the Internet becoming primarily ad-
| monetized, which they didn't know was going to happen. How many
| equally great engineers toiled in obscurity on dead ends but
| did equally great work? Doug Lenat was just as great an AI
| engineer, if not better, than Geoff Hinton. History just went
| one way and not the other, due to factors completely outside of
| the control of either of them.
| spimmy wrote:
| idk, avoiding landmines seems like pretty significant business
| impact
| tikhonj wrote:
| it's real impact, but it requires folks to be able to
| confidently talk about counterfactuals--"we would have wasted
| X days if not for..."--which I've found to be really hard at
| most places
|
| the exception was places where leadership already thought in
| the same terms about software quality/etc, which meant I
| didn't have to do much convincing :P
|
| how would you build teams or structures to support that sort
| of holistic thinking about software?
| spimmy wrote:
| i think it has to start with having engineering managers
| and directors who are deeply technical themselves. the idea
| that you can split up this work into "managers do the
| people stuff" and "engineers do the technical stuff" is
| bananas. it's all sociotechnical work.
|
| this is why i advocate the engineer/manager pendulum so
| strongly. we get better results when management has strong
| tech skills (and staff+ engineers have organizational
| skills as well).
| esafak wrote:
| The company should be constantly striving to better quantify
| the unknown.
| ivape wrote:
| I've thought a lot about this my whole life. How do you build a
| good team? People simply don't like each other so the natural
| sorting that happens is that teams hire for who they like and
| likes them in return (or at least in mating terms, will certainly
| appear as likable as can be). By definition, this can never be
| the most optimal team.
|
| There may have to be a different way to think about this. How can
| you have things that hate each other but still run an amazing
| operation? The best operation I can think of is a _zoo_. You have
| your tigers over here, and your penguins over there. The
| operation as a whole is amazing.
|
| A company of just tigers will destroy everything and a company of
| just penguins need too much caretaking.
|
| Most armed forces are not a "team", they are an operation. If you
| constantly try to fit an operation into a team framework, that's
| when you'll try to turn penguins into tigers (how do you turn
| someone into a 100x engineer?). Or worse, you tell a tiger to
| chill out and relax with the penguins (you're asking for
| trouble). If you need a 100x engineer, make sure the engineer is
| a thousand miles away and gets paid like it and far away from the
| normal engineers lest they start believing the tiger cage is
| suitable for penguins or vice versa. It's a big operation, no
| teams.
|
| If you MUST build a team, then just be yourself. You probably are
| building something small dogs like, so hire a few street dogs and
| you won't even need to worry about zoo-scale decisions and
| operations. You won't need to go through the mistake of jamming 4
| different species into the same enclosure to finally learn how
| things live separately but together.
| polytely wrote:
| > People simply don't like each other
|
| this seems like an insane statement to me, you can just hire
| for ability to function in a team?
| ivape wrote:
| You think people not liking each other is an insane
| statement? I'll paraphrase Thomas L Friedman on a recent
| thing he said about the middle east. He said, paraphrasing
| "never listen to what an Israeli or Palestinian tells you in
| English, always see what they say to each other in their own
| language". Obvious insight, but not well practiced.
|
| Do you think the amicable discourse on HN is indicative of
| feelings? Do you think the Hi and Hellos you get at work
| displays the true fabric of things?
|
| I'll just start with small examples in case you want to keep
| the convo going:
|
| 1) Leetcode is a thing
|
| How? Dude, there's _dislike_ of a certain type of developer
| and _obsession_ toward the idea of another type of developer.
|
| 2) Agile is a thing
|
| How? Dude, there is _dislike_ for the autonomy and value a
| developer brings.
|
| 3) How do you turn a "normal" engineer into 10x engineer
|
| How is this question constructed? What is "normal" and who
| defined the ideal "10x"? How do you turn your "normal" wife
| into a dime? What? What kind of question is this? The
| business _dislikes_ the price of a developer, how do we get
| more value for what we paid. These are the things you have to
| read into.
|
| ...
|
| N) Plenty more examples, the tech industry operates on shade
| because our PR game is so fake (seriously, remember the ping
| pong tables?)
|
| ---
|
| Which brings me back to "people don't really like each other"
| and good operations need to manage that.
| mulmen wrote:
| One of the most contentious disagreements between myself and
| my current manager is that I say we should trust our peers to
| do good work and enable them with that fundamental assumption
| in mind.
|
| IMHO if you assume the people around you are incompetent or
| malicious then that's exactly what you'll find.
|
| Further, if the people around you are actually incompetent or
| malicious then awareness of that fact won't change the
| outcome anyway.
| ivape wrote:
| _IMHO if you assume the people around you are incompetent
| or malicious then that's exactly what you'll find._
|
| What are you implying, that you are some kind of God? So if
| you see them as bad, often bad appears, and if you see them
| as good, then often good appears? That's some magical stuff
| there.
|
| _Further, if the people around you are actually
| incompetent or malicious then awareness of that fact won't
| change the outcome anyway._
|
| True. But we're here talking about managing serious
| operations, in which case being keenly aware of the above
| fact helps make decisions and they don't all have to be
| "evil" decisions and can often be quite beautiful
| solutions. You can reallocate people to optimize them
| without firing them, feeding one more person.
| mulmen wrote:
| > So if you see them as bad, often bad appears, and if
| you see them as good, then often good appears? That's
| some magical stuff there.
|
| Pretty much, yeah. Another way of saying this is
| "perception is reality."
|
| Everyone has their own perception of reality. As a result
| some people like you and others don't. You can choose to
| perceive those around you as favorably as possible. You
| control your perception of reality.
|
| It's similar to this HN guideline:
|
| > Please respond to the strongest plausible
| interpretation of what someone says, not a weaker one
| that's easier to criticize. Assume good faith.
|
| I think this is _the_ defining characteristic of HN that
| makes it a valuable place to be. It's a deliberate choice
| I wish was more widespread.
|
| > True. But we're here talking about managing serious
| operations, in which case being keenly aware of the above
| fact helps make decisions and they don't all have to be
| "evil" decisions and can often be quite beautiful
| solutions. You can reallocate people to optimize them
| without firing them, feeding one more person.
|
| Totally. And you should assume the best about those you
| manage so you can move them into a position where they
| can succeed rather than dismissing them for their flaws.
| tikhonj wrote:
| I definitely agree that the best teams have cultures that make
| even normal engineers incredibly effective compared to the status
| quo. Managers definitely put too much stock in hiring and
| "engineering quality" compared to culture, trust, systems and
| processes.
|
| > _Any asshole can build an org where the most experienced,
| brilliant engineers in the world can build product and make
| progress._
|
| But I have to wonder: if "any asshole" can build orgs like that,
| why don't they? I know of only a handful of orgs that actually
| manage to build strong teams of really strong engineers, and
| they're almost exclusively either trading firms or
| specialized/research-oriented teams. What's stopping everyone
| else?
|
| I guess this comes down to the initial point in the article: what
| do we even _mean_ by "productivity"? (Or, the word I'd prefer:
| "effectiveness"?) There are lots of orgs where only experienced
| folks can succeed because they're the best at working around and
| tolerating disfunction. I've seen performance review processes
| that--intentionally or unintentionally--selected not for some
| general technical strength/taste/etc, but for the willingness,
| ability and stamina to put up with management dysfunction. But,
| to me, that is very much _not_ what I have in mind when I think
| "top engineer".
| sorokod wrote:
| Beyond budget constraints, those brilliant engineers may not be
| good team players.
|
| Their brilliance may be in the way of finding the necessary
| compromises and doing the required but not intellectually
| challenging work.
| tikhonj wrote:
| I dunno, almost all the brilliant engineers I've known have
| also been great team players and mentors. Not all, but I'd
| say it's pretty correlated.
|
| The reason brilliant assholes stand out is one of those
| statistical paradoxes whose name I've forgotten: somebody
| who's an asshole _has_ to be brilliant to succeed, while team
| players can get pretty far with a wide range of skill levels.
| spimmy wrote:
| ha! ok, i never thought of it quite like that.
| MontyCarloHall wrote:
| You are thinking of Berkson's Paradox! [0]
|
| [0] https://en.wikipedia.org/wiki/Berkson%27s_paradox
| bluefirebrand wrote:
| > But I have to wonder: if "any asshole" can build orgs like
| that, why don't they
|
| Well the supply of extremely talented engineers isn't limitless
| so you wind up competing for talent with companies much larger
| than you building much cooler stuff or the same stuff but
| paying more
| burningChrome wrote:
| >> I know of only a handful of orgs that actually manage to
| build strong teams of really strong engineers
|
| The best teams I've been on work like a team in sports.
|
| You have the guys who are really good, really sharp developers.
| They know all the ins and outs of the framework, but are
| insanely specialized with one thing, but do the majority of the
| heavy lifting. Then you have the mid-range guys who are more of
| the JOT guys. They know UI/UX, accessibility, front-end dev and
| some back-end stuff. Then you have all the entry level rubes.
| The guys you can give them something to do and they'll figure
| it out. They're usually learning as they go, but can handle
| tasks with some direction and hand holding. As the project runs
| on, they get more comfortable with the processes and tasks so
| they need less direction and hand holding.
|
| Building teams is all about finding a good mix of people who
| compliment each other. Too many of the really sharp devs and
| they'll be arguing over everything. Get too many mid-range or
| entry level guys and it will slow down the whole project. You
| also have to have devs who are comfortable with their skill
| level and know what they're expected to be doing. Too many
| times I've been on teams where the mid-range guys start bumping
| heads with the senior devs. Lunch becomes a rage fest over what
| we _should_ be doing better. They think _they_ should a lead
| dev, not the guy they don 't like.
|
| The last thing is your senior/lead devs have to have the right
| attitude too. I've been around some insanely sharp lead devs,
| but they're complete assholes. They know everything, you know
| nothing. You use shit frameworks, they're always on the cutting
| edge and your an idiot because you like Angular not something
| bougie like Svelt.
|
| The key in all of this is finding the chemistry that works.
| When you get that chemistry, you can capture lightening in a
| bottle and really build some amazing stuff. When it works, its
| the coolest thing. People are dialed in, they're enthusiastic
| about what they're doing. They're willing to work longer hours
| to make sure the product we're building is incredible. The team
| is happy, delivering and working on faster sprints and things
| just feel effortless.
| ChrisMarshallNY wrote:
| _> if "any asshole" can build orgs like that, why don't they?_
|
| The biggest reason, is that most first-line and middle managers
| suck. They can't create and maintain a productive environment.
|
| The cure is/was to pay heaps of money. People will put up with
| almost any kind of hell, for good pay.
| spimmy wrote:
| because there is, by definition, an extremely limited supply of
| the "best engineers in the world". if you can afford to pay
| top-10% salaries, and attract and retain top-10% engineers,
| more power to you.
|
| maybe not literally "any asshole" can do it -- but it certainly
| asks more of your leaders to craft sociotechnical systems
| oriented towards learning and enablement. and i don't think
| that's a bad thing.
| MontyCarloHall wrote:
| > But I have to wonder: if "any asshole" can build orgs like
| that, why don't they?
|
| Other posters have said money, but it's also a function of time
| --how long can a company afford to wait to find the perfect
| "unicorn" engineer who excels in every aspect of the product
| but may take a long time to hire, versus hiring someone whose
| expertise only covers some of the product's needs but can be
| found immediately?
|
| Certain companies benefit disproportionately from unicorns,
| especially those in interdisciplinary fields. For instance, in
| quantitative finance, a single individual who's an excellent 1.
| systems programmer, 2. mathematician, and 3. financial market
| expert will contribute a lot more than a team of three
| specialists in each of those domains. But it's a lot faster to
| hire that team of three versus finding the rare individual who
| can supplant a whole team. This is also true in less exotic
| fields--it's rare to find someone who's truly a "full stack"
| web developer, with a deep understanding of networking
| protocols and Linux system administration and (cloud based)
| distributed systems and databases and caching services and
| frontend development & cetera. But the company that can afford
| the money and time to find these people will make a much better
| product than the company that cannot.
|
| (Whether the product actually needs the quality commensurate
| with all that engineering firepower is an entirely other
| question.)
| chickenzzzzu wrote:
| You spent all this time talking when you could have been coding.
| paxys wrote:
| There are plenty of good "normal" engineers whose abilities top
| out at following direction from management, implementing a spec
| (albeit really well), adding to an existing architecture etc. I'd
| wager the vast majority of the industry falls into this category.
| Yes, it's very important for an org to ensure that these kinds of
| engineers are successful, because they are the workhorses of your
| company and without them nothing will get done.
|
| Ultimately though you can't have a workforce _just_ of these
| engineers. Someone has to lead. Someone has to tell management
| what to build. Someone has to invent new tech from scratch.
|
| "10x engineer" is a bullshit LinkedIn thoughtfluencer term that
| has unfortunately caught on, but everyone who has worked in the
| industry for more than a day knows that there is a hierarchy in
| the tech org, and the ones on top _are_ more valuable than the
| rest.
| ysofunny wrote:
| > Someone has to invent new tech from scratch.
|
| uhm, as a research university or private company like a
| startup??
| commandersaki wrote:
| 10x engineer in the original sense to me is simply someone that
| 10x-es your company in some way. Maybe Avie Tevanian who
| brought Apple OSX/etc. or Andy Rubin who brought Google
| Android.
| tikhonj wrote:
| > _The smallest unit of software ownership and delivery is the
| engineering team._
|
| I see where this is coming from, but it's also pretty sad. In my
| experience, it tends to create environments where engineers are
| second-class citizens compared to managers or product: we're just
| responsible for "delivery", but can't independently make any real
| decisions beyond a tiny scope. Our timespan of discretion becomes
| measured in days or weeks, while, on the best teams I've seen,
| it's measured in months, quarters or years.
|
| It's counterintuitive, but you absolutely _can_ have real
| individual owernship for engineers without creating single points
| of failure or brittle systems. It 's a matter of having other
| sources of slack, encouraging quality work, and giving people a
| lot of room to fluidly adjust what they're working on when. Folks
| still have real ownership and can make longer-term decisions on
| their own, but they also collaborate in _ad hoc_ ways and share
| _tacit_ knowledge, so that somebody else can jump in, help out or
| even take over in a pinch. I 'm being a bit vague, but all I can
| say is that I've seen this before, and I'll know it when I see it
| again.
|
| In practice, the model I saw did end up with more rewriting than
| a normal team--but we were still way more productive overall,
| even accounting for the rewrites! Turns out that rewriting
| systems incrementally, in self-contained chunks, is an amazing
| way to both evolve the design _and_ to build up instutitional
| knowledge and capacity. It looks like waste, but it 's actually
| slack that is crucial to making your system as a whole more
| flexible, adaptable and resilient. (In fact, that's true of _a
| lot_ of the "waste" top-down management systems try to reduce--
| I'm incresingly convinced that anybody trying to optimize
| software team "utilization" is actively sabotaging the work!)
| dkarl wrote:
| People outside of engineering can't give engineers immediate
| credit for long-term decisions. They don't have the competency
| to know what to reward.
|
| I'd go further and say that even within engineering, people
| outside of a team can't give immediate rewards for work whose
| long-term value is internal to the team, for the same reason:
| they don't know if the work you're doing is actually valuable
| or is just superficially similar to the kind of work that often
| does have long-term value.
|
| If you're confident enough in your long-term decisions, and how
| you spend slack time, then you should be fine with being
| rewarded for delivery, since you expect your long-term work to
| pay off in future delivery and future rewards.
| maxsilver wrote:
| > They don't have the competency to know what to reward.
|
| I'd even take this a bit further, and say this is basically
| an argument that the engineering manager, engineering/dept
| VP, and CTO all need to be engineers or past-engineers
| themselves, so they actually do have enough competency to
| know what to reward.
| spimmy wrote:
| just made this exact same point myself, lower in this
| thread. (author here)
| tikhonj wrote:
| the best manager I ever had was a VP who came from a
| banking background--the key thing was not that he had
| written a lot of production software himself, but that he
| had _seen_ what great software looks like (apparently he
| worked closely with the core Slang /SecDB guys), and was
| willing to trust engineers who could build similar styles
| of tools
|
| on the other hand, the recent skip-level I had that got me
| to quit in six months was an engineer himself, but had no
| real opinion on code quality _or_ anything more than a
| superficial, process-oriented understanding of the dynamics
| on the team :(
|
| moral of the story: taste is necessary; direct technical
| experience is _mostly_ necessary, but nowhere near
| sufficient
| marcosdumay wrote:
| What you are describing _is_ direct technical experience.
| That the banker did have, but the one titled as engineer
| didn 't.
| EPWN3D wrote:
| Honestly, I don't even think that does the trick anymore.
| Once you're on the management track, you get infected with
| the same MBA bullshit as the rest of management, and your
| brain rewires itself around that culture and those
| incentives.
|
| I've worked for VPs who were former engineers, and they
| eventually lost their appreciation for the artistic side of
| the discipline and got obsessed with features, demoes, burn
| down charts, etc.
|
| If you want to solve this problem, you need to keep the
| professional manager class out of your org. Because once
| they get a foothold, they fuck everything.
| FirmwareBurner wrote:
| _> they eventually lost their appreciation for the
| artistic side of the discipline_
|
| It's easy to obsess with the artistic side of the
| discipline when you're doing it on someone else's money
| and assume it's coming from an infinite bag.
|
| Once you are a manager and given limited resources to get
| a job done by a certain date, art goes out the window and
| it's all about efficiency, you get paid to get the job
| done, not have pretty code.
|
| I think people focusing on SW engineering being art have
| been spoiled by only working at companies with infinite
| money, like Google, who treat work as play in hopes that
| 1 in a million toys will be the next billion dollar idea.
| But open your own shop, get customers, hire people and
| let's see how much you'll care about their work being art
| VS efficient, when it's your dime on the line, then
| you'll embrace and understand the managerial mindset
| you've despised.
| tikhonj wrote:
| Writing high-quality code lets you get more done faster,
| with less people. It's not just art for art's sake!
| That's what drives me crazy about this: you can just be
| better, it isn't even a tradeoff, but most managers
| choose to be worse instead.
|
| It's been a frustrating thing to talk about. The people
| who've seen high quality work in action just say "well,
| obviously it will be faster and more effective", and the
| people who haven't simply refuse to believe it. It's like
| there are two incommensurable paradigms around software,
| and we're just talking past each other :(
|
| The best places get a ton done with very few people.
| Like, XTX has, what, [?]100 engineers? And they're
| operating a system trading across 35 countries using
| hundreds of petabytes of data. That's more logical
| complexity with higher robustness and performance
| requirements than tech companies with thousands of
| engineers. And they're not doing this by slinging crap
| code at the wall as fast as they can!
| FirmwareBurner wrote:
| _> Writing high-quality code_
|
| Who defines what "high quality code" is and who enforces
| it in a team? Because what's high quality to you might
| not scan to other members of the team, and if you want to
| your standards across the team then you have to spend
| time and effort educating the people and enforcing the
| standards. And now you're wasting time obsessing over
| standards and guidelines while your efficiency doesn't
| increase.
|
| _> you can just be better_
|
| Better how?
|
| _> The best places get a ton done with very few people._
|
| Is it because the quality of their code, or because those
| people are better at what they do and better at working
| as a team?
|
| _> And they're not doing this by slinging crap code at
| the wall as fast as they can!_
|
| Because they're a highly specialized company making a
| highly niche product who's features must include high
| tolerance and availability ahead of new features. You
| can't in good faith compare trading firms to your average
| web dev shop. different projects, different customers,
| different budgets and profit margins.
|
| That's like comparing an F1 car to a road car and telling
| the engineers working on the road cars to "just be
| better", that the reason their work is not matching the
| F1 car is the quality of their drafting and not the 100x
| difference in budget and requirements.
|
| Edit to reply here to your child comment below:
|
| _> If you have a strong team, you don't have to
| "enforce" quality._
|
| Obviously you can do a lot with fewer people when you
| have crazy money and therefore can afford very high
| hiring bar. That's not most companies and not most SW
| projects though.
|
| Hence my original comment: _" I think people focusing on
| SW engineering being art have been spoiled by only
| working at companies with infinite money, like Google"_
|
| Your point only works if you cherry-pick well funded big-
| tech like XTX, but once you step out of that bubble to
| non-tech companies who need SW products on smaller
| budgets things are way different. Those places don't have
| the hiring bar of XTS, so the quality will be different.
| tikhonj wrote:
| If you have a strong team, you don't have to "enforce"
| quality. And if you think that quality is "obsessing over
| standards and guidelines" we're _definitely_ operating in
| categorically different paradigms.
| bsoles wrote:
| > ... you get paid to get the job done, not have pretty
| code.
|
| Artistic side of the discipline doesn't mean pretty code.
| It means good design, no rushed spaghetti code,
| expandable architecture, etc.
|
| "Getting the job done", in manager speak, often means
| shipping features with awful code behind them, just to
| give the manager enough time to move up the ladder
| without suffering the consequences of their awful
| decisions. With engineers left behind to fix the mess.
| FirmwareBurner wrote:
| _> With engineers left behind to fix the mess._
|
| There would be much less demand for jobs if there were no
| messes to fix.
| scarface_74 wrote:
| The purpose of the engineer is to add business value by
| either reducing costs or increasing revenue. You reward
| employees for _results_.
| spimmy wrote:
| i'm struggling to see how what you are saying you value is any
| different from what i am saying i value (author here).
| tikhonj wrote:
| possibly we're saying the same things in different ways, or
| maybe it's just hard to pin the difference down in a words
|
| what do you mean by "the smallest unit of software ownership
| and delivery is the engineering team" in practice?
|
| what's the largest scope of work some engineer can do
| entirely on their own recognizance?
| spimmy wrote:
| well obviously there's a ton of variance here. but in the
| type of engineering i'm most familiar with, any sizable
| amount of production services or surface layer being owned
| by a single person is a bad thing.
|
| individuals can get sick, go on vacation, etc. having it be
| owned by a team creates resiliency from a people
| perspective.
| tikhonj wrote:
| well, maybe that explains why I've gravitated hard away
| from general-purpose backend work :)
|
| I've had a great time on teams where folks can go off and
| build great tools/libraries/etc that others can use and
| adapt, without needing a whole team around them--ideally
| there's lots of collaboration, but it doesn't have to be
| formally structured
|
| I guess the main difference is that you don't have to
| _operate_ a tool or a library; if somebody has issues
| with it, they can patch the code themselves or simply
| adapt around it in their own code
|
| I also enjoyed working on simulation and optimization
| problems for similar reasons; there's lots of direct
| business value, but there's enough slack around it that
| if I go somebody else can take a model over and maintain
| it without any issues
|
| unfortunately lots of organizations do not know how to
| make library-style code "count" the same way a service or
| stateful component "counts"
| Jensson wrote:
| > individuals can get sick, go on vacation, etc. having
| it be owned by a team creates resiliency from a people
| perspective.
|
| Resilience against what? It isn't like teams make
| decisions quickly, an individual will get decisions done
| faster in almost every case, and if they are on leave
| right now its just slightly slower than a team.
|
| For example, if you ask a team "can you get this feature
| in", likely they will come back at you a few weeks later.
| That isn't faster than an individual on leave, so I don't
| see what "resilience" even is here.
| karmakaze wrote:
| For most teams that I've worked in, I've chosen certain
| parts to guard and nurture into a better state. I'll
| recognize certain shortcomings that have a real-world
| negative impact and incrementally nudge the design and
| future decisions in that direction. At some point it will
| have arrived. Eventually people that are in non-adjacent
| teams gets to know that I'm the XyzService person. I do
| socialize the design and implementation changes and even
| distribute the work and write up thought/decision
| processes for the team to see. I'll eventually run out of
| challenging work and move on to another sore area with
| the team well capable of managing what they've got. If
| the process were to be interrupted at any time, it's
| generally not in any worse shape than it started, only
| failing to reach the desired end improvements.
|
| _Edit: My current pet project is eliminating a bad DSL
| which has led to so many bad implementations and near-
| identical but different copies because factoring aspects
| isn 't well supported. I started with a PoC, then a
| Hackdays project, and now with that looking good, the
| team is willing to convert all of the codebase we
| maintain so that we can use normal programming language
| features like static typing and source navigation with
| easy to follow data flows._
| closeparen wrote:
| We have a pretty strong culture of individual ownership,
| but each owner has at least one other person reviewing
| their PRs, usually several junior engineers contributing,
| design review at the team level, and oncall at the team
| level.
|
| When the owner is away, the other people involved keep
| things moving. If they're away long-term or leave the
| company, we'll designate someone else to take ownership.
| bevr1337 wrote:
| > what's the largest scope of work some engineer can do
| entirely on their own recognizance?
|
| None. Everything we develop was built on someone else's
| work. Even when our collaborator is not physically in the
| room with us, the work is still a collective endeavor.
| matthewkayin wrote:
| I think that rewrites are an important part of how software is
| written, and it's an important part of being "agile", in the
| sense that you can go in and write a prototype that's coded
| very simply without much regard for long-term architecture,
| knowing that requirements likely will change and that you
| likely won't get the design right on the first go anyways.
|
| Coding is like writing, in the sense that it's often faster to
| write a sloppy first draft followed by a better second draft
| than it is to agonize over getting the first draft right on the
| first go. The first draft is generative. Its purpose is not to
| be good but instead to let you get something built quickly and
| to let you explore the problem, so that you know what edge
| cases you'll need to account for in your final architecture.
|
| But this still of working will never get through management
| because the moment you show them a working product, they'll
| tell you to ship it and won't give you a chance to rewrite.
|
| I think the best way to solve this is to flatten the hierarchy.
| Get rid of the notion of managers who rule over engineers and
| give ownership of the code back to the engineers. Have the
| engineers and product "owners" make decisions together in a
| democratic fashion.
| xyzzy_plugh wrote:
| I used to share this mindset, and I still agree that individual
| ownership is possible for engineers. Unfortunately many, many
| engineers simply do not want it. I would reckon most if not all
| engineers are comfortable with ownership at the team boundary,
| but many simply do not care beyond that. It's just a day job.
|
| Individual ownership at the individual engineer boundary can
| breed distrust within a team or org, but often alienates team
| members who like their job but aren't trying to lead, at least
| with respect to what ownership entails. In this blended
| environment someone almost always ends up without agency.
| Sometimes no one gets agency. Who wants that?
|
| It's surprisingly simple and effective by comparison to give a
| _team_ agency and ownership, usually in part because of the
| dynamic of having a manager or lead to begin with.
|
| Simply put, there are too many modes of failure at the
| individual level for software ownership to settle there
| comfortably: staffing changes, job security, career growth are
| the obvious ones, but the dysfunction (even in otherwise
| healthy orgs, there's always _some_ amount) will find the
| shortest path to complete the circuit here.
|
| I like to think of it like a gearbox. If you only have one
| gear, and you break it, or wear out all the teeth, then you
| don't get to go. If you have many gears, well, the ride may be
| uncomfortable at times, but you'll keep moving.
| almosthere wrote:
| I personally think _most_ people should treat their jobs as a
| _day_ job - unless they have actual ownership in the company
| (beyond what would be a 50-100k payout at option time)
| thePhytochemist wrote:
| I think this is key when people talk about "ownership".
| Actually owning a product means that if it fails you're
| holding the bag, if it succeeds you take the profits. And
| you have full control over it. Unless a company actually
| wants to do this I wish they wouldn't use that english
| word.
|
| Trying to hire an employee and tell this story that they
| "own" the product is just silly. It's like companies that
| try to describe themselves as a family - just kind of a
| weird and incorrect use of a real word that has other
| meaning.
| ghaff wrote:
| I certainly did a ton of traveling/speaking/meeting with
| customers/sometimes late night calls in different time
| zones/etc. but I still treated it as colloquially a "day
| job," albeit not really a 9-5 one.
| eikenberry wrote:
| In my experience this is mostly big-company vs. small company
| cultural differences due almost strictly to size and scaling.
| Small companies work best when individuals have ownership and
| large companies with team based ownership. They attract
| culturally like-minded people.
| tikhonj wrote:
| The highest-agency, highest-ownership team I worked on was
| at Target of all places. (To be fair, it was not a typical
| team for the company!) The VP who made that work learned
| that style of leadership from a decade in Strats at
| Goldman. Both are pretty big as companies go!
|
| On the flip side, I've seen early-stage startups and scale-
| ups where engineers did not have real ownership. It's easy
| to get into a situation where an individual engineer "owns"
| a specific part of a startup... but can't make any _real_
| decisions on it because the founders want to dictate work
| at a week-to-week level or something.
|
| It's a function of culture, not scale.
| hnthrow90348765 wrote:
| >we're just responsible for "delivery"
|
| Ownership has never gotten me anything but more headache. I'm
| just here to put the things on the pages.
|
| We've got to charge for additional responsibility.
| Manager/executive pay scales with how many people they're
| responsible for, no sense in not giving developers that too.
| athoscouto wrote:
| Agreed that you can have real individual ownership. Not only
| that, I think that is the only way to be really "productive".
|
| But I think that is beside the point.
|
| Individuals are not fungible, but team members are - or at
| least can be, depending on how you structure your teams.
|
| And as your org grows, you want predictability on a team level.
| Skipping a bunch of reasoning steps, this means having somewhat
| fungible team members, to give you redundancy.
|
| The engineering parallel here is the tradeoff between
| resilience and efficiency. You can make a system more reliable
| by adding redundancy. You make a system more efficient by
| removing redundancy.
| bsoles wrote:
| I blame Agile and the like for fucking up individual
| ownership by treating every engineer and every task
| interchangeable. You can't build expertise by working on a
| different type of task every sprint...
| alganet wrote:
| Fuck this. All engineers are normal engineers. Everyone can be an
| engineer.
| ericvolp12 wrote:
| > Make it easy to do the right thing and hard to do the wrong
| thing.
|
| This is basically the mantra of every platform team I've worked
| on. Your goal is to make the easy and obvious solution to
| engineers' problems the "right" one for the sustainability of
| software and reliability of services.
|
| Make it easy to ship things that are reliable and manage
| distributed state well and can scale well and engineers will
| build better muscle memory for building software in that shape
| and your whole org will benefit.
|
| This will never stop being true.
| simonw wrote:
| Coincidentally, Charity Majors wrote one of my favorite essays
| about that too: https://charity.wtf/2018/12/02/software-sprawl-
| the-golden-pa...
|
| > Assemble a small council of trusted senior engineers.
|
| > Task them with creating a recommended list of default
| components for developers to use when building out new
| services. This will be your Golden Path, the path of
| convergence (and the path of least resistance).
|
| > Tell all your engineers that going forward, the Golden Path
| will be fully supported by the org. Upgrades, patches, security
| fixes; backups, monitoring, build pipeline; deploy tooling,
| artifact versioning, development environment, even tier 1 on
| call support. Pave the path with gold. Nobody HAS to use these
| components ... but if they don't, they're on their own. They
| will have to support it themselves.
| raincole wrote:
| > Any asshole can build an org where the most experienced,
| brilliant engineers in the world can build product and make
| progress.
|
| Yeah, it's obviously not true.
|
| If it were true then the market salaries of coaches and trainers
| in professional sports would be really low. And they aren't.
| physix wrote:
| It's a good article, but does it go without saying that when one
| says "engineers", it's about "software engineers"?
|
| One reason I clicked on this one is that I was hoping to learn
| stuff about engineers beyond just software.
|
| But it's a good read nevertheless. Thanks for that!
| norir wrote:
| I tend to think that much of the difference between great and
| mediocre engineers comes down to mindset. The great engineers
| I've encountered have a commitment to making everything they
| touch better. They are adaptable and persevere. They believe they
| will either succeed at the task at hand or conclusively determine
| that it isn't possible given the current constraints. They
| recognize that failure will happen and do not get discouraged by
| it and instead see it as an opportunity to growth. When they
| encounter an issue caused by systemic problems, they will try to
| fix it systemically. They will not ship the first draft and will
| take a little it of extra time to get things right, which slows
| the initial release slightly but more than pays for itself with a
| dramatically lower maintenance burden.
|
| This type of engineer is often misunderstood and underappreciated
| by management. Management is often motivated by immediate short
| term goals. Instead of cherishing the work of the engineers who
| build the foundational systems that will enable the long term
| success of the org, they complain about them missing arbitrary
| short term goals and accuse them of doing engineering for
| engineering sake instead of real work.
|
| Management will celebrate the coder who whips up a buggy, but
| cool, feature in a week and will look the other way at the fact
| that the feature will always be a little bit broken because of
| its shoddy construction and instead will allocate some lesser
| engineers to maintain it. If instead the feature had been built
| correctly from the start, it may have been launched a bit later,
| but the overall cost will be much lower. Moreover, the poor
| engineers who are forced to maintain it (and let's be honest, the
| people who quickly churn out shoddy but shiny work almost never
| have to maintain it themselves) will not only be wasting their
| time, they will be actively internalizing the anti-patterns
| present in the code. This both inhibits their growth and
| understanding of good design principles and teaches them the bad
| lesson that crap is good and unless they have a uniquely strong
| character or good mentors, they will tend to either become
| demoralized (hurting their productivity and value to the company)
| or they will internalize the incentive to get out of maintenance
| work and build shoddy features of their own to pass down to the
| next poor soul.
|
| The truly great engineer is the one who breaks this cycle by
| building extendable systems that are correct by design and takes
| accountability for everything they ship. They raise up the entire
| org both by their work and example. In the long run, they will be
| far more productive and positively impactful than the sloppy
| cowboy coder.
|
| Unfortunately, the industry writ large celebrates and
| incentivizes cowboy coding so doing the right thing is very much
| against the grain. Indeed, the people who rise up the org chart
| tend to be the cowboys so they cannot even see the value of the
| other way and will often actively antagonize or undermine those
| who do the right thing (and threaten their dominant position in
| the org).
| spimmy wrote:
| many fair points here <3
| cardassia wrote:
| Well written, I agree based on my experience that you'll end up
| being penalized in most places as the one who spends a smidge
| more time incubating quality work. I really feel this now at my
| job where not only is the work shoddy as promoted by
| management, the motivations and ideas behind everything are
| even worse. I'm talking extreme levels of NIH syndrome. It's
| upsetting to see something like GraphQL, which could just be a
| gosh darn HTTP request using off-the-shelf libraries, be turned
| into this absurd Rube Goldberg machine of custom libraries and
| bizarre workflows.
| ChrisArchitect wrote:
| Discussion on the previous IEEE Spectrum 'version' a few months
| ago:
|
| https://news.ycombinator.com/item?id=43356995
| spimmy wrote:
| oh wow i missed that, thank you!
| anarticle wrote:
| This is all well and good, but it all hinges on your manager not
| being an insane maniac. All of those systems are great with the
| right manager, but if your manager is a KPI chaser / VP position
| seeker you are cooked.
|
| I have had managers that were essentially like a sergeant,
| serving engineers as a phalanx against the business so we can go
| fast.
|
| I have also had a manager who was so obsessed on showing off how
| much better of a dev he was than everyone else on the team, that
| he was largely hated and all talent on that team moved away if
| they could. I moved, and had a much better time in data science.
|
| I largely agree that killer onboarding, and a clear path to
| deploy are big wins for normalizing your dev culture to new
| hires. The measurement tech is always a double edged sword.
| narag wrote:
| Some good points, bad logic. The fact that you can't effectively
| measure something doesn't mean that something doesn't exist.
|
| Individual productivity exists.
|
| Maybe it's easier to measure groups' productivity? Probably.
|
| "Business impact"? I don't think so, that later concept seems
| much more arbitrary. But feel free to look for the keys under the
| lamplight. If you choose that metrics, you're not going to retain
| many extra productive people anyway.
|
| The old problem: judging the work of an expert is very difficult
| if you lack comparable expertise. I can give you advice, but I
| can't make you smart to accept it. How could you tell if I'm a
| genius or an overconfident asshole?
| sailfast wrote:
| A real genius can often explain their work without being an
| asshole, I think. So it's fairly straightforward to tell the
| difference.
| tikhonj wrote:
| the real problem is not that we can't measure productivity, but
| that we can't even fully _define_ an abstract productivity
| metric--what does "productivity" even mean?
|
| we can come up with some notion that talks about the net
| _effect_ of an individual (the "wins about replacement" of
| programmers), but that tells us absolutely nothing about _how_
| any given individual achieves that; hell, the net effect of any
| given individual is presumably a function of the entire context
| and the rest of the org, not just of the individual!
|
| alternatively we can try to define more direct notions of
| "productivity" even if we can't measure them, but those notions
| end up varied, multidimensional and, again, painfully context-
| specific--it's absolutely a useful thing to think about, but it
| does not let us pin down what a "top 1%" engineer "really" is,
| or even if that's a meaningful notion
| ljm wrote:
| I saw a post like this some time earlier this year and my first
| reaction is the same...
|
| Normal? Seriously?
|
| The article attempts to address this in an incredibly clumsy way
| by saying, well, everyone is normal in some way! It totally
| misses the mark and basically pays lip service to the issue after
| it set the stage, switching over to bigger picture diversity.
|
| Benefit of the doubt, the intention is to say 'average'. The
| people in the middle of the bell curve.
|
| 'Normal' suggests that, outside of that range, you are abnormal
| if you are terrible and abnormal if you're talented above or
| below the median.
|
| There's a non-zero overlap between abnormal and neurodivergent,
| both ways.
|
| Given the number of occurrences of '10x engineer' they should
| have gone with that and not 'normal'.
| ivape wrote:
| Once someone(s) pay a lot of money for something, they will
| always be critical of it. They literally bought the thing. You
| don't think I'd write articles about the pros/cons
| coulda/shoulda/woulda if I paid $180k for a car?
|
| A lot of businesses are truly poor and cannot afford buying the
| things they buy (in this case, it's people). Then the people
| have to go through their horrible post-mortem analysis. Build
| your own company, write your own shit, and stop analyzing how
| to min/max a person that was out of your league to begin with
| (never even in your price range comfortably, now shut up with
| what could have been done better).
|
| If for whatever reason the above paragraph addressed businesses
| that were rich, well then, I have nothing to really say about
| that, because in that case we're dealing with a monstrosity for
| which there are no words.
| ljm wrote:
| Why does this read so much like a copypasta.
| ivape wrote:
| I guess I'm figuring out my voice.
| physix wrote:
| > Build sociotechnical systems with "normal people" in mind
|
| From the perspective of the composition of software engineering
| teams: Most of us have to make due with the average, we strive to
| find the above average and avoid the mediocre, but mostly we are
| teams composed of "normal" people. The article has some good
| advice for making the best out of a group of normal people. It
| particularly relevant because it's unlikely that you'll see
| anything else.
| Tade0 wrote:
| > Are you using golang, python, COBOL, lisp, perl, React, or
| brainfuck?
|
| For years now I had this feeling that people confuse React with
| the entire frontend ecosystem, but dismissed it thinking that
| surely they're aware that there's a whole world of non-React
| frontend out there?
| mlhpdx wrote:
| > someone who is a 10x engineer in a particular skill set is
| still going to have infinitely more areas where they are normal
|
| Yep. I've been here for a career or so with moments of brilliance
| and marathons of mediocrity, but consistent kindness (I hope).
| bgwalter wrote:
| The article was commissioned by refactoring.fm, which, naturally,
| features Refactoring AI!
|
| Unsurprisingly the article comes to the conclusion that anyone
| can be trained, that 10x engineers are overrated, etc. The AI
| promotion strategy seems to be improving: AI is not mentioned in
| the article, but individual learning and meritocracy are
| dutifully devalued to fit the narrative.
| mclau157 wrote:
| Companies largely have terrible training and books of knowledge
| which leads to normal engineers not being able to do anything in
| an efficient manner. Unless they happen to ask a senior a
| specific tip (which seniors often take for granted and take no
| initiative to share) important knowledge could get lost forever
| JohnMakin wrote:
| > Any asshole can build an org where the most experienced,
| brilliant engineers in the world can build product and make
| progress. That is not hard. And putting all the spotlight on
| individual ability has a way of letting your leaders off the hook
| for doing their jobs. It is a HUGE competitive advantage if you
| can build sociotechnical systems where less experienced engineers
| can convert their effort and energy into product and business
| momentum.
|
| This hits close to home for me recently. I don't profess to be a
| 10x engineer, but I found myself on a team with a few people with
| much less experience and competence than I am normally accustomed
| to. I started getting _every single ticket_ with any kind of
| complexity, because I could get it done, and some people on my
| team couldn 't. I could have continued this way, contributing a
| massive percentage of the output and claimed to be superior to
| everyone - but the reality is, for me anyway, this is exhausting
| (and feels really unfair). Plus I am a little lazy (as I believe
| all good sysadmins/sre's/ops guys are). I _want_ my team to help
| me. So what I did was work extra for a few weeks and wrote a ton
| of abstractions over the most complex stuff we do (I dont write
| software, I write IAC, I 'm aware this is a common pattern in
| software engineering) so that the less knowledgeable engineers
| could do the work I'd been doing much of. It freed my time up to
| work on more interesting problems. This was the first time in my
| career I had to do this without anyone already ordering me to.
|
| I've been on teams where there was someone like me and everyone
| else was running around behind them frantically trying to keep up
| or cleaning up the inevitable tech debt that accumulates. It's
| miserable and really inefficient.
| alexandre_m wrote:
| > When your teams are used to operating with a mix of genders,
| racial backgrounds, identities, age ranges, family statuses,
| geographical locations, skill sets, etc -- when this is just
| table stakes, standard operating procedure -- you're better
| equipped to roll with it when life happens.
|
| Resilience doesn't come from having a "diverse" team on its own.
| What a shallow take.
|
| True resilience comes from mature teams with strong processes,
| clarity of roles, and the ability to adapt and recover
| effectively.
| zkmon wrote:
| At my company, I always prefer hiring average engineers with
| great attitude. Too many high-credential people with bad attitude
| were placed on high pedestals due to their perception-creating
| skills, and became immune to questioning. Once they bag that
| sweet perception from the boss, they also start bully around.
| Bosses would usually dismiss any data that goes against their
| perceptions. Mostly because going by perception is lot easier
| than looking into the data.
| tasuki wrote:
| > The smallest unit of software ownership and delivery is the
| engineering team. It doesn't matter how fast an individual
| engineer can write software, what matters is how fast the team
| can collectively write, test, review, ship, maintain, refactor,
| extend, architect, and revise the software that they own.
|
| Yes, and there are often teams of one. I am currently in such a
| team. Even though I work on a different problem than other
| "teams", I think it's reasonably easy to eyeball the relative
| productivity (not in my favour, in my current circumstances;
| though, to the credit of my superiors, they're being very patient
| with me).
| rebeccaskinner wrote:
| I've been lucky enough to work on a number of teams in my career
| that are full of brilliant high performing people who are also
| kind, empathetic, and focused working together to deliver
| something to customers. These days I'm lucky enough to lead a
| team like that.
|
| Counter to the article, in my experience these are the hardest
| teams to manage well because organizations typically aren't set
| up to deal with them. Larger companies tend to lean into
| standardization and making things accessible to average engineers
| in ways that make high performing teams less effective and often
| demotivated.
|
| I think this is an overly cynical approach that assumes that you
| can't invest and grow people into exceptional engineers. In my
| experience you can if you are willing to invest in it, and the
| long term benefit of having more high performing engineers who
| aren't being restricted from doing good work outweighs the cost
| of training and growing people.
___________________________________________________________________
(page generated 2025-06-19 23:01 UTC)