One of the things I always love hearing about is how a person made their way into tech. I started programming in elementary school, designing Xanga and LiveJournal sites for my friends. I took my first programming class during high school, and continued to create small websites for my friends and family. When I graduated from college, I joined an agency, Think Shift, where I met my first boss and mentor, Balaji Krishnamurthy.

While working with Balaji, I asked him if I could take on a weekend project to improve our company website—I was in a non-technical role at the time. He said, “Why should it be a weekend project? Let’s reshuffle your work and you can start it next week.” It was a small act, but Balaji was the first person who said, “Yes. Absolutely, you should do this.” I got to work building a new company website, by myself. It launched three weeks later.

Prior to meeting Balaji, I experienced a lot of small, subtle pushback when I showed an interest in computer science, both throughout high school and college. Much of it came from well-meaning people who thought they were helping me. I vividly remember when I was 16, my family moved from Kansas to Ohio and I transferred to a new high school. On the first day, I attended a programming class I had enrolled in and while I was trying to figure out the new desktop environment, the teacher pulled me aside and said, “I don’t know if this class is the right fit for you.”

I wish I could say, as a 16-year-old, that I got in her face and told her off and that I stayed in the class. But instead I left the class, stood in the hall for an hour staring at my shoes, and transferred out. Having Balaji assume my competence was a meaningful change. It only took one “yes” for me to charge into my first paid technical work.

Encouragement and discouragement can come in subtle forms—and over time, those nudges can add up and push you onto different paths.

Finding the right ladder to climb

After several years, I became a director of our consulting business at Think Shift. It was a fantastic job with a lot of responsibility—I flew across the United States and Canada at least once per month, had profit-and-loss responsibility for my department, and a book of clients I managed. However, on nights and weekends, I was coding side projects and attending technical workshops.

Around this time I joined Women Who Code Portland—a fantastic Portland community that I can’t recommend enough to people looking to grow their tech careers. Women Who Code Portland’s director, Caterina Paun, warmly welcomed me in as a volunteer, and soon I became one of the technical leads. As much as I loved both my business consulting work and my technical volunteering, it became increasingly clear that the paths were diverging, and I would need to dedicate myself to just one path in order to excel at it.

I built up my savings, and finally took a risk and left Think Shift in early 2017 to attend a full-time programming bootcamp. I graduated in June of 2017. While interviewing for my first tech job, I spoke to Dana Lawson, InVision’s then Director of Platform Engineering, and she invited me to interview for an internship position at InVision. I joined InVision as an intern in August of 2017. Two months into the internship, I went full-time with InVision as a software engineer.

The team I joined at InVision was building an app called InVision Studio, which used a framework called Electron. Electron allows you to build desktop applications using web technologies. As an example, let’s say you want to build a desktop application that you can install and run on Mac, Windows, or Linux. You can do it quickly and easily with Electron. It’s a versatile technology, but it can also be complex, particularly if you’re a new engineer. 

In an effort to learn more, I asked my friend Alice Goldfuss to introduce me to Jacob Groundwater, the Microsoft manager for Electron. Within a few hours, he sent an invitation to their maintainer Slack channel, and the community was very welcoming and responsive to my questions. 

The Electron maintainers and community were very helpful to me as an app developer. After a few months, I wanted to make sure that I was also giving back to the project itself, beyond just the contributions for my own app. I mentioned this to Jacob, and he strongly encouraged me to become a contributor. I was intimidated by the codebase at first—I knew I could deliver immediate value doing work like organizing events and writing release notes, which is where I started. But as I became more familiar with the project, I started fixing bugs, asked if I could help run a stable release, and then continued from there.

Jacob recognized my strengths and knew when to push me out of my comfort zone and deeper into areas I wanted to pursue. I think Electron owes a lot to his leadership and the inclusive culture that he’s helped create within the project.

I became a senior engineer at InVision in the fall of 2018, partially because of the leadership role I had taken in our company’s Electron upgrade processes. By December 2020, after nearly a year working with the Electron community, Electron’s Slack manager at the time, Felix Rieseberg, asked me to join their team as a full-time employee. I was overjoyed. I love my current team at Slack; it’s truly a dream job.

A lot of people—Balaji, Dana, Jacob, and Caterina, along with countless others—extended a ladder for me to climb up, and it changed my life. I want to lower that ladder back down and give others the opportunities they can use to make their own place, both in tech and in open source.

Equalizing roles across OSS projects

Non-technical contributions are important and foundational to projects, and to tech itself. The work needs to be done, but oftentimes it’s under-prioritized or there aren’t people who volunteer to do it. The people that do volunteer often come from marginalized backgrounds. 

People can take this work for granted, even though it requires a very real skill set. So if you’re a marginalized person doing work that is important but under-valued—even if others recognize that it’s valued incorrectly—you risk getting trapped in a self-perpetuating cycle. 

Electron has a strong Code of Conduct and multiple governance groups that run various aspects of the project. We try hard to be welcoming and accessible to new contributors. But Electron can be an intimidating codebase to break into, even if you’re an experienced developer. When I started trying to contribute back to the project, I volunteered for less technical work to start: helping to organize a maintainer summit, gathering release notes, and writing blog posts. This was work I had also felt comfortable doing prior to becoming an engineer.

Jacob was actually the one who called me out and made me think about where I was putting my time. Essentially, if you want to do this work as well, great. But make sure you’re not falling back into it when there are other areas where you can provide value as an engineer—especially if that engineering work is the work you want to be doing.

When people who are new to tech ask me how they can start working in open source, it can be hard to know how to answer. Non-technical work was how I started contributing to Electron before submitting code, and I want to be honest about that when I give others advice.

There's so much advice out there for people getting started, but I think we as maintainers need to try to take responsibility for helping new people get started and respecting their contributions, whether it's code or otherwise. If you’re part of an open source project and a newer contributor is working on non-technical work, actively recognize that person and make them visible. Then check in with them periodically to make sure they have a path into other possible ways they might like to contribute. That’s what multiple Electron maintainers did for me, and it’s what I try to do now for others.

Paying it forward, and paying for good work

I’m fortunate to work with a lot of smart people and I don’t need to be the smartest person in the room, but I do strive to leave a positive impact. It’s easy to focus on gaps in your knowledge—especially if you’re moving into a new knowledge area—so having others help you find that path is immensely valuable. That’s how I approach my job right now. I’ve worked hard, but I’ve also been very fortunate, and I owe it to others now to pay that forward. 

For their part, enterprise companies should be paying people to work on open source. Slack has tremendously benefited from having an Electron-focused team, and the product is better because of it. Electron, as an open source project, is healthier because they have an enterprise company dedicating resources to it. In this way, the company, Electron, and the open source community overall benefit. We will see better open source software if companies consider it a stewardship responsibility to pay people for it. 

It’s important too, that enterprise companies value the integrity of the project itself. Even on our Slack team, when we make a change to Electron, we ask if it’s good for Electron first. There’ve been times where there were things requested for a specific app, but we recognized it wouldn’t be as good for Electron as a project. You need people on your team like that, who put the project first—and they should be paid for their time. 

Before I was in my current position, which I’m very fortunate to be in, I was working as an Electron contributor, but I wasn’t paid for it. I worked in my free time and had a full-time job outside of that—and it got overwhelming. But that was my entryway into open source, and I’m grateful for the welcome I received from the Electron community and the mentors who encouraged me along the way. With time, I hope there’s a shift in how we think about maintainership, funding, and the benefits of enterprise companies showing up with their wallets as the stewards for projects from which they benefit. That’s the level of positive impact we should all be striving for. I want to see people paid well for fulfilling work.