There also IS the Two Cultures problem. See Wikipedia, for example.
I.e., a significant fraction of developers are not able or do not want to do the work the analysts do.

I think you’re exactly right. When I’ve interviewed people both for development and requirements/analyst positions one thing I always look for is reaching “beyond their role.”

I’ve become convinced over the last decade of working in the software space (combined with almost a decade as a mechanical engineer) that people who are great at whatever they do develop a significant understanding of what the people around them do. People who aren’t great at their own work rarely understand the work of their peers.

I believe that developers getting involved in requirements/specification, and understanding customer needs, qualifies in this regard.

Great insight, and thanks for reading and commenting!

Too often optimization, titles and processes (which are all necessary) can reduce a developer to a ‘cog’ in the wheel. While the ‘plan’ sure looks good on paper, it doesn’t account for job satisfaction, growth or passion. While developers can be technology focused, enabling the technology team as a contributor further up in the process provides rewards in passionate developers downstream.