Technical details are not always irrelevant nor mere implementation. They are often critical to the success of a product. It's like refusing to order from a menu at a restaurant and instead shouting "I WANT FOOD!" in a vain attempt to hide illiteracy.
"Oh what kind of food, sir?"
"GOOD FOOD! HOW DARE YOU ASK ME THAT!"
"Would you prefer a picture menu, sir?"
"...yes"
So, better off talking to the product manager who just orders hamburgers for them. Of course that just drives a wedge between devs and leadership even further and erodes trust. No wonder devs job hop. No wonder every product is so mediocre.
There's no escaping the fact that the days of non-technical leadership are numbered. Conversation should never be one way regardless of the hierarchy within a business. Such is the dysfunction of today's leadership.
This sounds like telling devs to 'manage up' which is shorter/searchable. I think that's good advice for more sr devs but juniors are still working out how to solve problems as stated and understood with their tech at-hand. Having this extra layer would probably be too much to deal with all together.
Now my ability to find something is limited by someone else's availability, and everywhere I've seen this culture it's devolved into the same 1-2 people answering all the questions as not everyone has a built up map of who knows what.
I have degrees in math and physics. Those degrees gave me close to zero value in the market. Spending X years in school, then having to prove to an employer that you can do barely more than squat is a familiar experience in a lot of fields.
There are tests you can take in those subjects, such as the Graduate Record Exam. Those tests work to some extent because the subject matter is relatively mature, and consistent from one college to another. And yet there are entire fields of math and physics that I've never been exposed to. Their main purpose is to see if you're conversant in a body of knowledge that would prepare you for typical graduate study, not for a job.
Software engineering is a comparatively young field, with less standardization. There are even debates on HN as to whether software engineering is a real thing. There are places where every programmer has the title "engineer" regardless of their background.
I'm only employable because most people hate math and physics so much that they're relieved if anybody offers to do those things for them. That, and I'm pretty good at programming and electronics.
There comes a point where impossible to leave code in a better state without a major refactor.
The choice is between writing a few ugly if statements making the code a little worse or spending 10x the time refactoring hoping you don't introduce any regressions.
The choice is between writing a few ugly if statements making the code a little worse or spending 10x the time refactoring hoping you don't introduce any regressions.
Those few ugly if statements might make the code only a little worse and take 1/10 of the time to do the job properly if the code was previously good. However the trouble with technical debt is the interest can compound rapidly. Your random set of if statements combined with three other developers' random sets of if statements from previous hacky changes (two of them in other parts of the code that the part you're modifying now implicitly and surprisingly depends on as a result) could be a story with a very different ending.
The argument is if you specialize in young women's clothing, instead of trying to micro target messaging to different personas, have a single message that can work with everyone you are trying to sell to.
I often use the 80/20 rule to push back against requirements from product managers.
Identify the features that are hard to implement and provide little business value then cut them out. For the things that are important, I see if there are any adjustments to the requirements to make it simpler.
It usually an easy sell because it results in getting out the product faster. We can always do the nice to have stuff as a follow up, but more than half the time, they realize they never needed it.
If done strategically, it can prevent adding tech debt in the system.
Instead try to understand what others really care about and frame the discussions around that.