If you are a product creator, whether a software developer or chair maker, and don’t thrive on resolving negative feedback you should adjust your perspective. Your products probably suck.

Think about using your product. How does a user feel? Too few developers are the actual primary users of their software; many never use it at all. I used to write software for Amazon and not once did I ever purchase anything off Amazon (now I do). Now I’m building a product I use every day. This means there are many things I see every day I hate.

In my ticketing system I have 432 tickets. 339 are closed and 94 are open. While that is a lot of completed work, it shows how much remains to do. More tickets are added every day and I love it. It is how I measure progress, but the number of tickets isn’t the metric I use.

Resolving the ticket may not fix the problem.

Recently I had a support request come in that confused me. It could be a real problem or user error. After discussing the problem and doing some testing, we found that a potentially destructive activity could be done with limited intention. In short, deleting people’s data is bad but allowing them to delete their data on accident is even worse.

The nature of the ticket was different than the actual problem reported. A new ticket was created now, because we stopped and considered what could have been the root cause. We improved and resolved an issue but it was completely separate to what we started with.

All problems should be thought about before they are fixed, and even before the solutions are thought of. Even the tiny, small ones that have harmless fixes. Wonder why and question yourself.

This thought loop is important and I wish all tickets I closed got the same treatment. I don’t do this but I’m working on it and improving. It’s hard to distrust ourselves, it goes against our nature.

Question yourself, nobody else will.

When I get some bug I try to always analyze what the root cause was. I don’t expect to be perfect and this isn’t meant to blame myself or someone else. Certainly I’m not going to beat myself up over it. Bugs happen.

But it’s important to question myself. What can I do better so it won’t happen again? Or, more importantly, what can I do better so the next time it happens I can fix it easier or faster?

I do this to improve. I do this to write more and product more tomorrow than I can do today. If I’m writing the same code 5 years layer, what’s the point? I’m not doing this for a paycheck, I’m doing it to make great product that I want to use.

Focus on the result.

Any developer that doesn’t thrive on receiving and resolving issues is going to produce a shoddy product. Their perspective is wrong. It’s the “works on my machine” mentality. The developers machine is the least important machine that it works on. In 5 years, they’ll make the same mistakes. They’re making the same mistakes they made 5 years ago.

Let’s stop and think about the users. They’re the ones who matter. Use your product. Use it like someone else built it. Chances are you’ll need a drink afterwards.