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

251–260 of 309 posts

Re: Egoless Engineering

#251

Post by motorest »

whstl wrote: post #221
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?

False dichotomy. The point of the quote is to worry about not breaking the product. It's still possible to deliver features while keeping it working.

> False dichotomy.

Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead.

If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer your users more of the same. If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.

Time to market matters. A lot. There is no such thing as time to empty backlog.

Re: Egoless Engineering

#252

Post by jboggan »

I really liked the part about engineering committing to force multiplication of the other parts of the business. Once in a senior data engineering role I took it upon myself to just teach the PMs SQL and let them start running their own analyses, with regular weekly 1:1s and office hours. It totally wasn't my job but it saved me twice the hours I normally spent responding to their ad hoc requests, allowed some wild hairs to turn into actual profitable products, and hopefully stimulated some professional development.

Re: Egoless Engineering

#253

Post by smag »

default-kramer wrote: post #90

Kind of tangential, but: > Then one day, our designer broke the build in the middle of the night. Everyone came in the next day and couldn’t work until they figured out what had happened. I've heard this [campfire?] story before. A bad commit happens and now no one can do any work. And I don't understand... Is it really that big of a deal to have to revert to an older commit or comment out the broken code until it ge…

I actually saw this happen at Google: no one could pinpoint the cause of the broken build for a while, and then it turned out to be a UX designer who broke the build. He was apologetic, like McFunley's example. But unlike the example, this guy never made another commit.

Re: Egoless Engineering

#255

Post by agumonkey »

bryanrasmussen wrote: post #198
Vilian wrote: post #144

Earlier quoted context omitted.

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.

yeah there's always something a bit special in success, even if they took the idea, you can't just copy paste or you just produce shallow shiny stuff

Re: Egoless Engineering

#256

Post by jack_h »

motorest wrote: post #251
whstl wrote: post #221

Earlier quoted context omitted.

False dichotomy. The point of the quote is to worry about not breaking the product. It's still possible to deliver features while keeping it working.

> False dichotomy. Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead. If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer you…

> If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.

In the short term. Features can attract new customers but software that is frustrating to use due to a lot of low level bugs will repel existing customers towards competitors over the long term. If you've simultaneously decided tech debt isn't worth addressing then your competitor can easily overtake you. Furthermore adding feature after feature eventually leads to a kitchen sink product where potential customers are put off by the learning curve. This is really just a variation on the quantitative fallacy that ignores qualitative aspects.

Re: Egoless Engineering

#257

Post by mewse-hn »

euroderf wrote: post #180

OT: What is this presentation format called - slides on left, text on right ? Are there any dead simple tools to optimise making them ?

It's basically a powerpoint presentation. The slides are projected to the audience and you have a field for the presenter's notes. Any powerpoint style software should be able to do this.

In this particular case, there's a link at the bottom of the page, the guy used his own keynote-export tool to turn his Keynote presentation into a web page (Keynote is apple's powerpoint-like software):

https://github.com/mcfunley/better-keynote-export

Re: Egoless Engineering

#258

Post by HL33tibCe7 »

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

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…

> one staff engineer, one or more lead engineers

An engineer isn't really a "lead" if there are multiple, or if they are outranked by a "staff engineer".

Re: Egoless Engineering

#259

Post by jacobsenscott »

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…

The main thing a good manager can do is act as a wall between the engineers and everyone above them, which is hard to do politically because it exposes a whole subtree of the org chart as useless.

Re: Egoless Engineering

#260

Post by Conscat »

> I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while.

My mom gave me Hackers & Painters when I was 13 or so, but I still haven't read it. What about it turns children into jerks?

Post reply on HN