Like you, I lean heavily towards the "Product Engineer" mindset (although I'd not heard that phrase until now). My first question is usually "What problem does this feature solve?". This is a habit that has developed naturally -- I've had too many carefully crafted features that went unused and unloved. Those failures sting, and so one learns to ask the question. That and empathising with users. After all, I'm quite often a frustrated user of software myself!
Like @kwstannard
, I'm not sure there's a dichotomy between product and craft. If anything, the two can complement each other -- by stripping down the requirements, you can focus on crafting the work that is being done.
However, I agree with your follow-up statement that some developers prefer to do the deep work on the code and let others deal with the requirements. In this case, they need to trust that other person.
So, in all, I'm not sure what the dichotomy is. "Leader" - "Follower" downplays the importance of the deep worker. Perhaps "Asker" - "Maker". Or "Why-er" - "Wow-er".
Like you, I lean heavily towards the "Product Engineer" mindset (although I'd not heard that phrase until now). My first question is usually "What problem does this feature solve?". This is a habit that has developed naturally -- I've had too many carefully crafted features that went unused and unloved. Those failures sting, and so one learns to ask the question. That and empathising with users. After all, I'm quite often a frustrated user of software myself!
Interesting. I think I lean more towards asking questions about craft and systems because I have been bitten too many times by technical debt making completing features hard or sometimes even impossible.
Very good point. I guess that just furthers the case that craft and product aren't mutually exclusive. If anything, they're two stages of the same process: product first, craft second. It's possible to ask questions about both.
My thinking is: all unused features are technical debt, regardless of how well they're crafted. They're all noise. Any time spent on them is wasted up front and then multiplied in their maintenance. (Although, as with any grand statement, there are no doubt exceptions.)
Perhaps there should be a distinction to be made between types of technical debt: Used and Unused. I would tend to treat the two very differently.
Thanks for this post, Glenn!
Like you, I lean heavily towards the "Product Engineer" mindset (although I'd not heard that phrase until now). My first question is usually "What problem does this feature solve?". This is a habit that has developed naturally -- I've had too many carefully crafted features that went unused and unloved. Those failures sting, and so one learns to ask the question. That and empathising with users. After all, I'm quite often a frustrated user of software myself!
Like @kwstannard , I'm not sure there's a dichotomy between product and craft. If anything, the two can complement each other -- by stripping down the requirements, you can focus on crafting the work that is being done.
However, I agree with your follow-up statement that some developers prefer to do the deep work on the code and let others deal with the requirements. In this case, they need to trust that other person.
So, in all, I'm not sure what the dichotomy is. "Leader" - "Follower" downplays the importance of the deep worker. Perhaps "Asker" - "Maker". Or "Why-er" - "Wow-er".
Really interesting discussion!
Interesting. I think I lean more towards asking questions about craft and systems because I have been bitten too many times by technical debt making completing features hard or sometimes even impossible.
Very good point. I guess that just furthers the case that craft and product aren't mutually exclusive. If anything, they're two stages of the same process: product first, craft second. It's possible to ask questions about both.
My thinking is: all unused features are technical debt, regardless of how well they're crafted. They're all noise. Any time spent on them is wasted up front and then multiplied in their maintenance. (Although, as with any grand statement, there are no doubt exceptions.)
Perhaps there should be a distinction to be made between types of technical debt: Used and Unused. I would tend to treat the two very differently.
Agreed.