As a developer, sometimes you can be proactive and get involved in proactive conversations to understand why you are implementing a feature. Does the feature requested is making the user experience more cumbersome or you are solving for the user’s solution but not the root cause solution.
“I want you to add a flashing moving text notification for any new updates that come into the system”
Flashing? When I hear this I think of the classic <marquee> tag. In theory it makes sense, the user wants to be notified. Why do they want something annoying as a flashing text? You can talk to the user to find out more about why they want the feature. As you speak to them try to relate to how their environment is or how they currently use your application. Is it always open amongst other applications or is it just used as the sole application at once like a word processor? By using your empathy and listening skills you can understand the reasoning behind this request. You can try suggesting a popup notification or badge like notification. Maybe a flashing notification is what is necessary.
What is necessary may not be what you hear first as the solution. Sometimes an user’s request to solve their problem could be investigated further to find out that a better solution is only a few more hours of work to do or a simpler solution could be uncovered via extra education.
Knowing why you do something is important in life and it is the same for coding as well. Making things of no value or building a wrong features is a waste of your time and in life you can’t be wasting your keystrokes.