Live data from Hacker News

Egoless Engineering

egoless.engineering

191–200 of 309 posts

Re: Egoless Engineering

#191
post #9
post #3

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, e…

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

> 'modern team structures'

This kind of argumentation somehow never settles with me and blocks me from reading on. 'modern', 'new', 'trendy', 'state of the art', 'industry practice' and alike all resonate with 'I do not know so I mimic how others do' in my mind. Weird, but do.

Are 'modern' team structures a desirable reference?

How about saying 'today's problematic team formations'? I'll try to understand so and read on.

---

Edit: it turns out we are on the same page, I jumped at ghost.

Re: Egoless Engineering

#192
post #9

Earlier quoted context omitted.

With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.) The staff engineer ne…

I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.

I remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing.

I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm working on "irrelevant" tickets and not focusing on the wider project we were working on, the senior I was working under had the same stance, and the PR never ended up being merged. It was like 20 lines of very easy to comprehend code that was fixing one of the most reported bugs our users had, like 6 figure number of reports since the bug card was created.

When I left that company a year and a half later, that bug card was still open, with my now-rotting PR sitting there with a "closed" status.

It really jaded me on all of these bullshit processes, sprints, AGILE, whatever you want to call it. It was obvious that nobody gave a shit about what we were building and how, it's all just a game to pad yourself up and to look good to the higher ups who control if you get a raise or not. If someone above you can't somehow gain a lot by boasting about the work done, then you might as well not do it. I fucking despise the mindset and how prevalent it is in the industry.

Re: Egoless Engineering

#195

Earlier quoted context omitted.

I feel this so much. I feel like most of my job is playing politics to make sure people are happy and let them feel like they're adding value. Rather than shipping things to users to improve the product. It's honestly so depressing. Strongly considering going back to work at a small startup, to avoid having to work with these layers of middlemen that really add little to no value.

I remember in a prior job that I had just joined when I was still new to the field, they had a bug board where they collected all the most common bugs users were experiencing. I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm workin…

Healthy orgs must have slack in the system and allow teams and individuals to do a little chasing of fun or meaningful things that give them intrinsic pride and motivation.

Teams must advocate for projects, but, for individuals, one solution that I've seen help is that the week long oncall developer handles sprint interruptions, slack questions, and bugs. No sprint commitments. If something is not on fire, they get to work on whatever they think will add value at their discretion. New tooling, proof of concepts, pet-peeve bugs that can't get prioritized, etc.

After lots of stabilization work, devs looked forward to oncall.

Re: Egoless Engineering

#196
post #3

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, e…

> * 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. I feel like everybody needs to internalize this one (and that notably includes governments and politicians), but it's a really hard problem to solve. If something bad happened, people (whether that be higher-ups, journalists, lawyers or your constituents) expect you t…

Yea Germany quitting all nuclear comes to mind…

Re: Egoless Engineering

#197

Earlier quoted context omitted.

There is no mismatch, friend. "Pulling others in", as you put it, requires two ends of the leveling-up: first, the initiate explains how to begin the self-evolution, and second, the newcomer accepts the challenge and begins their own path to self-evolution. For those who invite, we are to do so with loving kindness, because the result is wholly dependent upon the receiver opening and then walking through the door we…

Thanks for the rebuttle. You are right, I stand corrected - I think both approaches make sense for spreading change. Yours on an every day basis, the viewpoint I gave requires opportunity, but matters too. The thing with game theory, is it’s the right way to think of social structures that scale. I think a lot of people’s behavior responds strongly to their incentives. All those people you (and I) are cynical about.…

Well said, my friend. Thank you very much.

Yes, changing incentives is the easiest way to provide a proper carrot to help people choose a better way.

And let's not forget that disincentivizing our leaders from being corrupt bastards is the proper use of the stick as well.

Re: Egoless Engineering

#198
post #144

Earlier quoted context omitted.

A difficult quest indeed, but not impossible. Sometimes teams like this do exist. You know the ones. They founded the trillion-dollar companies you hear about and became billionaires themselves

Nah, it's usually luck and robbing someone else work, windows apple Facebook etc

I'm going to say it is efficiency and the ability to implement ideas well, even if they are stolen ideas, that account for more of the success for anything else.

I also bet they did come up with some small things here and there themselves, in the process of implementing stolen ideas, because often things become apparent at the moment of implementation.

Re: Egoless Engineering

#199

"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 with ops and platform teams to come up with solutions instead of coding around it.

Re: Egoless Engineering

#200

Earlier quoted context omitted.

> * 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. I feel like everybody needs to internalize this one (and that notably includes governments and politicians), but it's a really hard problem to solve. If something bad happened, people (whether that be higher-ups, journalists, lawyers or your constituents) expect you t…

Yea Germany quitting all nuclear comes to mind…

I thought of that too, but also the US banning Kinder Surprise eggs.
Post reply on HN