The news from Charlottesville is not an isolated incident. The US President responds that there is violence “on many sides.” This is false.

In Charlottesville, the police were present in riot gear, but the rioting white people were treated with kid gloves, a stark difference from Fergusen police reaction reported by @JayDowTV who was there.

These people feel comfortable declaring it a war: “And to everyone, know this: we are now at war. And we are not going to back down. There will be more events. Soon. We are going to start doing this nonstop. Across the country. I’m going to arrange them myself. Others will too, I’m sure, but I’m telling you now: I am going to start arranging my own events. We are going to go bigger than Charlottesville. We are going to go huge.”

General McMaster, US National Security Advisor tells us “I think what terrorism is, is the use of violence to incite terror and fear. And, of course, it was terrorism” (NBC via Vox)

A Christian minister writes this plainly on his post, Yes, This is Racism. We each need to declare what we stand for in this moment and always.

We are not with you, torch-bearers, in Charlottesville or anywhere.
We do not consent to this.
In fact we stand against you, alongside the very beautiful diversity that you fear.
We stand with people of every color and of all faiths, people of every orientation, nationality, and native tongue.

We are not going to have this. This is not the country we’ve built together and it will not become what you intend it to become.

So you can kiss our diverse, unified, multi-colored behinds because your racism and your terrorism will not win the day.

Believe it.

— John Pavlovitz

Disclaimer: I work at Google. This article is based on 18 years of observing the company as an outsider, along with over a year of experience as a senior technical leader at the company.

An internal google document was published this weekend, where an individual articulated poorly reasoned arguments that demonstrated conscious bias, both about gender and about the skills necessary for software engineering. Demeaning generalizations and stereotypes were presented as unbiased fact. The author may not have intended to be disrespectful, yet caused great harm. Many women have spoken publicly about their frustration in reading this harmful rhetoric in their workplace.

For many years before I joined Google, I heard stories of sexism and racism that happened inside the company. Frankly, I know of no company which is immune to this. Companies believe they have well-established social norms around respectful behavior, good management training, effective escalation paths, etc., yet these aren’t evenly distributed. In 2006, I declared that I would not work at Google because of their hiring practices. In 2016, I decided that both Google and I had changed a bit since then. I interviewed Google even more than they interviewed me. Not including the actual day of interviews, I had 21 conversations with 17 different people before deciding to work here.

Unexpectedly, Google was the first tech company I have worked for where I didn’t routinely meet people who expressed surprise at my technical ability. There seems to be a positive bias that if you work for Google you must be technically awesome. I can’t tell whether this is universal. (I assume it isn’t. Google is a big place.) However, as evidenced by this latest rant, Google has a long way to go in creating effective social norms around discussing diversity and the efforts to make hiring and promotion fair.

We need to be careful as we address inequities. As a woman who attended private high school and studied Computer Science at a prestigious university, I have an advantage in getting a job at any tech company over a white man who joined the military to pay for college and taught himself to code. Google could, if it wanted to, hire the very best women and people of color such that it statistically matched the demographics of the United States, and not “lower the bar” yet still be homogeneous, yielding limited benefit from its diversity efforts.

Diversity and inclusion is not just about demographics. The lack of minorities and women at Google and most other tech companies is a sign that things aren’t quite right. We should look at diversity numbers as a signal, and then seek to address underlying problems around inclusion and respect. We need to include effective communication skills as part of selection criteria for new engineers and for promotion.

Ex-Google engineer Yonatan Zunger wrote a thoughtful response about how communication and collaboration are critical to the work we do. I have also written more generally about how communication is a technical skill: “We usually think of software as being made of code, but it is really made of people. We imagine what the software should do, and through our code, we turn ideas into reality…. I find it confusing that anyone could even suggest that communication is a different skill that is optional for programmers. This is what we do. We write our code in programming languages. We define things and then they exist. We make real things using language.”

