There’s No Wrong Way to Become a Software Engineer: Part 1

Check out part 2 of our “There’s No Wrong Way to Become a Software Engineer” series.

Hi! My name is Bianca Henderson, and I’m a software engineer at Anaconda. When people think about developers, most tend to think about computer science graduates or people who are super good at math; as a single mother and woman of color who has an undergrad degree in English literature, I will challenge those misconceptions and hopefully show people with similarly unconventional backgrounds that they, too, can become software engineers if they want to!

My Background

From an early age I was interested in computers, poking around on a terminal, and playing computer games, but never really thought coding would be something I did for a living. My mother was an architect and my father was an artist/graphic designer so I made a lot of visual art, and as a bookish kid I wrote a lot of fiction, wrote poetry, and played guitar.

I got pretty good grades in high school, but unfortunately I didn’t get very good guidance nor financial support, so I had to work full-time through university to pay for school and living expenses. In order to support myself I worked as an office assistant, warehouse manager, technical writer, etc. during the day and attended evening/night classes.

After receiving my degree I moved to New York City and worked at Discovery Channel doing ad sales, and then at PricewaterhouseCoopers writing financial reports. I also worked for a couple of years as a graphic designer for D.E. Shaw & Co, a role that included web design, which prompted me to learn HTML and CSS (my first official programming languages).

Teaching Myself Python

In the mid-2010’s, I decided to add another hobby to my list and picked up Python. My goal was to create text-based adventure games and learn how to program something via an object-oriented language, just for fun. I used a combination of books and online tutorials to teach myself basic syntax and some software design patterns. During the course of my learning journey I found out about PyGame and other frameworks/libraries, and was absolutely hooked.

In 2017 I went through some major life changes, including a separation/divorce. The first several months were very difficult, as I was juggling several jobs in the retail and service industries while caring for two preschool-aged children. Things looked pretty grim for a little while until an incredible opportunity presented itself: A close friend told me about a job opening in the sales department at a local company called Red Hat. During one of my interviews there, the manager of the team said, “You’ve got Python listed on your resume. Are you interested in eventually assuming a technical role?” to which I enthusiastically responded, “Yes, definitely.” He offered me the sales job and said I could view it as a way to get my foot in the door, and that I was free to do whatever networking I needed in order to move into a technical role.

Working in Tech

Very soon after I started my new job at Red Hat, I found a willing mentor in the Ansible Tower technical support department who kindly met with me every week to give me topics to research and to answer my questions about what I’d been learning. We discussed a wide variety of subjects: operating system fundamentals, scripting, containers, different types of programming languages, and more.

After a couple of months of regular meetings, he asked if I’d ever installed any Linux distros and I told him that I hadn’t. He said, “Go install Arch Linux and let me know what you learn.” I had a beat-up old laptop at home that I could mess up freely, so as a warm-up I successfully installed Elementary OS. My confidence boosted, I uninstalled Elementary OS and attempted to install Arch Linux, which led to a very different experience! It took me a couple of hours but I eventually halfway succeeded; Arch was booting up from the USB instead of from the laptop’s hard drive. I rm -rf’ed the home drive and started over; fortunately, my second attempt was a success. I sent my mentor screenshots of Arch running, and he responded with, “Congratulations, you’ve got a job on my team doing technical support for Ansible installations.” I was absolutely elated and couldn’t believe the opportunity that had been given to me!

Learning How to Read Error Messages

Over the next 18 months I learned about the many ways that software can break, and what sorts of things tend to cause customers the most difficulty. I also acclimated to reading and parsing through error messages, which would later come in handy for me as a developer, since that’s a large part of a developer’s job. In my current role, there are some days when the majority of my time is spent figuring out where exactly something failed and reading through error messages for clues on how to fix the problem—so this was invaluable experience.

During this time I also conducted a monthly “how-to” webinar for newcomers to Ansible, since teaching is one of the best ways to learn. I had no idea what I was doing during the first couple of sessions, but over time I became more comfortable with presenting information in a “tried and true” type of way, and the monthly webinar became something I looked forward to.

Contributing to Open Source

After a year on the support team I started to feel like I was gaining enough technical experience to attempt development work. Luckily for me, Ansible is completely open source, so I filtered their GitHub issues for any that were tagged as “good first issue” (a common GitHub label that can be found on many open-source projects—it’s meant to encourage people who are new to the codebase to submit a pull request) and found a few to try my hand at.

Contributing to an established open-source project can be a crucial addition to any aspiring engineer’s portfolio. It shows that you:

• looked through the relevant codebase

• took the initiative to enhance the codebase via a bugfix, new feature, documentation edit, etc.

• successfully communicated requests for feedback and/or code reviews

• are interested in doing development work (even if you submit changes to the documentation and not necessarily to the code)

Leveraging open-source software to advance your engineering career is a win-win, since it not only gives you more experience, but also helps the folks who maintain the relevant code and associated documentation!

What Kind of Development?

Something I made sure to do before applying to a specific role was to figure out exactly what type of engineering I wanted to pursue. The main types can be broken down as:

