I think this is great: > The only way to recognize — and then bridge — the gulf of understanding between you and people using your tool is to observe their str

I think this is great: > The only way to recognize — and then bridge — the gulf of understanding between you and people using your tool is to observe their struggles and talk to them. It’s amazing how quickly glaring flaws are revealed this way. Answering questions on Stack Overflow (or GitHub, Twitter, Slack, or wherever else) is not a selfless act of altruism; it’s a chance to learn, to find where people struggle and hear their perspective. Each question is an opportunity to help one individual, but that question can also inspire a tutorial, an example, or even a feature that prevents others from hitting the same issue. What I love about being a front-end engineer is seeing how people use what I build, which almost always brings up "obvious" issues and improvements that weren't so obvious when you're working on it yourself. Now that I'm mostly building developer tooling, this gets even better: not only are the users like me so I can empathise with them better, but I know where they're going with their questions and observe them "in the wild", and easily figure out what help they need without needing to set up specific UX research sessions. But this primarily gets fun if you use it as a way to scale up your support. Which means it's important to keep the following in mind: > But there’s also a limit. As one person, you can’t help everyone. And you can’t make everyone happy because your tool is only a tiny part of their life. Don’t make that your goal: focus on learning and broadening your perspective. If it stops being constructive for you, then stop. Period. And don’t feel bad!