One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse.
A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew towards it for many problems...
We want to deliver features faster, what can I do, me, a manager?
- I could hire more engineers!
- I could reorganize my engineers so each one works on a specific type of issue
I'm picking at managers, but every role has this issue. Engineers have this lever of "technical ingenuity". And they skew to it as the solution to all problems.
We want to deliver features faster, what can I do, me, a software engineer?
- I could rewrite this in a more productive language/framework
- I could redesign this to make it simpler and easier to work onAn ageless idea...
"There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building.
...
What’s the alternative to an ego-invested programmer? A team-player programmer.
The team player sees the software product as a team effort and a team achievement. Error reports and reviews and questions become team inputs to help improve the product, not threatening attacks to derail progress.
...
But after further thought, this notion begins to unravel. It is all well and good to advocate egoless programming, but the fact of the matter is that human ego is a very natural thing, and it is difficult to find people who can—or even should—divorce their ego from their work.
...
A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.
"
- 'Facts and Fallacies of Software Engineering', Robert Glass, 2002Kiva's engineering drew quite a few lessons from Etsy, though we never got so big.
I think Dan is missing mentioning one ingredient: Security.
Not code security, the human feeling of personal security. Most especially, of being secure in one's role.
And that drives so much of this. If everyone is secure in themselves, or able to transcend worrying about their personal security, then magic happens.
Without it, things will inevitably wander back to gatekeeping, control, and conflict. Much as in the world at large.
The success of any organization depends upon each member behaving selflessly to meet the needs of the group. Selfishness in any organization is a parasitic drain on energy and productivity.
Embracing compassion for all those who drift into our orbit is the only way to improve oneself in all dimensions. Compassion is the common factor in virtue, and the cure for selfishness.
It is also the measure of every person, so once you begin orienting yourself in the moral compass' proper direction, you can begin to see how others are aligned or misaligned. Such selfish folks are those who just don't give a damn to become a better person, which would result in lessening the amount of hurt they inflict on others. Treat such people as well as you can, but be wary of their nature.
Unfortunately, very few human beings really give a damn about anyone not in their in-group. Such is our baseline mammalian heritage, which we must each overcome with deliberate spiritual self-evolution.
"The Way goes in." --Rumi
I joined my current company to work on Growth. I was added to Gitlab, and for the first 3 months I pushed all my commits as MRs that my manager reviewed and merged into main. Standard procedure.
One day I needed to get a hotfix out to prod STAT. I pinged my manager to accept the MR and explained all the testing I've done. He said I could just accept it myself if I wanted it up now.
Turns out I've had the permission to push to prod since day one. The only red tape I had to cross was my own confidence.
Definitely agree that domain experts are preferable to domain owners, and that overly explicit specialization causes problems, but at the same time I think it's quite possible to stray too far in this direction too, and that the author didn't really address that.
The problem is not just that the Designer might Break the Build or ship something broken one time (but know how to fix it). The problem is that stuff can (obviously, not in all cases, and not something you should just assume will happen without good evidence/reasoning) start breaking all the time because you have too many people changing things that interact with other things they only partially understand. Or it's that one team/"domain" ends up downstream or dependent on another, and locally optimal but globally suboptimal decisions made upstream (eg a bad but quick to implement data model, or adding more dependencies on something you're in the process of getting rid of) cause problems downstream. In these situations your "egoless domain experts" might actually need the authority to force these things to stop, or might get burnt out spending all their time firefighting or playing hero.
There are also some kinds of engineering mistakes that are literally business-killing, like major security breaches/data loss. Mandatory code review isn't a "feel-bad program", it's precisely to guard against disasters like this (also I'm pretty sure it's literally required by SOX/SOC2 and I'd certainly want my software vendors to implement this).
That's why I think this is actually a balancing exercise that is highly case dependent, not something you can merely say "just empower people we're all on the same team". If your team is highly skilled, conscientious, and motivated you can give people a lot of autonomy - if they're mostly unskilled and don't give a fuck about the quality of their work, you can't give them much autonomy. If the scope of what you're working on is huge (so huge that any one person can only have a working understanding of a small part of the whole) you probably do need more process and guardails in place than a smaller project.
Ok, but how do you deal with people that submit broken CSS, break the site, and are unapologetic? Especially when you are in no position to fire them (because laws, or organisation)?
All these “if you do it this way it works” posts seem to assume everyone has the best of intentions (or at least want to do the best job possible), and especially in corporate settings I just don’t think that’s always the case. People are just there for a paycheck and to divert any possible responsibility away from themselves…
This is great! The best teams I've worked on have worked towards the following:
Pizza teams that own the whole stack, and for the roles that don't need a full-time individual, specialists that come in and advise but also make it possible to DIY the things they do.
The best examples of specialists are Designers and Security teams as this talk highlights. They can make the tools and the means for other teams to self-service those needs. For example, security teams implementing CI tools and designers building design frameworks that are easy to apply. Conversely, they can feel free to make changes themselves and are empowered to at the best organizations.
Everyone else in product development is a generalist, including the managers, and everyone is on-call. When everyone is on-call then it results in far fewer alerts going off because when there is an issue, it's taken very seriously and remediated quickly in the following days & weeks.
I think GTM teams could also benefit from this same kind of process, but instead melding Marketing, Sales and Support roles and responsibilities.
My theory on why this wasn't more common in the past was that the work was too complex and specialized and that the tools and knowledge to do the job weren't as easy to acquire as it is today. LLMs have certainly leveled the playing field immensely in this area and I'm truly excited to see the future of work myself.
Part of me wants to say that it's best to work in a 'low-ego' environment as opposed to a 'high-ego' one - or to avoid working with people who have 'huge egos'... but I honesty find any discussion about 'egos' relatively devoid of meaning. As someone else said, it's difficult to find people who work without ego (whatever working without ego would mean). Most of my professional experience is as a working musician, and it goes without saying that artists have egos, in the sense that they try to bring something from their inner selves to the outer world, and that they invest a lot of effort in learning how to do so properly. Sometimes I've felt that the best musicians I've worked with were "low ego" but this could be just that they are supremely confident and also not lacking in affirmation from their audiences - and if they are kind, from their fellow musicians. The worst people I've worked with are talented people who can't seem to find the affirmation they crave, but feel they deserve. They feel constantly slighted and left behind. As a band leader, I realized I simply have to stroke these people's egos - no matter how confident, skilled, or amazing some people seem they are riddled with self doubt and absolutely need outside affirmation. I used to fight it, but eventually learned it was my job as a manager of sorts to do so...
The part about intentional team values is very good:
• Digs ditches. Nobody is too good for any task. • Returns shopping carts (even if nobody's watching). We leave things better than we found them.
It's amazing how most teams don't set norms/values at all!
Sports metaphors are a bit unpopular in tech, but the teams that win championships in sports have exactly the same dynamics as a good business team and we should be taking a lot more from that school of thought.
There's an old rachelbythebay post that's relevant here: https://rachelbythebay.com/w/2018/03/21/next/
I think it was about the blue company that's tried to pivot to the metaverse?
The gist of the post is that managers started to actively discourage looking outside of their little walled garden, to the point of people getting bad performance reviews for building bridges to elsewhere.
"They get up to building entire GraphQL monstrosities to avoid talking to each other."
I feel seen
I really liked the part about engineering committing to force multiplication of the other parts of the business. Once in a senior data engineering role I took it upon myself to just teach the PMs SQL and let them start running their own analyses, with regular weekly 1:1s and office hours. It totally wasn't my job but it saved me twice the hours I normally spent responding to their ad hoc requests, allowed some wild hairs to turn into actual profitable products, and hopefully stimulated some professional development.
Most of the issue exemplified in the article arise due to a lack of domain expertise, not ego. Parochialism, maybe, as it relates to lack of expertise. We fear what we do not understand, which translates into domain ownership and controls over guardrails.
The productivity of every single team that I've been apart of, that shipped fast, was enabled through permission, by highly experienced domain experts who knew how to build guardrails instead of controls. Canary releases, monitoring and rollbacks, not release managers. Automated testing, not codeowners.
Controls prohibit actors from doing certain things. Outside of regulated environments, they should only exist at the perimeter of your business, interfering in the nefarious activities of malicious external actors.
Guardrails on the other hand, guide actors in the right direction. Well installed guardrails can see your legal team pushing changes to your API schemas.
Those guardrails however take real expertise to install.
Was an interesting discussion, but lost me with the sort of pointless Musk bashing near the end.
I remember back in the late 90's and early 2000's it was similarly cool to bash anything related to Microsoft.
I spent a good bit of time writing a lengthy comment on slashdot about "Why to code". It was fairly poignant and well-received, except at the end of it I took a low effort pot-shot at Microsoft - because it was cool to do at the time.
Someone replied and (rightly) called me out on it. Why muddle an otherwise interesting talk / piece with a cheap, drive-by swipe?
That was nearly twenty years ago, but let's call this comment me paying it back (if the author reads HN).
> So that was a high-level overview of how all struggling companies are unique. But they’re also all the same.
Reminds me of Tolstoy's “Happy families are all alike; every unhappy family is unhappy in its own way.”
Kind of tangential, but:
> Then one day, our designer broke the build in the middle of the night. Everyone came in the next day and couldn’t work until they figured out what had happened.
I've heard this [campfire?] story before. A bad commit happens and now no one can do any work. And I don't understand... Is it really that big of a deal to have to revert to an older commit or comment out the broken code until it gets resolved? Sure, I can see it being annoying, but not bringing an entire group of developers to a standstill. What am I missing?
This really hits
> Computer Scientists are also really bad at it
> Despite literally studying the asymptotic limits of work completion under various conditions
There are so many times that I'm looking at the workflow thinking "We know how to break this up using distributed systems knowledge, why are we doing it this crazed way"
I like his other two talks better than this one.
I find "this worked for me once at Etsy when we were a 20 person team" not a very convincing argument. That does not mean I think he's wrong. Just that the conclusion needs better arguments.
One argument that comes to mind is: If you treat people like children, they will start behaving like children. Treat people as adults if you want them to shoulder responsibility.
The main message of this talk is that when a designer tried to deploy a fix into production and it blew up production, they realized he had the wrong kind of permissions and their solution was to give him full deployment permissions.
Well, great if that worked for you. It might or might not work for others.
I would recommend not letting anybody deploy to production. You can deploy to staging, then tests are run, and only after those all pass can anyone deploy to production.
Also, the current process is not just the result of ego. It is also the result of evolution. We usually take steps to prevent things from happening because they have blown up in the past and we would like to not have that happen again.
Oversimplifying warning:
Must of the problems described here come from a cultural setup that you can't tell or even suggest your managers that they are stupid and/or someone above them is even more stupid.
I noticed that this is especially painful in the US companies, we in Europe seem to be much more lucky with telling people that they do stupid sh*t and not lose the job after telling that. But YMMV
Really goes to show how the whole "I have the hardest job in the company and all y'all are just morons" attitude really needs to die.
This is incredibly good, and reflects most of the things I have bumped into that made me miserable. One of the takeaways for me (which transpired where I am now) is "to do devops properly, do not have, hire or designate dedicated ops people". It works exactly like it should.
I want to go off a small tangent
> In Theory There Is No Difference Between Theory and Practice, While In Practice There Is
I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team. I still believe it somewhat but my ego is shattered.
I worked on one team where the lead believed in this more than I ever did. Consequently, I was doing tasks I sucked at and therefore didn't enjoy s lot more because as she said, it will help me improve.
Long story short, I didn't improve. I just got frustrated and I quit. I guess it was all fine from the leader's perspective as her team stayed the way she wanted anyway.
I went down this tangent to remind people that when things are going well, we can say a lot of things that are nice like kumbaya my lord but when things are tough is when our ideals and morals are actually put to the test.
When poop hits the fan, will leadership throw someone under the bus? Will team members feel like leadership will throw people under the bus? Kind of a difficult question that we can't answer until we are there and at that point it is too late.
"Like many of you, I was raised in the background radiation of Calivinist thought"
Sorry -- you lost me in the first sentence.
Egoless engineering is such a great mindset—focusing on team goals over individual credit really makes collaboration smoother and ideas stronger. It’s amazing how much better things get when everyone’s just working toward the best solution, not personal recognition. Definitely something more teams should embrace!
I spent so much time at my last job trying to implement this with so much resistance. I felt so insane for getting resistance I ended up becoming a jerk and hated who I was. The worst part was because I was so good at what I did people started trying to protect me from getting angry. That made me even more angry and jerky. I hope I will be forgiven, I hope I can become better.
I like the idea but it’s something that must be implemented from the top.
How does something like this scale for more than 10 people? 100? 1000?
Random comment: slide 10 talks about using Twisted and then adding a twisted middle layer. 2010 me (or earlier) liked Twisted a ton but not sure I would have foisted this technology on a development team. As a single dev doing all kinds of crazy shit it (sort of) worked but was pretty hard to debug or understand.
It makes sense, but I wonder if it's something most people feel it should be like, but the reason it's not is that it's not possible. I switched jobs recently looking for something like this, but still haven't found it. Now I know the argument of the article is that it worked in one place, but maybe this was just lightning in a bottle of same minded people coming together. So maybe the answer to the problem is that it doesn't take a large number of extremely ego driven people to mess everything up. I say extremely because I think to an extent everyone has one.
But it made my heart warm that someone used Amdahl's law and applied it to people. It's how I've felt for a long time, and why I value communication but kept at a minimum.
The section on Deriving the Equation for a Disaster is perfect.
After being acquired (~80 person startup) we were part of 1000 person org.
As the CTO of the acquired company, coming into a larger org, I was front row to this type of infighting.
Especially when the CPO wants direct ROI, and less worried about creating compound value.
Is there a video of the talk somewhere ?
I prefer recording over slides.
> I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while.
My mom gave me Hackers & Painters when I was 13 or so, but I still haven't read it. What about it turns children into jerks?
This completely disregards the methods that brought us the most successful software ever written, which we all rely upon and which the world rely upon to function.
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
The points do "soften up" but it starts with this, at number one:
1. Every good work of software starts by scratching a developer's personal itch.
> "We are living in the age of narcissistic personality disorder"
With a picture of the man who revolutionized EV vehicles, worldwide. Who created a company that sends rockets into spaces and then... freaking catches the booster down to the centimeter with giant chopsticks... And who created StarLink. And all this in record time.
If he considers Musk has narcissistic personality disorder then the world needs way more of those people.
How can seriously write about methodology and criticize the one person (if there's only one to pick) who has a proven track record showing he masters efficiency?
And I can tell you, for sure, a type of place where I go and see a lot of soul-crushed, egoless, people: public servants in inefficient public administrations.
It must be hard for egoless people to live in a world created by people with incredibly strong egos.
Linus and Theo de Raadt certainly comes to mind. And we all use and depend on the work of these people.
At some point when you see crap, you have to take a stand. Be it when you find crap at work or be it when you read crap online.
This is impossible without egoless software engineering managers.
OT: What is this presentation format called - slides on left, text on right ? Are there any dead simple tools to optimise making them ?
I always check the ego at the door, but have a high threshold for persuasion if I've done due diligence.
From the title, I wanted to dislike this, but Dan McKinley drops another banger slide.
Giving people the keys to the car is both 1. how you make a happy person and 2. build systems that understand and operate with the bigger picture
There are a lot of big egos in team sports, and in high performing teams you often have a team full of big egos, although there are usually a few "team players". I wonder what coaches think about ego.
In my opinion very little of this has anything inherently to do with development, but organization science in general. All these problems exist is every org corporate or otherwise.
Why I don't hear such discussions coming out of other engineering fields? Is this type of hamletization specific to software engineering?
I don't think engineers (especially non-managers) talk or write nearly enough about personality dynamics at the workplace.
Slides 25-26 filled me with hollow, empty laughter.
we don't have that problem where I am now, but we should teach queueing theory in middle school.
hahaha they gave the designer keys… to deploy to prod!
as a lead engineer this is something I don’t even want… as soon as you have keys to deploy to prod, guess what you’ll be asked to do? and always at the worst times!
the opposite of an egoistic programmer, is the anonymous one.
then how do you credit those who do produce results? Just put money into the anonymous one's bank account.
Those Galadriel memes had me in tears :')
I did not finish yet to read, but
"Executives are well-adapted to insisting on fundamentally contradictory goals"
Is so well worded (and also so hilariously true) that I wanted to symbolically tip my hat at the author in case they read here.
I mean, these seem like good passwords at least.
"How do we tear down parochialism and ego?"
First, by not writing rambling, pretentious, navel-gazing, ignorant powerpoints. This would be amazing if it were satire.
The stab at Musk seems out of place. You might not like him, or his politics, but he took over and reformed a slow and bloated place, and despite all the doomsayers Twitter is still working and IMO better than before. And he has a solid track record of delivering: finance app, electric cars, rockets. Sure he over-promises and under-delivers, sometimes borderline lies, etc. but there is a huge amount of wisdom behind what he's doing, and you're doing yourself a huge disservice by just dismissing one of the most successful technical entrepreneur of our times.
good guide for allowing everyone to walk all over you
Lots of people in the comments exemplifying why I would never want to work with them.
Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly:
* Don't add process just for the sake of it. Only add it if seriously needed.
* Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)
* Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.
* Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)
* Never forget your team is full of actual humans.