Egoless Engineering
egoless.engineering
Egoless Engineering
1–10 of 309 posts
Re: Egoless Engineering
#2The 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!
Re: Egoless Engineering
#3Really 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.
Re: Egoless Engineering
#4Random 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.
Re: Egoless Engineering
#5good guide for allowing everyone to walk all over you
Re: Egoless Engineering
#6good guide for allowing everyone to walk all over you
If you're a manager, you put this stuff in place in-part so that everyone understands that you will be watching for attempts to walk all over others.
Re: Egoless Engineering
#7good guide for allowing everyone to walk all over you
Work is not a zero sum game, sometimes, everyone can win.
Re: Egoless Engineering
#8This 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"
Re: Egoless Engineering
#9Really 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 needs to validate any design (that’s his job), and provide feedback if he thinks your design “sucks”. So if the feature ends up being successful, he gets points.
The senior and lead engineers need to own the design and implementation details. The leads would probably want to cover a good chunk of the solution so that it appears in their performance review. It’s gonna be though for senior engineers to get a good share if the leads are already one step ahead.
The engineering manager will own the timeline. He will ask you about estimates, but most likely you’ll feel the pressure of whatever imaginary deadline is set.
So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard.
I have to say, though, that I only have experienced this in tech companies that are around 5-7 years (old enough to have well established processes, young enough to still hire like there’s no tomorrow) and that are obsessed with FAANGs: they will hire faang engineers only if they could. This mix ends up badly, because suddenly every team needs to be a high performing team, everyone is raising the bar and speed is number one prio. When working with companies that hire no faang engineers, everything feels better.
Re: Egoless Engineering
#10Really 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…
[flagged]