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

181–190 of 309 posts

Re: Egoless Engineering

#181

Post by cereal_cable »

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.

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 features isn't something I've seen done amazing. I'd like to work somewhere that could pull it off.

Re: Egoless Engineering

#182

Post by kookamamie »

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…

> Require ownership all the way to prod and beyond

Ideally this sounds great, practically it rarely happens in modern organizations.

Companies, and corporations especially, do not like the idea of engineers having personal ownership over things, as that makes them harder to replace, i.e. reduces the redundancy of the organization.

Re: Egoless Engineering

#183

Post by kookamamie »

oscillonoscope wrote: post #85
pjmorris wrote: post #45

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

You can never remove ego from the equation, completely. People are placed on different levels of organizations, with different incentives and agendas.

Thus, it's never a balanced setup where everyone's happily working towards a shared vision in equilibrium.

There's always someone having a larger incentive than the other person, overriding their decisions in a haste, in order to reach a bonus objective.

Welcome to the real World driven by capitalism.

Re: Egoless Engineering

#184

Post by worksonmymach »

motorest wrote: post #173
worksonmymach wrote: post #102

Earlier quoted context omitted.

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.

> "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 better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning.

Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.

Re: Egoless Engineering

#185

Post by worksonmymach »

cereal_cable wrote: post #181
worksonmymach wrote: post #102

Earlier quoted context omitted.

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.

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 the table for strategy.

Finally quality is about probabilities. That test you wrote that takes 12s to run and flakes 0.1% adding 10 hours of build time a year ... what is the probability of it detecting a bug and what would the cost of that bug be. You need every engineer to think of that stuff. It is hard stuff to get right or even good.

I worked at places where a religion almost builds. People are hired to maintain those slow expensive unreliable tests! You want to improve that you now have politics!

Re: Egoless Engineering

#186

Post by BerislavLopac »

throwaway2037 wrote: post #168
didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

> hire more engineers I was listening to a podcast with Joel Spolsky recently. He told a story that when he went to Microsoft, they had done internal research (and experiments) to debunk some of the theories from Fred Brooks' "Mythical Man Month". At the time, he generally believed in the "rules" from "Mythical Man Month", and was pleasantly surprised to learn about this further research. In short: Adding more develo…

Fred Brooks never said that adding more developers does not help -- he was stating that solving the single problem of being late will only be exacerbated by adding more people.

To use the infamous analogy that "nine women can't make a child in one month": it is still true, but if your goal is to have more children (as opposed to having one child be born sooner), adding more women would certainly help.

Re: Egoless Engineering

#187

Post by BerislavLopac »

sublinear wrote: post #177
didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

That these levers are the tool instead of mentoring and validating plans is an extremely strong signal these people should not be managing engineers. > Engineers have this lever of "technical ingenuity". LMAO this is not merely a lever. This is why you hired engineers.

I believe that the GP's point was that different roles have different tools in the box that are more efficient in their particular areas, and tend to rely on these rules even when solving problems in other areas.

It is very common to see engineers trying to solve non-engineering problems using the "technical ingenuity" to attempt resolving social issues; sometimes it works well enough (e.g. timezones), and sometimes it fails pretty miserably (e.g. OLPC).

Re: Egoless Engineering

#188

Post by brainzap »

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

Re: Egoless Engineering

#189

Post by mihaaly »

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…

Excellent points!

I wonder why these almost never considered.

Re: Egoless Engineering

#190

Post by noam_k »

didibus wrote: post #158

One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew…

I heard this phrase in college and it stuck: "when all you have in your toolbox is a hammer, every problem looks like a nail".
Post reply on HN