A lot has been written about the 10-page memo by former Google employee James Damore. Following on from the folks at MongoDB, we, the Capgemini UK Engineers, felt the need to share our thoughts on it with all our peers in the worldwide engineering community.
We’re not going to go into the science. There have been Quora posts as well as articles which have responded in detail to each of the points raised in the memo in far more detail. There’s little point adding to the voices in this area - there are others who know far more about the current state of the science of individual differences (from the perspective of evolutionary psychology and beyond) than any of us. Suffice it to say, we agree with the conclusions of the above experts; that there are undeniably individual differences between everyone, and that in some areas there are individual differences between the sexes. However, to use any of these as a basis for a conclusion of the kind which states that one group in particular is on average more biologically suited to software development is simply wrong.
This said, we do however feel well-placed to comment on what makes a good software engineer. We know from personal experience that more than anything else, the reason these extrapolations (from carefully-selected traits to a general superiority in software engineering) are flawed is because they fail to acknowledge the multi-faceted nature of this discipline within which we have made our careers. And ironically, it is this very complex mix which makes diversity and inclusion more than simply a moral crusade or a nice to have. These focuses are imperatives for anyone who wants to engineer the best solutions and ship the best products.
How can we be so sure?
Let’s take a step back for a second and think about something as simple yet fundamental as Test Driven Development. When we do TDD we know that there are three distinct mindsets at play in every single line of code that we write. There is the thinking about what it needs to do (from the perspective of the consumer - the failing test, aka the Red). Then there is the thinking about how it needs to achieve it (the line of code to make the test pass, aka the Green). Finally there is the redesign, to make what you just wrote clean, well-designed, and structured.
That’s three mindsets just for a single line of code.
That’s when you’re at the keyboard alone.
Three distinct, different, equally hard, core things.
But wait; what if you’re pair programming? Or if you’re working as part of an Agile team? Or trying to understand the concepts that are in your user’s head but that they can’t quite get you to understand?
How many skills are at play then?
And we’ve not even started to think about planning, architecting, testing, debugging, deploying, monitoring, scaling, fixing, maintaining, and decommissioning your code. Or the code that one of your peers wrote. Or even something that someone you never met wrote, but that you depend upon to get your job done every. single. day.
How many skills are at play then?
This is our key point. And one which we feel needs to make indelibly clear. While there are no objective measures of software quality, or productivity, or even value; there are things we do know. How do we know? From our hundreds of years of collective software delivery experience.
We know what the job entails. Sure, it entails abstract, hardcore, intellectual graft; but it also entails creativity, human interaction on a massive scale (with developer-peers, and non-developers alike). It requires understanding, compromise, dogged determination, self-motivation, and a willingness to surrender. It requires distance. It requires focus. It requires communication. It requires planning and management. It requires guessing. It requires continuous learning. It requires humility. It requires a sense of fun. In short, it entails a lot. So much in fact, that no one individual has all these skills. Not even the ones who’ve been doing this a long time.
We know some other things.
We know that the ultimate results of combining all the above are good products and working solutions. We also know that the only way to get the best of all of these skills is via empowered teams; inclusive teams who trust each other and support each other; teams who collectively are far stronger than any individual’s strengths; teams who between them encompass not only a myriad of skills-mixes, but also a rainbow of viewpoints and thought patterns. And the result? They deploy their powers, and those of their peers, to greater, frequently unimaginable effect.
There is only one way to achieve this. That is when the working environment is a safe and inclusive place; a place where individuals can be the worst at something, or try something spectacular and fail; a place where individuals can express themselves, be themselves, disagree, and then come together with a better, alternative solution. That is when the environment is one which supports people with these skills to work as teams, and to build amazing things together.
This is why diversity and inclusion are vitally important. Diversity makes us all better, and inclusion ensures that everyone can contribute; and consequently the end results are the best they can be. We have a lot of stuff to imagine and build in the coming years, and we’ll need all the help we can get - let’s not put up even more unnecessary barriers.
