4 ms·
> I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engi
by kcplate 3y ago
> I'd argue that the position taken above weakens the engineering practice. Understanding requirements (e.g. constraints) is a core element of engineering, engineering management, and general management.
Determination, evaluation, and articulation of requirements is the sweet spot of the product manager role. Understanding those requirements is certainly necessary for an engineer to build to the requirements.
- moandcompany 3y agoAn engineer's understanding of requirements entails determination, evaluation, and articulation of those requirements. Calling oneself an engineer doesn't preclude their ability to do these things, and force them to call themselves a "product manager" for doing so. And quite often, especially at more senior levels, an engineer must do these things. Once upon a time, this too was a formalized practice in engineering that people called "Systems Engineering": https://en.wikipedia.org/wiki/Systems_engineering https://en.wikipedia.org/wiki/Systems_engineering https://www.nasa.gov/reference/2-0-fundamentals-of-systems-engineering/ https://www.nasa.gov/reference/2-0-fundamentals-of-systems-e...
- ketzo 3y agoDoesn’t preclude the ability, no, but there are only so many hours in the day. Writing good code is a very separate skill set from that kind of problem-space work, and software engineers are mostly hired for the former.
- sarchertech 3y agoOnce you get to staff+ level, engineers are no longer hired mostly for writing good code.
- ketzo 3y agoThat’s fair, but that is… what, 1% of all software engineer hires?
- sarchertech 3y agoI don’t know about as a percent of total hires, because staff+ engineers tend to stick around a bit longer. But in my current bigco it’s a bit north of 10% and I’ve seen it go as high as 20%.