This debate is as old as time. Another form of this debate is whether the onus of understanding is on the speaker or the listener. I've seen people manipulate

This debate is as old as time. Another form of this debate is whether the onus of understanding is on the speaker or the listener. I've seen people manipulate this debate back and forth, both have good points and bad points. People will always flip flop depending on what situation they're in because it benefits them, plain and simple. I view this article in much the same light. Telling users they can't comment without thinking up a possible solution is incredibly dismissive. Usually I've seen this done because teams have shifting priorities or when a lot of effort was dispensed to solve a problem that doesn't solve a problem for everybody. The fact is that people live in their own worlds. When you develop a tool that tool becomes part of their world and to some degree they depend on that tool. When the tool has lots of influence from people who use the tool differently, obviously strong disagreements will occur. I've seen this with internal tools I've developed before where priority was given to automation features and not UX features or vice versa. To me, the problem isn't the speaker or the listener, the reporter or the maintainer. It's just discourse. - If you feel some type of way about a comment then let another team mate tackle it. Maybe the way you feel is justified, but in the grand scheme of things, if you go try to explain your justification to the commenter they're just going to see some powerful maintainer telling them how to feel about a problem with a tool that they chose to make a part of their world. - Use data and process engineering to tackle your problems. Overusing empathy to design and develop software leads to exhaustion and a lack of caring. Not everyone will suffer from this problem, but many people who overuse empathy cannot stop at just identifying with a problem. They feel the problem. Instead, separate yourself from the problem, quantify it, and build a case for how to work on it. Let empathy motivate you but don't let it rule your judgement or consume you. This data driven approach accomplishes the same thing as the former does but leaves your emotions and well-being intact. - If you're a naturally curious person: on comments which lack solutions probe the commenter for more information. Make them be useful to you. Sure, it takes more time and it's inconvenient but welcome to software; not everyone has a war on time like Software Engineers do. Sometimes observational style comments I will wrap up and store in Obsidian for a later date. I may not do anything about them now, but if I see repetition then I'll start digging.