• Front end (making applications and websites functional, efficient, and well-designed for optimal user experience)

• Back end (server-side design, building, and maintenance)

• Full stack (a combination of front end and back end)

• Quality engineering (breaking things, writing CI/CD pipeline tests)

With my background in graphic design, most folks thought I would do best with front-end engineering, but I wanted to see for myself so I did extensive research on what problems each type of engineer has to solve, and I made sure to dabble in some front-end languages such as JavaScript to see how it felt.

After months of shadowing different engineers and reading their code, it became clear to me that back-end work was the most “puzzle-y” (in my opinion), and since I love logic games and puzzles, it was the best fit for me. Understanding this was a huge boon to achieving my goal of working as a programmer.

Working as an Engineer

Towards the end of my research phase, I saw that a developer position had opened up on the API/back-end team for Ansible Tower, so I updated my resume and wrote a cover letter that included links to my previously-completed pull requests and the reasons why I wanted to contribute to the team as a junior developer. I went through a couple of interviews that mainly focused on the pull requests I had submitted, what I knew about the codebase, and how I approach/think about problems, and I got the job in March of 2019!

Since my ultimate dream was to work in the field of data science/machine learning/AI research, after several years at Red Hat Ansible, I decided to apply for a role as a software engineer at Anaconda in late 2021. I’ve been working here since December ‘21 and I love it; the company culture is wonderful and I still get to be involved in the open-source ecosystem and community!

Learning on the Job

One major point I want to make is that no matter how thoroughly you’ve taught yourself to program, no matter what you learned in boot camp or while obtaining a computer science degree, you will learn way more in six months on the job than you can via years of self-teaching. This is because there are walls that come up in programming work. When you’re working on something on your own, you can make decisions to drop a particular feature or use any framework/library that you think would be best. When you’re doing this work professionally as a junior dev, however, you have to see a task to completion without necessarily being able to decide how to design it. As you gain experience, you will contribute more and more to the decision-making process as well as the code, but until then, you have to learn to deal with repeated frustrations and roadblocks until you figure out how to get something right.

Ideally, you’ll be working on a team with devs who are more experienced than you. The “banging your head against the wall” situations are perfect for asking lots of questions (no matter how “stupid” you think those questions might be!) and reaching out to teammates to get some pair programming scheduled. Learning in a vacuum is inefficient and can be harmful; make sure you incorporate lots of diverse viewpoints into your problem-solving approach, and over time you’ll naturally develop your own styles and methods.

Be prepared to feel like you never know enough about anything. Being a developer is less about knowing the answers right off the bat and more about being curious and driven to learn and teaching others what you’ve learned and how to make processes easier.

Conclusion

That’s pretty much my story of how I grew into my role as a professional developer, against all odds! It took a lot of studying, determination, and relationship building. My job is incredibly fulfilling and I love that I learn new things every day with each new bug I fix or feature I work on.

If you are reading this article as an aspiring developer, know that you can do it, and know that you don’t have to enter the industry via “traditional” methods, whatever you think those are.

Key Takeaways and Advice

Here’s a TL;DR for folks thinking about getting into programming:

• Consider every opportunity that comes along, even if it’s not exactly what you think you’re looking for—especially if you don’t have prior experience. I started in a sales role at a tech company then moved into engineering; a move like this is a slower process, but you will learn a lot along the way. Every doorway that opens is worth peering into to see where it leads. Some people hold out for their dream role, which can actually take much longer than assuming a role that isn’t the exact one you were looking for.

• Create a GitHub account! Fork any repository that you find interesting, and don’t be afraid to feature anything you create on your profile—whether it’s based on a tutorial or it’s code you generated yourself from the ground up.

• Leverage and contribute to open source! Remember, everything you do that is visible via GitHub can be part of your portfolio.

• Ask people who are already in engineering to be your mentors. You don’t need to stick with just one mentor; you can talk to multiple people regularly, and learn many different approaches and methods. This is a great way to figure out what your own style is, and to develop it with confidence as you receive regular feedback.

• Get comfortable with imposter syndrome! Even the best and most experienced engineers suffer from it; it’s a sign that you’re constantly learning. Everyone gets stumped on a regular basis, but with time and experience you’ll be able to recognize repeated patterns and solve problems more quickly and naturally.

• Give your brain regular breaks so that it has time to process what you’re learning. If you find yourself hitting the same wall over and over, stop thinking about the problem. It’s counter-intuitive, but often the solutions will come to you during these breaks.

• If you identify as a member of a group that’s underrepresented in tech, make sure to find coworkers and community members who identify similarly and be supportive allies to each other. There will be times when negative interactions happen or identity-related self-doubt creeps in, so make sure you surround yourself with kind people as much as possible! If there isn’t an established group that is accessible to you or others in your role, consider starting one.

• Teach what you know—it’s the best way to learn and grow your skills, and it’s also a great way to see the progress you’re making.

• You can’t rush learning. Take your time and try to enjoy the journey!