I’ve worked with amazing engineers who have little else in common. The best engineers I’ve worked with solve problems differently from each other — creativity and insight combined with technical skill are the mark of a great engineer.

The Google hiring process tests for the candidate’s ability to write code and solve problems (and to some degree talk about code). This is not enough. Google and the rest of the industry needs to set a higher bar for hiring talent. It is much harder to collaborate effectively and communicate your ideas than it is to write a basic algorithm on the whiteboard.

In my experience, the ability to write great software is not tied to any outward trait, and discussion of biological or societal differences is a distraction from the core issue. We need people with a diversity of experience and perspectives to bring creative solutions to their work, and we need engineers who can work with people who are different from them with respect and enthusiasm.

I know there are good people working inside of Google to make change. I applaud the publication of research on effective teamwork. This is not enough. This work of creating change for humans is much harder than the work of writing software. Smaller companies have a greater opportunity to make change faster. We each need to step up and take a leadership role at every level of our organizations.

Impact matters more than intent.

Sometimes when I talk about customer use cases for software that I’m building, it confuses the people I work with. What does that have to do with engineering? Is my product manager out on leave and I’m standing in?

I’ve found that customer stories connect engineers to the problems we’re solving. When we’re designing a system, we ask ourselves “what if” questions all the time. We need to explore the bounds of the solutions we’re creating, understanding the edge cases. We consider the performance characteristics, scalability requirements and all sorts of other important technical details. Through all this we imagine how the system will interact. It is easier when the software has a human interface, when it interacts with regular people. It is harder, but just as important, when we write software that only interacts with other software systems.

Sometimes the software that we are building can seem quite unrelated from the human world, but it isn’t at all. We then need to understand the bigger system we’re building. At some point, the software has a real-world impact, and we need to understand that, or we can miss creating the positive effects we intend.

On many teams over many years, I’ve had the opportunity to work with other engineers who get this. When it works there’s a rhythm to it, a heartbeat that I stop hearing consciously because it is always there. We talk to customers early and often. We learn about their problems, the other technologies they use, and what is the stuff they understand that we don’t. We start describing our ideas for solutions in their own words. This is not marketing. This influences what we invent. Understanding how to communicate about the thing we’re building changes what we build. We imagine this code we will write, that calls some other code, which causes other software to do a thing, and through all of the systems and layers there is some macro effect, which is important and time critical. Our software may have the capability of doing a thousand things, but we choose the scenarios for performance testing, we decide what is most normal, most routine, and that thing needs to be tied directly to those real effects.

Sometimes we refer to “domain knowledge” if our customers have special expertise, and we need to know that stuff, at least a little bit, so we can relate to our customers (and it’s usually pretty fun to explore someone else’s world a bit). However, the most important thing our customers know, that we need to discover, is what will solve their problems. They don’t know it in their minds — what they describe that they think will solve their problems often doesn’t actually. They know it when they feel it, when they somehow interact with our software and it gives them agency and amplifies their effect in the world.

Our software works when it empowers people to solve their problems and create impact. We can measure that. We can watch that happen. For those of us who have experienced that as software engineers, there’s no going back. We can’t write software any other way.

Customer stories, first hand knowledge from the people whose problems I’m solving spark my imagination, but I’m careful to use those stories with context from quantitative data. I love the product managers who tell me about rapidly expanding markets and how they relate to the use cases embedded in those stories, and research teams who validate whether the story I heard the other day is common across our customers or an edge case. We build software on a set of assumptions. Those assumptions need to be based on reality, and we need to validate early and often whether the thing we’re making is actually going to have a positive effect on reality.

Customer stories are like oxygen to a development team that works like this. Research and design teams who work closely with product managers are like water. When other engineers can’t explain the customer use cases for their software, when they argue about what the solution should be based only on the technical requirements, sometimes I can’t breathe. Then I find the people who are like me, who work like this, and I can hear a heartbeat, I can breathe again, and if feels like this thing we are making just might be awesome.