I haven't read it myself but I probably will because I have a lot of hope for this topic (there must be a better way to do this!)
I worry that it doesn't much matter if it's perfect or mediocre, though, because there's a huge contingent of project managers who mock _any_ efforts to improve code and refuse to even acknowledge that there's any point to doing so - and they're still the ones running the asylum.
Project managers shouldn't be running engineering. They are there to keep the trains running on time, not to design the track, trains and stations.
The generally accepted roles are Product decides what we need to build, Design decides how it should work from user perspective, Engineering decides how to build it at a reasonable upfront and maintenance cost. This involves a fair amount of influence, because Engineering is better equipped to describe the cost tradeoffs than any other function. Of course this comes with the responsibility of understanding the big picture and where the business wants to go. IMHO you should not be speaking to project management about code quality, you should maintain ground level quality as you go, for bigger refactoring/cleanup this needs to be presented to Product leadership (not project managers) in terms of shoring up essential product complexity so it's easier for customers to use, less support, and simpler foundation for the next wave of features. Never talk about code with non-technical stakeholders.
I disagree fundamentally with the modern division of labor. I’ve been around long enough to understand that it doesn’t actually have to work like this.
I don’t think you can be an expert in generic “Product” just like I don’t think you can be a generic management expert.
And I don’t think you can decide what to build or how it should work from a user perspective without taking into account how it’s built. In many ways I think how it’s built tends to inform what it should do more than the other way around.
However, Product alone is never the cause of bad software in my experience. It’s always product plus an engineer who refuses to push back on the initial proposal.
In most cases when product and design comes to you with a feature, and all the solutions you can come up are going to add tech debt or take forever, you should step back and talk to Product about the problem they are actually trying to solve.
If you go back to product with “I can build this very similar feature that will get you 90% of the way there, but will take 1/2 as long and not create maintenance problems down the line”, they will almost always be happy with that.
The real problems are caused when an engineer says immediately “yep I can build that in 2 weeks” and starts trying to force their solution through by telling everyone that product insisted on this specific feature in this specific timeline that unfortunately can only be done in the way they’ve designed. And then they tell product that they have a solution but are being blocked.
I’ve seen this pattern over and over.
This is exactly what I assume when I see people blame their tech debt on others.
We do the work, we are responsible for whatever it is. Sure maybe some times you begrudgingly just have to do something you're told, but in my experience there's almost always room for discussion and suggestions. I think most devs just don't care. They do what they're told and blame others if it's ass.
Agree on the one engineer overpromising. But you can talk about a product without knowing how it’s built in finer details. But what can and can’t be done is the realm of engineering. Then the filtered list can be reduced by product to the ones that are inportant. So it’s actually a spiral: (product) here’s what I would like -> (eng) here’s how it can be done -> (product) let’s go with this one -> (eng) here is the plan -> etc…
I should've noted that, although I found it frustrating, I think it's a good read for most programmers. There are many excellent ideas in the book.