Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Egoless Engineering

egoless.engineering

Post reply on HN
Print view View original

241–250 of 309 posts

Re: Egoless Engineering

#241

Post by YetAnotherNick »

worksonmymach wrote: post #102
dakiol wrote: 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…

It needs a culture change. The magic words: "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Number of features is a dial. You turn that down. You turn the operations (devops) dial up. There is nothing modern about releasing half arsed shit... we been doing it since the dawn of civilization.

I have never seen positive impact from turning the devops dial up. Most of the times, we just keep on adding checklist items for quality and engineering practices. Devops keeps pushing things like observability and standardization through complex things like service mesh which creates all of its own problems.

Re: Egoless Engineering

#242

Post by alkonaut »

brainzap wrote: post #188
Aeolun wrote: post #161

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 ar…

you fire them

That takes months or years if it's possible at all (at least in many places). For any place where you can neither fire bad devs nor find very good ones to replace them with, the trick is to make good processes and products using mediocre people. And that's hard. But that's also why a lot of processes appear, that would seem unnecessary to someone who is a good engineer and used to working only with good engineers.

Re: Egoless Engineering

#243

Post by RHSman2 »

theropost wrote: post #224
spuds wrote: 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…

I completely agree. I’ve had the privilege of working with a very small team of engineers—a team with diverse life experiences and unique areas of expertise but a shared work ethic: the willingness to try. We always said that most of our time was spent failing, and that’s what made the moments of success so rewarding. When we finally succeeded, it wasn’t just about the victory; it was the culmination of relentless ef…

I think there are ways of philosophy not process. And the philosophy has to be agile to those in it.

Re: Egoless Engineering

#244

Post by evantbyrne »

weitendorf wrote: post #88

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 (o…

Yeah you really can't go this hands-off on deployments when the stakes are high. If someone could be physically harmed by bad code, then it all needs to be reviewed. If you can be hacked by a rouge deployment, then it all needs to be reviewed.

And more generally, it is not fun using a lot of mainstream software these days because it is a buggy mess, and I believe a lot of that dysfunction is partially related to the low standards for correctness that development teams have.

Re: Egoless Engineering

#245

Post by mattcaldwell »

lijok wrote: post #21
mattcaldwell wrote: post #14

Lots of people in the comments exemplifying why I would never want to work with them.

There is currently literally 1 comment disagreeing with some of the points in the article. Are you saying you wouldn't want to work with anyone that agrees with the points in the article? If so, it would be interesting to hear your thoughts.

I'm saying the opposite. There are several comments that demonstrate an insecure "dog eat dog" mentality.

Re: Egoless Engineering

#246

Post by kazinator »

spuds wrote: 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…

The Process Person who wants to build a Mature software organization will say, process is seriously needed.

Re: Egoless Engineering

#247

Post by fatnoah »

sethammons wrote: post #195
sensanaty wrote: post #192

Earlier quoted context omitted.

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 t…

> 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.

As an Engineering leader, I try my hardest to make sure this Slack exists for the exact reasons you listed.

Re: Egoless Engineering

#248

Post by pphysch »

aylmao wrote: post #53
pphysch wrote: post #50

Earlier quoted context omitted.

> 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. Ironically, it's the "egoless" crowd which tends to be ego-obsessed and solipsistic. They imagine an egoless world which simply requires that everyone thinks just like me; in effect, everyone shares…

Claiming that the "egoless" crowd is egotistic, because "they want everyone to think like them" is like claiming the "tolerance" crowd is intolerant, because "they don't tolerate intolerance". In my experience, It's both non-factual (ego-less people are the first to learn from others when poised with new ideas) and short-sighted.

There's a manifest difference between people who are naturally humble+curious, and people who are idealistically seeking an "egoless" environment. The latter is what I am referring to.

Now that you mention it, there are parallels with the "tolerance" ideologues. There are people who are naturally patient and empathetic, and then there are people who opportunistically pursue the in-vogue virtue of "tolerance", and end up practicing de facto intolerance in the process. Don't conflate the two.

Re: Egoless Engineering

#249

Post by pphysch »

bithive123 wrote: post #57
pphysch wrote: post #50

Earlier quoted context omitted.

> 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. Ironically, it's the "egoless" crowd which tends to be ego-obsessed and solipsistic. They imagine an egoless world which simply requires that everyone thinks just like me; in effect, everyone shares…

How predictable the ego's self-defensive reactions are. Merely encountering the suggestion that the ego is a necessary servant but a terrible master and it yelps "I'm not an egotist, you're the egotist!"

Which character is this referring to?

Re: Egoless Engineering

#250

Post by motorest »

worksonmymach wrote: post #184
motorest wrote: post #173

Earlier quoted context omitted.

> "Our customers prefer the product works over getting a new feature, so let's ensure that at any cost" Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?

> If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd bette…

> A feature that drags people over is really a new product.

But isn't that a post-facto observation? I mean, any project can work on a complex feature that's a flop, but sometimes a simple feature can go a long way and just tilt the scale. That's not a new product.

Post reply on HN