> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the cli

> Programmers are most effective when they avoid writing code. They may realize the problem they’re being asked to solve doesn’t need to be solved, that the client doesn’t actually want what they’re asking for. And how do you balance your urge to say "this feature is not what brings us the most value" in a team setting where the business/ product decisions should be evaluated by the product owners? I've only worked with one product owner who actually appreciated the engineers challenging product decisions and was capable of actually changing priorities based on our feedback. He didn't always change his mind, but I know that he was always listening and never made me feel like insubordinate little child. Most business and product people may let you share your thoughts, they smile and nod, and ignore everything you said. Do it a couple of times, you will be labelled as "not a team player". Do you want to know how our similar features performed in the past? You want to challenge whether some SAFe ceremony actually works for your "autonomous" team? You want to recommend hiring an analyst because the whole product flies blind without proper data? Want to take a step back and think about whether a project that takes many man-years to complete is bringing the business or the users any value? Too bad, shut up and code. I had to work too many times on a "super urgent, hundred million dollar feature" and "non-negotiable legal requirements" that still hide behind a feature toggle. In practice, you can figure out in a couple of months whether the person in charge of product vision is capable of listening or not. If they are not, you'll either learn how to keep your skepticism to yourself and do as you are told, or you start looking for a new position (or going solo).