I was a history major, but my first job out of college was in the buying and planning department at Macy’s. There were lots of spreadsheets and customer reports, and I loved to tinker and build things from scratch, which flipped a switch in my brain. I had taught myself the basics of JavaScript, HTML, and CSS, and I realized I could make this my full-time gig. 

I quit my job, moved out of my apartment in New York City, moved in with my boyfriend (now husband), and committed myself to give every ounce of energy I could to navigate this transition. My parents thought it was a big risk, but I had conviction in this idea. I completed a bootcamp program at Grace Hopper Academy, then applied what I learned to build my own projects and get involved in open source.

This was before bootcamps of varying quality saturated the market, leaving some graduates unprepared and ultimately giving bootcamps a bad rap, so I was able to get a job quickly. I know folks entering now aren’t always as lucky, especially with the pandemic. It was definitely a wild ride, but I’m so happy I went down that path and took a risk because I’m so much more fulfilled and have had such great leadership opportunities. Now that I manage my own teams, I want to give back and be a champion for new developers and empower those who may not follow the traditional tech path to succeed.

Finding open source through soccer, and the power of creativity

I discovered open source software as an engineer at Major League Soccer. Our team was pretty small, but we worked with bleeding edge technology. Using React Native, we were able to build a real-time match experience for web, iOS, and Android using a single code base. I was inspired by our work and wanted to share it with the broader open source community.

Encouraged by my teammates to contribute code and content, I found my niche helping simplify things for folks who were newer to the libraries and tools I used. The more I did, the more I learned, and the more people I met. Then I found my way to nteract, which was a really great open source project to get my feet wet: I worked with Safia, who’s absolutely fantastic, and everyone was welcoming, inclusive, and encouraging. I worked on that for about a year, and it led me to Apollo.

Entering the software development community through this path took a lot of hard work and a commitment to lifelong learning. But folks coming from untraditional backgrounds have so much to offer the tech industry. Even though I’m not a computer science major, I’m great with words—probably better with words than code—which is why I’ve found myself in my current role at Apollo. I wish folks could see that programming is so much more than math and science skills. It’s about creativity and structuring things logically and making them human-readable so others can contribute.

Helping developers help the world 

At Apollo, our team’s mission is to inspire and equip developers everywhere to be successful, which we tackle in a number of ways. Our education team builds our interactive learning platform, Odyssey, educates developers at scale, and ensures our docs are delightful, easy to use, and complete. DevRel is out there in the community: They listen to the developers’ pain points, and then craft code or content to solve them. Since events took a back seat with the pandemic, everything happens virtually, so we have the newly created video team and have invested in YouTube to show developers how to use Apollo through a really rich, interactive medium. I manage the leaders of those teams and no week is the same. 

I love that Apollo is an open source company, which means open source is at the heart of everything we do, and we have such a passionate community of tens of thousands of developers. We wouldn’t be here without them. When I joined the company, it was actually called Meteor and Apollo was a very small team. As adoption grew and we eventually built our SaaS around it, we pivoted, but we would not be here today without the Apollo community.

We’re all about helping developers get their ideas out into the world faster, and we help them do that with the graph. The graph is a layer that sits between your UI—for example,  your web, mobile, or IoT clients—and your services, which could be REST endpoints, databases, or gRPC. If you didn’t have the graph, you have these point-to-point APIs. So for each client you support, you’d have to write that data-fetching code which leads to a lot of duplication. When you have the graph as one window into all of your data, services, and capabilities, it gives you one complete picture and reduces the amount of code you have to write at the same time. We’ve found that developers building apps with Apollo can delete data-fetching code and support multiple clients much faster than before. 

I’m so motivated to help developers discover that spark where they understand the power of the graph and can ship their apps so much faster. I want to bring that to every developer in the world. 

The way it should be for open source developers

We all know Fortune 500 companies use open source libraries. Then one of them has a security vulnerability and you see what’s behind the curtains—and it’s often a solo developer with no external help keeping the lights on. Meanwhile, the Fortune 500 companies aren’t paying a dime. There needs to be more financial incentives for maintainers. Otherwise, you’re going to continue to see a very cis, white, male-dominated demographic.

This may be slightly controversial, but I think it’s a privilege to assume that everybody can contribute to open source forever, especially folks belonging to underrepresented groups in tech. They may not always have the opportunity or time, especially if they’re not doing it in their day-to-day job. Especially new mothers, for example, or folks who have responsibilities, like taking care of family members or friends or partners who are ill. We don’t know someone’s circumstances and that ebbs and flows throughout a person’s life.

Open source is always there for you when you want to return, and the relationships that you build in open source continue to persist even long after you've left the project. As a maintainer, it’s frustrating when somebody you onboarded as a potential maintainer and worked with for a year has to leave the project. But that’s how tech is: It’s cyclical. You’re not going to work on the same thing forever. And no matter what your life circumstances are, I think you can always come back to open source and take what you've learned since then, and then apply that to something new.

Everyone’s journey is valid and valuable

I have experienced sexism and the microaggressions of somebody interrupting me in a meeting or downplaying my contributions. I’ve also had more one-offs, like someone groping me inappropriately at a conference or conference organizers using my image in a sexist way without my consent. It was all difficult, and I’m thankful I had a strong support system and people who stood up for me, got me out of harm’s way, and supported my decision to pull out of that conference or disengage with those community members. 

The further I move up in leadership, the less I’m subjected to these kinds of experiences. But this still happens all the time to women, Black people, LGBTQ folks, and many other engineers belonging to underrepresented groups. When we see harm happening in our communities, we must deal with it swiftly and prioritize the feelings of the person who was harmed over the person doing the harm. Our communities need strong codes of conduct that we restate often, in person or virtually, and ensure there is a clear reporting policy.

As community leaders, we have the potential to create more harm than good to other minoritized groups. If you do, it’s so important to recognize what happened, apologize, and say exactly how you’re going to fix it. Then, back it up with action, and do better. It goes both ways and I’ve experienced both. It’s really important across the board to prioritize those who are vulnerable and ensure we create safe and healthy spaces for our open source communities to flourish.

Over the next 10 years, I’d like to see more representation across the board: more leaders of different gender identities, races, and abilities. Unfortunately there’s a culture of hero worship in open source. Often, the folks we put on a pedestal and celebrate are the ones we’ve celebrated for decades. So we need to create more opportunities and space for folks of different backgrounds to excel and thrive. 

We also need to recognize all types of contributions, not just code. It’s really easy to get hung up on GitHub profiles, but a lot of things that go into managing an open source project aren’t recognized on the contribution graph. You have designers who get involved, and folks giving workshops or talks or just helping other community members. That’s not reflected on the contribution graph. Let’s recognize that all contributions are valid—and you aren’t defined by the squares on your GitHub profile.

Everybody has their own experience, background, and unique gifts to bring to the table. Even though I might not have had someone’s exact path, I have experiences that make me different and special. Regardless of our journeys, all of us can learn from each other, which is what open source is all about.