Valérian de Thézan de Gaussan 
Stop coding. Start asking why.
Stop diving straight into code. That might sound strange coming from someone who loves to build, but it’s the hard truth every developer has to face if they want to create software that actually matters.
Why? Because most features don’t matter
Before jumping into how to build something, ask why it’s being built. What’s the real business interest here? Way too many features get coded and then sit around, unused, cluttering up the product and wasting everyone’s time. Developers who can push back on meaningless features aren’t just following orders. They’re saving time, money, and mental bandwidth for everyone involved.
The middlemen problem
Between the developers and the users, there’s often a long line of intermediaries. Product owners, scrum masters, business analysts: the titles don’t really matter. What matters is that all these extra layers act like a game of telephone. Each person in the chain adds a little, loses a little, and by the time a request hits the developer, the purpose behind it is usually half-lost. So, you end up with a backlog filled with nonsense or, at best, half-baked ideas.
Here’s a better way
Imagine if developers had direct access to users. No product owners. No analysts filtering and interpreting everything. Just developers talking to the people who actually use what they build. In this unfiltered setup, developers would get to understand the problems firsthand. They’d get to hear what users actually need, not what someone else thinks they need. That’s where real solutions come from.
Then, if a feature aligns with the company’s direction and makes sense for the product, go ahead and build it. No need to wade through layers of approval. No endless waiting. Just meaningful work that moves the product forward.
It’s about cutting the crap
Encourage your teams to question everything. Not just the tech specs or the code itself, but the purpose behind it all. The best products aren’t built by developers ticking off tasks on an overstuffed backlog. They’re built by developers who know when to say no. The aim is to build features that solve real problems and make a real impact.
In software, less is more. Work only on what matters, and leave the rest out.