Working on Products People Hate

Sean Goedecke (see sean-goedecke-blog) writes from experience at Zendesk and GitHub — two companies whose products regularly attract vocal criticism. His argument: the quality of an individual engineer's work has surprisingly little bearing on whether users love or hate the product.

A strong engineer can improve things in their local area. They can write clean code, ship a better interaction, fix annoying bugs. But that work gets absorbed into a codebase shaped by organizational incentives, product strategy, and accumulated decisions made by hundreds of people over years. The individual contribution, however good, doesn't override the structural forces that make users frustrated.

Goedecke treats this as a feature, not a bug. Working on something people complain about teaches you where the boundaries of individual-engineer-agency actually are. Engineers who only work on beloved products can develop a distorted sense of their own influence — attributing to personal skill what really comes from being in the right company at the right time.

There's a practical resilience angle too. Reading harsh criticism of something you built requires learning to neither dismiss users as wrong nor internalize their frustration as your personal failure. Both reactions are tempting and both are dead ends. The professional move is sitting with the discomfort: users have legitimate complaints, you have limited power to fix them, and the job still needs doing.

The silver lining is genuine. A product that millions of people use daily but find annoying is still a product millions of people use daily. Making it 5% less painful is real impact, even if nobody writes a grateful blog post about it. And almost every engineer will end up in this position at some point — it's a normal part of a career, not evidence that something went wrong.