"They get up to building entire GraphQL monstrosities to avoid talking to each other." I feel seen
On the other hand, people can't possibly talk to each other if they are always in a meeting.
Egoless Engineering
231–240 of 309 posts
Re: Egoless Engineering
#232Why I don't hear such discussions coming out of other engineering fields? Is this type of hamletization specific to software engineering?
Perhaps because you are not in tune with the goings on of other engineering fields? I don't know what the Hacker News of civil engineering is, but it is likely you will find similar discussions happening there.
Re: Egoless Engineering
#233In 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.
Re: Egoless Engineering
#234"Like many of you, I was raised in the background radiation of Calivinist thought" Sorry -- you lost me in the first sentence.
That's fair, but if it makes you at all curious to learn what he means, you night find it rings true - if not for you, certainly people you know. https://en.m.wikipedia.org/wiki/Protestant_work_ethic
I feel like the concept of "protestant work ethic" has been coming up a lot lately. Make me wonder if this is going to be the stoicism of 2025.
Re: Egoless Engineering
#235Earlier quoted context omitted.
If you were the benevolent dictator of a small engineering with no stakeholders to answer to how would you fix this? How would you make ownership all the way to prod a reality and who would the owner be?
There should not necessarily be an owner, but a responsible individual - which would then be "you", the benevolent dictator. Ownership "in and of itself" creates incentives to gatekeep.
Why did I hire these people if I cannot delegate responsibility to them?
Re: Egoless Engineering
#236"They get up to building entire GraphQL monstrosities to avoid talking to each other." I feel seen
The weird balancing of plates I have seen developers do to not talk to each other amazes me. I often have to remind frontend that we are on the same team as backend and we own the technology: if we need an api to behave differently, let's make that happen, not code around it. Similarly, I have to tell the backend team that the things they find frustrating can be automated, processes can be changed, and we can talk wi…
Yes, but when you do manage to get people to "say what they mean" I had the following response from a frontend bloke (me being on the "backend" side, even though I never refused to work on frontend per se): "I don't like you and I don't like your stack, I want to make decisions regarding frontend without consulting with anyone, I want to get promoted for running a team which overcomes any hindrances related to either how the product actually works or that human collaboration requires communication."
It is not about "nog being able to collaborate" - it is about refusing to do so.
Re: Egoless Engineering
#237From 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
Re: Egoless Engineering
#238Earlier quoted context omitted.
Quality can also become it's own trap as the entire org chases metrics aimed at quality. Soon you have loads of brittle tests that likely aren't adding great assertions but you have code coverage. Because that doesn't work soon you keep adding layers upon layers to reduce the risk and your time to delivery suffers. All knobs have consequences and long term they can really compound. The balance of picking quality over…
You are right and the biggest asset here are executives and management that can: 1. Think 2. Know what is going on. 3. Effectively get the best from their people. You want the whole org to engineer the right solution Any metric that gets abused needs to be found and replaced. Companies should use metrics and be very respectful, curious and also suspicious of them. Even revenue! I know companies that leave revenue on…
How do you build 1 and 2? It seems so simple: talk relentlessly about what you’re trying to do as a company, and then figure out how to assign your people most effectively to do that. I’ve seen a number of leaders figure out the messaging and then flat out fail on execution. Once they’ve worked out the vision, they fail to give middle management enough latitude to accomplish it, and the lack of trust flows downhill.
Re: Egoless Engineering
#239Part 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…
I find "ego" to be really interesting — on the one hand you want high-ego: confidence to try things, strong sense of mission — and on the other hand you want low-ego: selfless giving, able to let go of ideas that aren't working. Are those egos the same thing? I really don't know.
Re: Egoless Engineering
#240The 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!
I've encountered people who sincerely dislike talk of "values", and I think it's because they have seen them used as a flog rather than an inspiration. My guess is that there was a leader in their past who set values but didn't actually follow them. "We dig ditches" means "everybody but me digs ditches". It's hard to be both technically and morally capable, but I think that's what leadership requires.
So an approach might be to set only the values you can actually follow through on, and be clear when a value is aspirational. If you really do dig ditches (perhaps metaphorically, maybe by fixing deployment script bugs or something), then you can use it as a value.
To be clear: I'm definitely in favor of team values. Is there a way to make them achievable, but also grow them over time as you get better at them?