Live data from Hacker News

Egoless Engineering

egoless.engineering

221–230 of 309 posts

Re: Egoless Engineering

#221

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?

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.

Re: Egoless Engineering

#222
post #175

Earlier quoted context omitted.

The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions. The specific example is of a rare event which, while regrettable, does not justify the cost of policy changes to prevent it.

> The context of "stop making reactive decisions" isn't "start making proactive decisions." It's to just make fewer decisions. You don't get the luxury of not making decisions. You always have to make decisions.

If you do not consider the problem at all, you have not made a decision on it; any more than you have to make a decision about, say, the most aesthetically pleasing perspective of Olympus Mons for prospective Martian colonists.

The actual point stands, either way: Whether you do not make a decision, or you decide not to act, the outcome is the same--and it is often a better outcome than the result of reactive or proactive decision-making.

Re: Egoless Engineering

#223

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 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. Why do you feel your way of shipping things to users to improve the product is something that makes your team members unhappy and not able to add value?

[dead]

Re: Egoless Engineering

#224
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 effort that allowed us to push forward, improve our product, and refine our ideas.

Our approach was unique. We engaged directly with the people who did the work, learning from their insights and challenges, and built tools specifically for them. It wasn’t an Agile team or a Waterfall approach, or any other rigid corporate framework. It was an ad hoc team that came together organically to solve problems—and solved them faster than large corporations, consultants, or armies of workers ever could.

With just four people, we scaled applications, built automation systems, and tackled complex problems that delivered multi-million-dollar savings across the board. The process was simple: no micromanagement, no unnecessary oversight. Everyone contributed based on what made sense, and we all collaborated freely to solve problems as they arose, moving seamlessly from one challenge to the next. It was innovation through cohesion—a kind of synergy that can’t be forced or replicated through standard processes. It’s the magic of the right people, in the right place, at the right time.

Over the years, the tools we developed have grown into critical applications used by professional organizations, with over 3,000 users relying on them daily to make their work hundreds of percent faster. Yet, when these tools are handed over to large organizations for "modernization" or "corporatization," they often end up spending exorbitant amounts of money, adding no meaningful features, and making the tools less effective. Teams of 30 people fail to replicate what our small team accomplished. It’s a strange and frustrating reality.

I’ve tried to find ways to replicate this success, but I think it comes down to that intangible element—a “ragtag team” dynamic where the right people come together with a shared drive and passion. It’s rare, and perhaps it doesn’t exist as it once did. Maybe it’s out there, but we need to find ways to enable and foster it.

Re: Egoless Engineering

#226

"Like many of you, I was raised in the background radiation of Calivinist thought" Sorry -- you lost me in the first sentence.

That's fair, but if it makes you at all curious to learn what he means, you night find it rings true - if not for you, certainly people you know.

https://en.m.wikipedia.org/wiki/Protestant_work_ethic

Re: Egoless Engineering

#227

"Like many of you, I was raised in the background radiation of Calivinist thought" Sorry -- you lost me in the first sentence.

also: "I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while. This talk is about how despite this, I got better."

I've read H&P and a bunch of PG's essays. Unsure what conflict exists btw Graham's writings and the content of this guy's powerpoint essay.

Re: Egoless Engineering

#228
post #213
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…

> Resist the urge to build walls between people/teams/departments Do you often have to deal with support staff reaching out directly to developers on Slack to investigate some problem – without going through "normal" process of creating a ticket that gets assigned? Or even asking for features. Developers generally want to be helpful, but also small requests often turn out to be rabbit holes. And even in best case it…

In fairness, it seems the problem in your case is that the "manager" has built up walls between people, trying to own the work, and in that not allowing you the full context that would allow you to make informed decisions around such asks. "The manager not wanting you to spend time debugging this now" should be a false premise. Knock down the walls and you will know yourself that you shouldn't spend time debugging it now.

Re: Egoless Engineering

#229

Kiva's engineering drew quite a few lessons from Etsy, though we never got so big. I think Dan is missing mentioning one ingredient: Security. Not code security, the human feeling of personal security. Most especially, of being secure in one's role. And that drives so much of this. If everyone is secure in themselves, or able to transcend worrying about their personal security, then magic happens. Without it, things…

I was listening to Andrew Kelley (of Zig fame) in a podcast the other day. He talked about the fact that, because the zig foundation is a bunch of empowered experts, he doesn't really need to manage work because people following their own idea of good software leads to really great work. Having the psychological safety of "being trusted to do what you think is right" is critical.

I think there's so much in that (although how to scale it out is clearly a tricky question). The best places I've worked, have all had the ability to make changes when there's a clear benefit. The worst places I've worked have had the opposite, where it's so hard to touch anything beyond the remit of a ticket or feature item, nobody changes things that are obviously flawed and easily fixable.

Re: Egoless Engineering

#230
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…

There must be a point in which they can be fired, unless there some nepotism going on.

If so, then it's already pretty messed up.

Post reply on HN