Opening the Tech Pipeline to Non-Developers

Coding bootcamps and similar programs geared towards career changers often focus exclusively on guiding people towards developer roles, usually without educating these new developers on the engineering ecosystem and the other roles that interact directly with the products being developed. These include QA engineers, product managers, project managers, user experience designers, software architects, and technical writers, to name a few. Software developers are a vital part of the ecosystem, yet they are not fully representational of the entire tech ecosystem, and focusing narrowly on a subset of (albeit important) skills and roles diverts talent and resources from other positions that require different sets of skills.

Conversations of coding, developers, and building websites had always sparked my interest, but it wasn’t until I was laid off from a job in communications that I took up the opportunity to learn to code with a friend. It was fun, it was challenging, and it was jarring most of the time, but as the weeks turned into months – and with the possibility of becoming a junior web developer periodically appearing in the horizon – my desperation to move past a career that I believed was undervalued and underpaid into one where I could get gainful employment meant I was grasping desperately onto the belief that the only way I could get into the tech industry was by “mastering” code. Yet, the more I tried to “master” it, the more elusive any hope of getting solid footing in programming became. I felt like I had failed and began to question – along with others – whether or not I was suitable for a career as a developer. That sounded more like the death knell of a dream than an invitation to explore other options in tech that would actually suit me better.

Photo CC-BY Pedro Ribeiro Simões, filtered.

It’s Not All In Your Head

Just in the last two months, I started identifying the specific attributes of software development that inspired me to become a developer, what my interests and passions were, and where my growing involvement in the community was taking me. It became clear that while being a developer would fulfill my desire to solve problems, a growing part of my motivation came from feeling it would give me more “credibility” within the tech community – that I was only worth being listened to if I was a developer, and that I would only be respected if I was one.

It’s a nagging feeling that is far from irrational: beliefs around the values of non-technical employees inform how they are treated and viewed in comparison to their developer colleagues. Resources allocated to the professional development of engineers, and other opportunities that increase developer happiness, already exist at many startups including my own. The same cannot be said for the majority of non-technical employees at those same organizations, where such opportunities are granted either on a case-by-case basis, or vary greatly between different non-technical teams: for example, I once had to ask for another team at my company to fund a trip to a tech conference as my team didn’t have it in the budget.

Women in STEM-related fields report experiencing the effects of “imposter syndrome”, as well as falling victim to subversive microaggressions such as being viewed as less knowledgeable in their field, being assumed to work in an administrative role or worse – in the case of Latinas and Black women in the sciences, getting mistaken for members of the custodial staff, and given menial tasks compared to male colleagues. My first tech-related gig came about as a teaching assistant in a ten-week Ruby and Ruby on Rails course and I was the only woman on the three-person instructional team. It became apparent very early on that some students didn’t see me as being on the same level as my colleagues. One male student said no more than three words to me the entire ten weeks; he wouldn’t call on me when he had questions, and he wouldn’t even acknowledge that I was in the room.

I realized what was happening only on the last day of the course, when he very publicly thanked the other two male instructors by name for teaching the course, even though I was very clearly a part of the team and had been there the entire time. I internalized what he said and attributed it to my lack of experience, but the other male teaching assistant had roughly the same amount of programming knowledge as I did, and the student feedback we received at the end of the course did not indicate that any of the students thought I came across as less knowledgeable whatsoever. It was simple – I wasn’t a developer and I was a woman. From this point, I’d ascertained that I would be taken more seriously by peers and the rest of the tech community only if I became a developer, a belief that carried over as my involvement in the community grew.

Fork The Road

Photo CC-BY Miguel Virkkunen Carvalho, filtered.

Yes, I eventually made it into the tech industry, but not quite the way I’d imagined: I was working in operations. I enjoyed helping beginners learn how to code, and believed my involvement with the developer community wouldn’t extend beyond that. Yet after attending a community event — unique among conferences for being an exceptionally supportive and safe space — my passion for tech was rekindled, outside of the promises of making a quick buck, of being a part of “cool” startups, or other such golden carrots dangled to get people interested in development.

