Ask HN: How do I feel less guilty about bugs?

We have blameless postmortems after major incidents like "the app is completely down." The action items aren't always followed, even easy ones like "new PRs should not use X function, they should instead use Y function." Two days later a PR will be approved and merged that uses X function. So then I'll make a meeting a month later saying "here are all the action items from the last couple postmortems that I don't think we're following" and everyone will be in full agreement again, but still nothing changed.

So given that, I don't feel very comfortable pushing hard for any process changes. I already feel like I'm bordering on annoying.

The cure is using other software. It's almost all so fucking terrible—yes, even from FAANG—that before long you'll stop feeling bad about your own bugs.

That's not an excuse to get lazy about bugs, but it ought to help you not feel so bad about it.

Apple's way better about software quality in general, than most. Yet every day I use their alarmingly-janky multi-user login/switching screen. If I my M1 Air falls asleep while not connected to power, I'll have to juggle wifi networks to get it re-connected (if I don't want to wait the several minutes it takes it to sort things back out without that intervention). Last I checked opening a link in a new tab in the background while in a "tab group" in Safari still caused a flash of the real content before loading the blank-tab screen and losing the original URL, when you eventually switch to the backgrounded tab, basically making tab groups unusable. Even they ship bugs in big, user-facing ways, and leave them there for months or years.

This is true, but not nearly so much as FP advocates make it out to be. Once you reach a halfway decent level of competence in any programming language, most of the bugs that you write will end up being ones where you didn't understand the "requirements" correctly, or where you failed to predict some sequence of actions and account for it correctly. Type systems and immutability provide exactly zero help in situations like this.

It's better to focus on clear and simple code styles and architectures. The goal is that when you're debugging the code or explaining it to someone else, you don't want any situations where things don't make sense, or something happens in a weird order for no apparent reason. Immutability can help here, for sure, but FP is a double edged sword. Sometimes it's fantastic but at others it makes your code into an unintelligible mess.

So yeah: Don't go rushing to rewrite your perfectly functional Java/Ruby/Python app across to Haskell or Clojure. It won't help you much at all. Rather, think about how you might use some of the ideas like immutability and function composition, to make your Java/Ruby/Python app easier to work with.

You sound like a really smart, engaged employee. I would absolutely not try to 'fix' this in yourself.

Advocating-for customers, fellow employees, technology to solve specific business problems—is the quickest way to progress to senior or staff level engineering positions. Sure you need the engineering chops, but my experience has been that applying those skills in the context of business goals is the quickest way to climb the ladder.

In your case it sounds like you need to be willing to engage with the founders on the field they care about, which is business goals. Their metric of success (downard trend of x) is a good focus for early stage startups. Over time, there will be other metrics that will become important and one of those is going to be customer acquisition channels.

The holy grail of acquisition channels is customer referrals. Do you have NPS surveys at your company (or some other proxy of 'I would love to refer you to other customers')? If you do, I would take a look at what those scores look like, which will help you engage your boss with something like:

- Our NPS score for key customer X is in the shitter, do you think that means we should focus more on bugs so that we don't get a bad reputation? How do we think about NPS vs feature count in a situation like this?

Or if NPS is still good, you have grounds to feel better about the bug situation. Sure it's not good, but you can feel good that you are spending your time in other impactful ways.

If NPS is not a thing yet, advocate for it. One way to do this might be to engage with your boss / founder. I would suggest simply asking how they know when you have met your goal of supporting x number of features. Or if they don't have an answer to that, how they think through when other metrics might become more important. If they go into customer acquisition, marketing, etc, it would be a natural and good time to advocate for NPS or some other form of engagement with your customers so you can discover how to harness them for future growth.

Sorry for the novel. This is basically a long winded way of saying it's not something that needs fixing in you. Business is a big chess game of strategy. If you want to feel better about it, the best way is to continue to engage your boss/founders on the business goals and to help them think more clearly about the tradeoffs you are making as a tech team.

From a human perspective, you are caring for your customers, which are the people who care the most about your product - hey, they use it all day. I think you are amazing for caring so deeply, and I admire it.

From a business perspective, your company has finite resources. It has to decide to invest in getting new customers or in retaining existing ones. This decision would depend on several things such as churn rate of current customers, potential customers, value of locking in more customers up front.

Your concerns are valid. Keep empathizing with your customers. But also be aware of the big picture of the company from a business perspective.