Sometimes, being a developer, your job consists of just saying no. No to a feature, a client or your boss requested, no to a new project or no to a...
For further actions, you may consider blocking this person and/or reporting abuse
I find that most feature requests have a valid problem behind them, even if what was specifically asked would lead to a worse product. The hard part is teasing the actual problem out of the request instead of taking the request at face value. Rather than saying "no", I usually find more good will by having a conversation with the requester to figure out what problem their request is meant to address. And then bounce ideas off of each other that can meet their constraints and my constraints (e.g. performance, quality, etc.) while solving the actual problem. If it's something that has unclear implications, then I will add it to my backlog of work but continue to collect information and refine the problem definition until an answer becomes clear. Instead of "no", it's "later".
All that said, I have said No on occasion. One particular consulting job, I refused to do because I was given some donated code from an outside company and told to adapt it to the client's system. They were hoping since the code was already written it would be a quick and easy new integration for them. It was a spaghetti mess that I didn't want to be responsible for going forward, and I told the client as much.
For us it's usually already on the backlog and it's a matter of saying "Yes, but it might still be a while". But feature requests always get a bit of a boost.
No is almost always no for now, or yes, but it has to fit the structure a bit better, here's what we're thinking.
I asked my ex-boss for salary raise. He said "NO". Then he became my ex-boss.