How I got to become a software engineer
I started at GitHub in July of 2019 as a technical support engineer. I had actually been struggling to complete a coding bootcamp prior to joining. After I got the job, I moved on from the bootcamp without completing the program. I felt some shame about that. It bugged me that I didn’t complete the task I set out to do. How could I be taken seriously as an engineer if I couldn’t finish a bootcamp?
I buried that feeling of shame and worked toward becoming the best support engineer I could be. I thoroughly enjoyed the work I was doing. I enjoyed my teammates even more. There was always something new to learn, especially with the growing line of GitHub features.
Even so, I always had a move to engineering in the back of my mind.
My former skip-level manager and I had a regular one on one. During a meeting, he asked me to think about what I wanted for my career in the future. More importantly, he said to be deliberate about what I was seeking. We met again about a month later, and I told him that I wanted to be a software engineer. To my surprise, he said he was happy to help me get there.
While that manager was instrumental in putting me on my engineering career path, it was the relationships I built with other Hubbers in engineering that really got the ball rolling. I started chatting with an experienced engineer, Lexi Galantino. We had conversations about my experience and what I was learning. She took an interest in my development and sought to help me move closer to my goal of becoming an engineer.
Working with the Discussions team
Lexi believed in me and my goals. She wanted to do more to help, so she came up with the idea of putting me on a trial run with the Discussions team. Lexi created a proposal which entailed me working full-time with the engineers on her team to build out a small feature within the Discussions product.
I worked with the Discussions team for about 6 weeks, with two weeks of that time on full-time engineering work. The rest of that time I split between my regular support responsibilities and the Discussions team. I was able to finish the project work earlier than the projected time, and I learned a great deal about how our engineers work together. I had a lot of fun working with the team. They really embraced me as one of them. It made me feel awesome! Shortly after the trial period was done, I was asked to apply for one of the open positions. I actually declined, because I thought I wasn’t ready to make the leap to engineering just yet.
However, after delivering that news, I spoke to the manager of the Discussions team. She told me that my personal reservations about myself were unfounded in this situation. It turns out the team really did like working with me, and they wanted me to join as a full time engineer. It was understood that I was really inexperienced compared to a traditional hire, however that was okay. This team was very senior heavy, and they wanted to balance it out with some early career engineers. I didn’t say no twice, and I began the interview process shortly after that conversation. In August of 2020 I became a software engineer at GitHub!
Working as an engineer
The GitHub Support team is full of some of the most caring, understanding and knowledgeable people I’ve ever worked with. I felt at home with this team. It was really exciting to move to engineering, but also very scary.
Prior to landing a full-time engineering role, I had a lot of negative expectations about what it would be like to work on a team with other more experienced engineers. My general fears revolved around working in a competitive, and hostile environment.
Since I started in the engineering organization, my teammates and managers have dispelled so many of my previous assumptions about what it would look like to be an engineer at a company like GitHub. Everyone I work with has been kind, and extremely helpful. They are eager to make sure I have the tools I need to become a better engineer.
Learning to work with others
There’s no detailed roadmap for someone new to engineering. There’s a lot of freedom to create your own path towards proficiency in the role, however it can be challenging to know how to move forward on projects and tasks without the guidance of more experienced engineers.
Pairing is awesome!
I aim to spend about 3 hours a week pairing with teammates and other engineers outside of my immediate team. I have found that I learn and retain more when I can discuss concepts aloud. When pairing, I am usually the driver. Meaning, I will be the one that writes the code with the guidance of my pairing partner. I find that this gets me to be more active in the development process. Things tend to go slower this way, but it gives me the opportunity to ask questions, think more deeply about the problem/task in front of me. My pairing buddy can provide guidance rather than coding everything themselves.
This pairing method took some time to get used to, as I had to get over my fear of looking dumb. My teammates have given me the psychological safety that is necessary for learning, as making mistakes and not knowing things is all a part of growing as an engineer. I like pairing with different engineers, as each one has a unique way of coaching. Some have held my hand quite a bit during a pairing session, while others will just give suggestions, hints or ask questions to help nudge me in the right direction. All these approaches were necessary in breaking through the various sticking points I have in building software.
The most important skill I have improved is getting over my fear of asking for help. It has been invaluable when it comes to improving as an engineer. I will ask questions in Slack, issues and PRs. Asking questions is a skill in and of itself. I have definitely improved in this area since I joined the engineering org.
While I do believe that you learn more by doing, reading others’ code has been a valuable experience. Reviewing code has shown me different programming patterns, introduced me to new Ruby methods, and helped me to better navigate our codebase.
What is next?
Always be learning.
I am looking forward to sharing my opinions and perspectives more going forward. There is a lot I can draw from in regards to my support experience. I have gained a great deal of confidence over the past year, and it’s only natural to feel more comfortable sharing my ideas on how we build things at GitHub.