In praise of “normal” engineers(charity.wtf)
charity.wtf
In praise of “normal” engineers
https://charity.wtf/2025/06/19/in-praise-of-normal-engineers/
119 comments
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.
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.
> 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.
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.
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
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
What you are describing is direct technical experience. That the banker did have, but the one titled as engineer didn't.
The purpose of the engineer is to add business value by either reducing costs or increasing revenue. You reward employees for results.
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.
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.
> 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.
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.
I said they lost their appreciation, not their obsession.
Furthermore, the art of the trade is not "pretty code"; it's a design and implementation that can last decades and not require a rewrite to accommodate new feature demands. There is a balance to be struck between business interests and legitimate engineering concerns around technical debt. And as we've gotten more of these MBA wunderkinds at software companies, the balance has swung very far toward the "Just get it out the door, engineers are just spoiled brats who are never happy with anything" end of the pendulum. Pretty much the entire attitude you espouse in your second paragraph.
You're not wrong that it's not the engineer's dime in terms of money. But it's also not the manager's dime on the technical debt credit card. Engineers have to make the trash solutions forced by their management work and scale for years. That doesn't show up on a quarterly report, but that doesn't mean it's free.
Furthermore, the art of the trade is not "pretty code"; it's a design and implementation that can last decades and not require a rewrite to accommodate new feature demands. There is a balance to be struck between business interests and legitimate engineering concerns around technical debt. And as we've gotten more of these MBA wunderkinds at software companies, the balance has swung very far toward the "Just get it out the door, engineers are just spoiled brats who are never happy with anything" end of the pendulum. Pretty much the entire attitude you espouse in your second paragraph.
You're not wrong that it's not the engineer's dime in terms of money. But it's also not the manager's dime on the technical debt credit card. Engineers have to make the trash solutions forced by their management work and scale for years. That doesn't show up on a quarterly report, but that doesn't mean it's free.
> it's a design and implementation that can last decades and not require a rewrite to accommodate new feature demands
When you're a start-up starting out to build your product, nobody knows what your product or the market will look like in two years, let alone in 10. YTOu might not exist in 2 years if the product isn't a hit, so there' no point in investing in robust codebase if you'll be broke by then.
Very, VERY few companies starting out have the luxury of having secured the funding, customers and the knowledge of knowing upfront what the future will look like in order to plan well from the start.
>Pretty much the entire attitude you espouse in your second paragraph.
It's not my mentality, I'm just telling you what the real world mentality is of those who pony up the cash. Then again, I'm in Europe, where VCs don't throw billions of ZIRP money at SW engineers, so nobody here values your "code quality" but your ability to push something out the door fast and cheap to multiply their investment ASAP.
When you're a start-up starting out to build your product, nobody knows what your product or the market will look like in two years, let alone in 10. YTOu might not exist in 2 years if the product isn't a hit, so there' no point in investing in robust codebase if you'll be broke by then.
Very, VERY few companies starting out have the luxury of having secured the funding, customers and the knowledge of knowing upfront what the future will look like in order to plan well from the start.
>Pretty much the entire attitude you espouse in your second paragraph.
It's not my mentality, I'm just telling you what the real world mentality is of those who pony up the cash. Then again, I'm in Europe, where VCs don't throw billions of ZIRP money at SW engineers, so nobody here values your "code quality" but your ability to push something out the door fast and cheap to multiply their investment ASAP.
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!
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!
>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.
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.
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.
> Who defines what "high quality code" is and who enforces it in a team?
An engineer who has appreciation for the art of the discipline. But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
An engineer who has appreciation for the art of the discipline. But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
>An engineer who has appreciation for the art of the discipline.
That' sounds incredibly vague and useless. The problem is always communicating to management the value add of such a position. If they see money gets made without it, than why bother? The customers don't complain so it's a slam dunk. And most companies are customer focused.
>But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
Like I said, the issue is budgets. Not every company is big-tech and can afford lavish salaries to attract SW shamans to bless your codebase with their appreciation for the craft. Most SW is a commodity, not an art. Some is, sure, but that's cherry-picking.
That' sounds incredibly vague and useless. The problem is always communicating to management the value add of such a position. If they see money gets made without it, than why bother? The customers don't complain so it's a slam dunk. And most companies are customer focused.
>But since you don't value that and think that engineer is a spoiled brat, you won't hire him.
Like I said, the issue is budgets. Not every company is big-tech and can afford lavish salaries to attract SW shamans to bless your codebase with their appreciation for the craft. Most SW is a commodity, not an art. Some is, sure, but that's cherry-picking.
> ... 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.
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.
>With engineers left behind to fix the mess.
There would be much less demand for jobs if there were no messes to fix.
There would be much less demand for jobs if there were no messes to fix.
Oh, certainly. In a world with far fewer failed software projects, it trivially follows that people would want far less software.
Not sure, what you're saying follows broken windows fallacy.
Good software might begat the need for more good and useful software.
Good software might begat the need for more good and useful software.
>Good software might begat the need for more good and useful software.
Where's the proof for that? And what do you define "good SW"? For the management, "good SW' is whatever makes money fast. It's business.
SW isn't like building chruches or bridges, something to last 100+ years, but something with an incredibly limited lifespan, that will have to be rewritten anyway, so why bother investing too much in "good SW" if "OK SW" will do the same job anyway?
Where's the proof for that? And what do you define "good SW"? For the management, "good SW' is whatever makes money fast. It's business.
SW isn't like building chruches or bridges, something to last 100+ years, but something with an incredibly limited lifespan, that will have to be rewritten anyway, so why bother investing too much in "good SW" if "OK SW" will do the same job anyway?
Open source is business?, and the hundreds of thousands of packages that have spawned from it?
>but something with an incredibly limited lifespan,
Oh hell, I found a js developer with their package du jour. Meanwhile in a lot of enterprise you work with software that is positively ancient.
>but something with an incredibly limited lifespan,
Oh hell, I found a js developer with their package du jour. Meanwhile in a lot of enterprise you work with software that is positively ancient.
Define "good" and see if the question still makes sense. If we define it to mean "fit for the purpose declared as its basis for funding," then either high-dollar-value fraud is so prevalent in this industry as to qualify it for comparison with Scientology and other MLMs, or the industry simply cannot be attempting in fact to do what it claims to be trying to do. Which might amount to the same.
For that matter, how do you know good software really doesn't last centuries? The practice of software's creation has yet to see its hundredth birthday. We have quite literally not had time to tell, and early results seem suggestive in really either direction.
For that matter, how do you know good software really doesn't last centuries? The practice of software's creation has yet to see its hundredth birthday. We have quite literally not had time to tell, and early results seem suggestive in really either direction.
That was the fallacy I sought to satirize, not too successfully, I think.
> 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.
Not necessarily. The problems rather are:
- Those who are mostly immune to this will hardly ever be put on a management track.
- Those who are resistent regarding this kind of infection won't make any further career in management (incentives matter).
Not necessarily. The problems rather are:
- Those who are mostly immune to this will hardly ever be put on a management track.
- Those who are resistent regarding this kind of infection won't make any further career in management (incentives matter).
just made this exact same point myself, lower in this thread. (author here)
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.
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.
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.
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.
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)
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.
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.
Ownership means you have real skin in the corp, your payout goes up or down, hopefully somewhat proportional to your hard work.
'Ownership' is taking on those same stresses and responsibilities without any of the potential pay-offs... or at best a marginal rounding error.
It's not surprising that few people want to work as a founder but get compensated like an employee.
'Ownership' is taking on those same stresses and responsibilities without any of the potential pay-offs... or at best a marginal rounding error.
It's not surprising that few people want to work as a founder but get compensated like an employee.
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.
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.
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.
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.
I think the cultures naturally change with scale. Is isn't a requirement, just a tendency. At least from my personal experiences, friends and read over the years this seems like a good general heuristic. I personally use it as a primary rule for job seeking, I ignore any company over ~500 people. Once they are bigger than that and their culture seems to start naturally evolving to the same stance of people being interchangeable cogs that have no worth as an individual. This naturally leads to team ownership as there is no one else.
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.
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.
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...
>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.
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.
[deleted]
that does work in smaller places, but there are many reasons and many books about exactly why this does not scale or work at most organizations.
> 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.
being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible
> 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.
being vague does not work when talking about organizational design so telling people that they don't need to build teams around systems is a bit irresponsible
i'm struggling to see how what you are saying you value is any different from what i am saying i value (author here).
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?
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?
> 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.
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.
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.
individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.
> 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.
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.
what if that one person quits suddenly because they're not getting paid enough, wants to move to a different country, etc?
> For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later.
feature not a bug etc. they should already have and know their priorities and if yours doesn't trump theirs, there's no reason you should get a concrete answer.
> For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later.
feature not a bug etc. they should already have and know their priorities and if yours doesn't trump theirs, there's no reason you should get a concrete answer.
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.
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.
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"
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"
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.
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.
It's extremely simple. Stop hiring/promoting into management who don't know the job. This is extremely common in every other industry, and I and legion of people will keep saying this.
It only seems like not a big deal while "good enough" is a really low bar.
It only seems like not a big deal while "good enough" is a really low bar.
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".
> 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".
> 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
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
> 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.)
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.)
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.
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.
There is more to choosing a job than money. No engineer likes being managed by incompetent assholes, and the best engineers also get to choose the best managers. And the bar for those is, sadly, quite low.
> 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.
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.
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.
Their brilliance may be in the way of finding the necessary compromises and doing the required but not intellectually challenging work.
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.
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.
You are thinking of Berkson's Paradox! [0]
[0] https://en.wikipedia.org/wiki/Berkson%27s_paradox
[0] https://en.wikipedia.org/wiki/Berkson%27s_paradox
I’ve seen plenty of assholes build long successful careers in tech without the brilliance.
ha! ok, i never thought of it quite like that.
>> 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.
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.
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.
“Impact on the business” isn’t inherently a short term viewpoint.
Maximum impact is a long term proposition.
Maximum impact is a long term proposition.
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.
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.
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.
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.
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.
ooh, good point.
You can build systems for efficiency, or build them to minimize disaster. It's really hard to see the negative impact on the business that was prevented.
You can build systems for efficiency, or build them to minimize disaster. It's really hard to see the negative impact on the business that was prevented.
The company should be constantly striving to better quantify the unknown.
idk, avoiding landmines seems like pretty significant business impact
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?
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?
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).
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).
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.
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.
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?
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?
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
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
A real genius can often explain their work without being an asshole, I think. So it’s fairly straightforward to tell the difference.
[deleted]
> 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.
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.
Most great engineers were once good engineers. A healthy engineering organization helps its engineers on this path.
yes! love this. and many great engineers will go back to being "good engineers" as they pick up new skills. rinse and repeat++
> 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.
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.
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.
> 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.
> 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?
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?
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.
> 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.
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.
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.
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.
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.
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.
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.
> Someone has to invent new tech from scratch.
uhm, as a research university or private company like a startup??
uhm, as a research university or private company like a startup??
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.
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.
> 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?
this seems like an insane statement to me, you can just hire for ability to function in a team?
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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!
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!
> 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.
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.
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.
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.
> 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).
Yep. I’ve been here for a career or so with moments of brilliance and marathons of mediocrity, but consistent kindness (I hope).
> 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).
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).
Discussion on the previous IEEE Spectrum 'version' a few months ago:
https://news.ycombinator.com/item?id=43356995
https://news.ycombinator.com/item?id=43356995
oh wow i missed that, thank you!
> 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.
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.
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
Great products are not build by normal engineers.
They are built by Linus Torvalds, Steve Wozniak, Larry/Sergey, Greg Brockman.
They are built by Linus Torvalds, Steve Wozniak, Larry/Sergey, Greg Brockman.
You spent all this time talking when you could have been coding.
[deleted]
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.
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.
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’.
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’.
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.
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.
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).
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).
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.
many fair points here <3
Fuck this. All engineers are normal engineers. Everyone can be an engineer.
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!)