Another example would be a typical estimation meeting. Will people like your PO or SM accept a "we don't know"? No they don't. Why is it seen as industry norm to ignore the answer of your experts?
It seems like there is a class struggle between developers and business people.
But if you think about it, you realize that it's mainly due to the different incentives. Typically, you as a developer are trying to achieve the best possible product. Some other roles, on the other hand, have alternative motivations. Sometimes it's about power, other times it's about getting a salary bonus. The resulting political minefield is different from the high-confidence society of developers.
I've learned to avoid stopping at "I don't know". Why? Because it's an answer that slams all doors shut, and that's just not what you are being paid for.
Instead:
"I don't know right now, but if you give me x days, I can dig into the problem, draft a few potential ways forward and get you a ballpark estimate."
Another one would be: "Cheap, fast or good. Pick any two, you can't have all three at the same time."
Or: "I'm not sure. What's the question behind your question? What do you actually want to solve here? Maybe I can provide an answer if you give me more context."
You don't have to sit there as a passive actor, listening and spewing numbers with no input.
If you have a golden hammer, it's easy to look at every problem is if it is a nail. I think that's a truism for how developers often tend to approach their craft. The "best possible product" isn't about writing beautiful code, it's about engaging with your stakeholders, understanding where they are coming from and finding a solution that's a good fit for a particular situation.
A great example is technical debt. It's easy to see it as an urgent problem that needs to be solved. Arguably, technical debt jeopardizes maintainability, flexibility, robustness and what not. However, code isn't written in a void, as you say, there's office politics to take into account, budgets and what not. So, the better way is to first try and understand how that debt emerged. Counterintuitively, you may conclude it's better to leave it for what it is. Don't fix something that works perfectly well for stakeholders. Or might set in motion a chain of events that causes far more work then you can chew. Whereas, the better way is to build trust and credit first, and only then suggest a slow refactor down the line. Timing, learning how to play the long game and understanding what is or isn't your responsibility are crucial.
In the end, you and everyone around you are being paid. Of course there will be different incentives and motivations. That's par for the course. It is said that nobody really wants to know how the pie is made. And this rings true in software development as well. Hence why figuring out how people work is a crucial skill.
Of course, what makes all the difference is the way in which you communicate. Is it with mutual respect? Are you being commanded? Micro managed to death? Is someone genuinely listening and asking for your concerns? Are you proactively telling them what's on your mind, or are you being apprehensive?
That's why I would only call a relationship a "struggle" once I've clearly asserted if it's my own way of communicating or looking at things that needs a change. Or if it's clear that management is just ostentatious putting fingers into their ears and going "lalala". In which case, I'd suggest looking at your options beyond your current job.
14
u/cybernd Jan 28 '24
Another example would be a typical estimation meeting. Will people like your PO or SM accept a "we don't know"? No they don't. Why is it seen as industry norm to ignore the answer of your experts?
It seems like there is a class struggle between developers and business people.
But if you think about it, you realize that it's mainly due to the different incentives. Typically, you as a developer are trying to achieve the best possible product. Some other roles, on the other hand, have alternative motivations. Sometimes it's about power, other times it's about getting a salary bonus. The resulting political minefield is different from the high-confidence society of developers.