"They get up to building entire GraphQL monstrosities to avoid talking to each other."
I feel seen
Egoless Engineering
81–90 of 309 posts
Re: Egoless Engineering
#82Why I don't hear such discussions coming out of other engineering fields? Is this type of hamletization specific to software engineering?
Re: Egoless Engineering
#83Earlier quoted context omitted.
Where was the Musk bashing? I didn't see that in the slides.
I had to look pretty hard to find the Musk bashing - there's a (face redacted) photo of Musk carrying his sink around on the slide about narcissistic personality disorder.
Part of me wants to say "Using a picture of Taylor Swift when talking about successful recording artists wouldn't make anyone bat an eyelid. This was a discussion about narcissistic personality disorder..."
Re: Egoless Engineering
#84An 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…
The last paragraph is the interesting one, and here's the full quote in context: One of the reasons Communism eventually failed is that it assumed that we could all accept the philosophy "from each according to his ability, to each according to his need." The assumption that we could all subjugate our needs to those of others is about as faulty as the assumption that we can subjugate our egos for the betterment of th…
I actually like how the standing committee are the best capitalists of them all
S-Tier
I like it because its amusing and always gets a new generation of gullible people.
"hey, rent's pretty high, how about you all give the state all your property instead and I run the state until further notice"
Re: Egoless Engineering
#85An 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…
I'm not entirely convinced that ego-less is even a better way of doing things. Sure, the ego can go overboard but it also gives a sense of drive and direction. It isn't just the bad stuff. Without it, there's nobody taking ownership of the design or it's just designed by an apathetic committee.
Re: Egoless Engineering
#86Why I don't hear such discussions coming out of other engineering fields? Is this type of hamletization specific to software engineering?
Unlike other engineering fields, software engineering is more similar to being a writer, and that’s another field that has big egos. The work you put out directly speaks about your personal abilities and worth.
Re: Egoless Engineering
#87Earlier quoted context omitted.
Recently, I was thinking plenty about trust within organizations, and it resonated with me too. I've worked at a few startups and have seen high-trust environments lead to a lot of productivity, comfort and success— and the opposite for low-trust startups. In general, I think startups tend to lean towards high-trust, especially when they're small and early, but I was part of a 15-person one that was quite the opposit…
Yeah, I think there's almost always a point where a company decides they need to stop generally trusting their employees. Then all the trustworthy ones start getting more and more frustrated, or just start checking out. Agreed that most startups lean towards trust. Need to keep that going as long as possible, and stay away from hiring managers who think their primary job is "protecting" the company from anyone who mi…
Yes, and at the same time, companies start hiring employees that shouldn’t be trusted.
Neither one causes the other, both occur as companies mature. I’ve seen this as startups mature. One very vivid recollection: we had a very strong and tiny dev team. Each dev owned a huge piece of the product. Definitely not egoless. We brought in trusted junior devs to grow. That was fine.
Then the very talented VP Eng. wanted a promotion and brought in a hack to replace him, who hadn’t coded in years, and was obviously more concerned with his career than our product. A real mediocrity. But the VP wanted to move on, so this mediocrity was hired, over vigorous objections.
That was the end. This new VP brought in mediocre devs, rewarding loyalty and “being a team player” more than productivity, or competence. He brought in employees who couldn’t be trusted.
As this was happening, we were acquired, and our new bosses from the parent company were used to employees who couldn’t be trusted, and acted that way.
HR knew that to keep the good engineers they had to do something, so they showered us with bonuses. That worked for a while. I finally got so bored and fed up that I left (for another startup).
Re: Egoless Engineering
#88Definitely 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.
Re: Egoless Engineering
#89This is impossible without egoless software engineering managers.
Re: Egoless Engineering
#90Kind 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?