After sitting in on CS 107 as a pre-frosh (naively thinking it was Stanford’s intro CS course), I thought majoring in CS would mean learning about compilers, multi-threading and all the other jargon they threw at us the first day. And while I certainly learned all those things (and more), I was more surprised by what I learned about tech privilege and diversity. You know, the sort of things that don’t really come up in AP Computer Science.

I’d heard all the buzzwords enough that, like most people, I thought I knew what they meant. More importantly, as a hallowed “woman in CS,” I felt that it was my responsibility to preach these concepts to others. After a myriad of workshops, conversations and (dare I say it?) WAYS courses, I’ve found new meanings for these words, and importantly, specific action items to follow. Of course, I had to learn most of it the hard way.

When complimented on my CS ability, I alternated between “What?! I’m really not that good at this” and “I just have lots of CS experience.” For people already stressed about CS, the former implies that if I’m bad at CS, they must be really bad at it. The latter just emphasizes the problematic notion that they are “behind.” Trying to downplay the material by suggesting that “this stuff is easy; you’ll get it really fast” only made others feel worse when they didn’t pick it up immediately. It was a vicious cycle: my friends took my denial to mean I was both “humble” and “a genius”, whereas I spiraled further into my own imposter syndrome. I felt like I always had something to prove and with my freshman friends proudly introducing me to everyone as “good at CS”, it seemed like even asking for help would shatter the illusion. I was surprised to find that I was more relieved than embarrassed when my CS 107 partner, after fixing one of the many bugs I had accidentally introduced into our code, turned to me and said: “You know, it’s actually pretty reassuring that you’re not like crazy good at CS or anything.”

After much trial and error, I finally realized the key was to emphasize my opportunities rather than my experience. It’s dumb luck that my parents are both engineers, or that they sent me to coding camp in middle school. Therefore I frame “I did a bunch of side projects in high school” as “I happened to have a really awesome mentor in high school.” And that so-called head start is easy to make up for. My freshman friends who were so worried about being “behind” all got the tech internships and research positions they were shooting for.

Though I had a rocky start to addressing tech privilege, I felt right at home in conversations about gender equity in STEM. As a woman (and therefore a “minority”), I took myself to be a resident expert on gender equity, and by extension all diversity issues (which should raise some red flags right off the bat). Like most good-intentioned analytical thinkers, I thought that if we could just treat everyone the same, it would be fair for everyone. If only people were as open-minded as my friends and I, good programmers could learn and succeed regardless of gender/race/background. Of course, I wasn’t quite naive enough to think that would happen on its own, so I still supported specific programs for disadvantaged groups.

Besides the assumption that members of a minority are somehow free from bias, it seemed like a fairly reasonable approach. That’s why I was so surprised when I ran into the concept as a very clearly delineated “what not to do” in my Psych 103 (Intergroup Communication) class. This idea of treating everyone the same ties directly into the concept of “color-blindness”: when a person (usually racially privileged in some sense) suggests that we should just ignore color and treat everyone the same. Though the term is actually quite common, I had never heard it before. I was just happily applying the golden rule of “treat others the way you want to be treated.” Little did I know that since at least 1996, we’ve had the “platinum rule”: “treat others the way they want to be treated.” I soon discovered that these two concepts of understanding and celebrating differences are extremely important, with entire bodies of literature (that as a vanilla CS major you rarely come across). Let’s just say, I was more than a little embarrassed that I had somehow missed the memo.

Since my ramblings can hardly serve as a crash course for complicated issues like diversity and privilege, I simply wanted to draw attention to the role of such subjects in engineering education at Stanford (and hopefully across the world), structured or otherwise. Further, I hope that those in positions of privilege feel equally empowered to start these conversations, without fear of “saying the wrong thing.” The prominence of the tech industry draws everyday engineers right in the crosshairs of the public debate on diversity and privilege. While tackling these issues is hardly part of the job description, I’d argue that understanding the subtleties of diversity and privilege will help me more in my role as a manager or engineer than any amount of arcane systems knowhow.


Rachel Gardner

Favorite engineering-related sources for inspiration:

Why did you choose to be an engineer?

I first tried engineering because I love math and science (thanks to some amazing teachers early on). Once I realized that I could use those skills to make cool things, I was hooked.

Class year:



Computer science

Blogger bio:

Rachel loves solving problems with computer science (and has for a while). Her main hobby is pursuing Mandarin fluency, but she also enjoys teaching, swing dancing and martial arts.