As a developer, my requirements are handed down to me from business. I have a small amount of power to suggest improvements, but largely, the design of the system isn't handled by me; I just implement it.

I'd agree that having different perspectives in the idea phase is very important, but when it comes to implementation, diversity doesn't matter at all. Get the data from database, stick it in the views. It's pure technical ability at this phase.

I used to work with an engineer who felt the same way. At one point, I was asked by management to help him out because a product release had fallen behind by nearly a year. He was working very diligently to implement a nearly impossible specification (300+ hour battery life with a standard 9V), and was trying all kinds of sleep modes and stuff. I asked him what was the need which was driving the 300 hour lifetime and making him do so much work. He said, "I'm an engineer. It's my job to make the design meet the requirements."

I went and talked to the customers and other stakeholders, and found out that 300 hours was actually a nice-to-have. 48 hours with some margin was absolutely necessary, and 100 hours was better than equivalent devices on the market. We got buy-in to change the requirements and released the next week with a 100 hour lifetime.

Just an idea what a different perspective can bring.

Or perhaps your different perspective convinced him to stop work on what would have been an amazing development?

I'm just responding to your anecdote and I do agree that different perspectives are valuable. My point above was just that there are many, many places to include diversity and the hyper-focus on the implementation phase (aka development) means you will miss the more valuable lifecycle phases where diversity has much more impact.

This would seem to support the claim that none of the perspectives that would matter to an engineer are gender-specific.