After I returned from this conference, I spent more and more time getting to know the community, attending other conferences, and speaking at panels and events, all while thinking about how I was going to actually get my first development job. I was mostly self-taught. Seeking the guidance of other developers, I was assured that while it was difficult, it was possible. When I received my first code challenge, I enlisted the help of a friend who tried to guide me through the difficulties of the problem while others told me that a code challenge like that made no sense. For the first time in years, I became depressed. I felt scared, unsure if I would ever “master” this, unsure if I was even “right” in becoming a developer. After a few weeks of working on it, I got in touch with the company that sent me the code challenge and told them that I’d hit an impasse.

After the coding challenge episode, I stopped coding, attending tech-related events, writing about tech, and engaging on Twitter to focus on self-care. Life slowed down and I was able to pull apart what I had experienced up until that point. All of my creative energy was spent on writing poetry and rediscovering the things that I enjoyed away from the external distractions and internal pressures to always “be” something.

I knew that being a developer wasn’t the path for me, but I didn’t want to give up on tech. It was around this time that the idea of becoming a technical writer fully materialized. I’ve been writing for years, and the time I’ve spent with developers made it very clear that I want to work alongside them without doing exactly what they do. What I enjoyed about being a teaching assistant for two years, and learning to program in general, was the ability to break down complex problems and find ways to communicate the solutions clearly and concisely. A technical writer does just that. The idea of doing it was extremely exciting; finally, I’d happened upon a technical career that fit me perfectly, and I felt encouraged by the tech community as a result. Just recently, I crowdfunded the cost of books and tuition for an intro to technical communication course on Twitter and will be helping the Bundler team rewrite their documentation. Being able to do this is far more exciting, and far truer to who I am as a person, than trying to force myself to become a developer ever was.

Owning your interests and giving yourself the permission to want certain things, and not others, is key. I thought learning to code was in vain if I didn’t “see the dream through”, but just last August, when speaking to a group of high school girls that were largely of color, I explained that programming skills can be used across many roles, technical and non-technical alike. I was the only non-developer invited to speak to them, and I knew that by limiting the conversation about programming to mean engineering exclusively, we were doing these girls a great disservice. Because the truth is not all of these girls will go on to become engineers, and we shouldn’t inadvertently give them the message that they have failed and there’s no space for non-developers in tech, simply because we didn’t care to present them with other options.

In Conclusion

Photo CC-BY Jeffrey Beall, filtered.

Inclusion extends into treating both non-technical roles as well as technical, non-developer roles as equally valuable and instrumental in the industry’s growth. Programs that teach people how to code should educate their students about what engineering teams look like beyond the developer, instead of giving a narrow and incomplete perspective. Many engineering teams have championed the employee in the way of giving engineers access to resources like professional development budgets, flexible work hours, etc. in a way that other teams in the same organization may not. An appreciated employee is a happy employee. Treating other members of the engineering team and non-technical employees with the same amount of respect makes sense. Companies need more than just developers to fully function, and this also has the added benefit of making members of underrepresented groups feel that there is a place for them in the industry.

Am I allowed to say I work in tech even though my current role is non-technical? The answer is unequivocally YES.

It took a crowdfunding campaign and engaging with techies on Twitter on a wide array of subjects to make me finally come to the realization that I have something very valuable to offer the tech industry. Opportunities have found their way to my doorstep and I don’t attribute them to luck anymore. This past March, I was asked to be one of the keynote speakers at Open Source Bridge in Portland. I couldn’t believe that I would be asked given my mostly non-technical background, but I knew that I had something to offer the community.

“Work” in tech should not be limited by the amount of code you can produce – though you’re welcome to check my GitHub if you’d like – since it takes so much more to keep the industry running and functioning. Everyone who wants to learn to program should absolutely be encouraged and provided with the resources to do so. Let me be clear – I still want to code and build things, and I will. I’ve become more interested in open source and have found an outlet to continue coding that way. I have a newfound appreciation for programming and have found a way to keep it in my life without it coming at the expense of the other skills and interests I possess.

Let’s just start thinking outside the box and allow people the opportunity to enrich the tech industry with their newfound programming skills and the skills they already possess. And if you’re a developer? Don’t try to do it all yourself. I may just come after you if I see your documentation is a hot, incoherent mess.