Great write-up. Thought provoking and something I definitely have seen. I'm a little more on the product side ... However I might suggest a slightly better pris

Great write-up. Thought provoking and something I definitely have seen. I'm a little more on the product side ... However I might suggest a slightly better prism to shine the op's light through to suss out nuances: - time frame: the more immediate your attention the more code emphasis you have. The more depth first the more code like you are. The more senior you are the more product you might be because you're able to see beyond the day to day noise. - TQA v SQA: (Total quality attribute v substitute quality attribute): in fact neither code or a product emphasis can win because in truth the two are interrelated. Tqa is to product what sqa is to code. Example: The NYTimes buys rolls of paper to print newspapers with. They notice supplier A's rolls rip in the press which requires downtime to fix with subsequent spend of resources to remediate and greater effort to meet deadline. When NYTimes phones A you hear a guy yelling: your rolls suck. They are constantly ripping apart in our press (product or tqa complaint: roll should not rip). To fix A is going to have to trace the tqa to it's sqas: - what's average paper thickness? How much does it vary? Where? Why? - how long did we bleach it because that may increase chance of tears. Maybe bleaching makes the paper brittle - how hard does the press pull on the paper? Maybe it's too tough on the paper? - is the roll sufficiently protected? Maybe shipping or storage knicks it and sets up failure in the machine? - etc So yah better have tqa on the brain. Customers do. And customers write checks or don't if dissatisfied. But better have sqa on the brain because that's how tqa (product failures) are fixed. So? Teams in which persons fixate on sqa (code) or tqa (product) is the real poison. The more my counterpart cares about code only the more I have to care about product and vice versa. We'll wear each other out. Therefore I might need a code first person to spend a little more time typing up usecases so we can see how better to architect and better see how features interact. I might need a product person to be more insistent on more thorough unit testing and less complicated class apis.