When I finished undergrad, I was lucky enough to land a job as a software tester at a local biotech company.
I came in as a junior QA engineer who was eager to learn, and because I lacked confidence in my programming skills, I did most of my work manually.
After spending time with the software developers on my team, I started learning about software engineering and design. I eventually applied these principles to my daily responsibilities and became a software engineer in test, which was a role where I got to write test code and build automated test frameworks.
That role was my first taste of software development, and over the next three years at that company, I fostered a passion for building things with code.
I then decided that I wanted to switch from QA/test so that I could build customer-facing applications. This is because I found that the work my company was doing with its software products to be more interesting and challenging than the development work I had been doing in test.
I want to share some tips and advice that I wish I had when I was first interested in changing my career. I especially hope that this post will be useful for any who are currently in QA/test roles and are interested in learning more about software development opportunities.
Here are three actionable tips:
Pair up with someone who can show you the ropes and give you a new perspective. Whether your mentor is a software developer or hiring manager is not important – what you want is to build a relationship with someone you can trust to provide you with honest and insightful feedback.
Having an internal mentor was crucial in helping me switch to software development.
My mentor was a manager of another software test team, and he had seen many software test engineers go down the path I'd hoped to take.
He advised me on the best ways to explore development opportunities at the company, while grounding my expectations with what he had seen in the past. He also expanded my network by introducing me to software developers that were generous enough to assess my technical skills and offer advice on how I could improve.
Most importantly, having a mentor meant that I was building a support network at the company. When the time came for me to apply to developer positions, my mentor and the software developers that I had interacted with could vouch for me. An internal job transfer is different from a new hire – you can gain a step up over external candidates if you have established a good reputation at your company.
If your company has internal networking or career building sessions and opportunities, I think that's a great place to start! You can meet people in different organizations, and these are the perfect settings for asking questions and finding a more structured mentorship process.
If that's not accessible to you, or if you're like me and prefer something more informal, then no worries! You'll likely find mentors all around you. The best mentors I've had are people who I naturally get along with and who inspire me in some aspect of their profession. Start a conversation with a potential mentor or ask if you can pick their brain over coffee/lunch. You can go from there and see if they're available to meet with you on a more frequent basis.
Whichever mentorship route you prefer, remember that you are building relationships and that this takes time. It will be worthwhile, as having a professional mentor can enrich your career.
Being a software developer means that you're continuously learning, and what better way than to learn by doing!
For me, the first step was learning how to apply software automation to my daily responsibilities.
When I was a test engineer, I was responsible for running regression tests for every product release cycle. The test suite featured hundreds of manual tests that grew each release, and they were painstaking tasks like opening text files after performing specific workflows and verifying the right data was there.
I automated a good portion of those tests, and by doing so I had saved myself a lot of time. More importantly, I picked up some valuable developer skills such as:
- Writing tools to eliminate repetitive work
- Developing automation frameworks and libraries that could be shared with others
- Learning best practices for writing tests
When you take an automation-focused approach to your test role, you are sharpening your coding skills by solving problems programmatically. If you don't know how to code, automation is an excellent way to learn – plus, when you are done you will have built something of value that you can share with others!
A great place to start is to find a task that is worth automating. Draft a list of manual tasks that you think would make your life easier once automated, and then pick one to work on.
For which tools and programming languages to use, I recommend choosing the tech stack that fits your company. This means if your company is primarily a .NET shop, you'd probably use C# to implement your automation.
When your goal is to explore development opportunities at your company, there are a lot of advantages in implementing your automation using the company's stack:
- You can leverage existing libraries/codebases, which will cut down your implementation time.
- Developers can provide guidance on the technology stack and review your code.
- Your tool/automated scripts are more likely to find more users, contributors, and maintainers within the company.
Ultimately, these benefits will sharpen your skills, increase your visibility at your company as a software developer, and integrate you with the developer community.
I knew that I could and wanted to be a software developer when I merged my first commit to a production codebase.
Contributing to that codebase not only helped me build serious momentum and confidence in my development skills, but also built confidence in the dev team that I could add value as a software developer. By the time I had applied to switch to a developer role, I had established a body of work, as the bug fixes and features that I was responsible for were running in production.
I acknowledge that I was really lucky in being able to work on another team's codebase and that this option is not accessible to everyone.
If you have career development initiatives at your company like apprenticeships or rotations on other teams, these are excellent ways to gain experience in contributing to a production codebase.
Another option is to see if you can devote time outside of work to contribute. This is more difficult than finding a formal rotation, because you will have to:
- Find a team that is willing to work with you so that you can contribute to their codebase
- Ensure that you aren't stepping on your manager's or anyone else's toes by doing this work outside of your normal work hours.
Having to spend time outside of work to contribute to a codebase is a sacrifice of your personal time, and I would only suggest this if your circumstances allow you to do so. I would also recommend thinking of your off-hours work as an informal rotation, which means that there's a start and end date in mind. Ultimately, moonlighting as a developer for other teams is an unsustainable long-term solution, so you want to be intentional with the time you devote to it.
Formal rotation or not, the good news is that a lot of developer teams are happy to have more help and have a wide range of development work available. I would start off small by seeing if the team could pick out a good first issue/bug for you to work on, and then you can go from there and move on to more substantial work as you gain confidence.
Thanks for reading!
These tips are what I wish had known when starting out, but it's important to note that a career change looks different for each person. I hope this post can serve as a starting point for those who are interested in getting into software development at their company.
If you have any questions, want to keep the discussion going, or just want to say hi, feel free to reach to me on Twitter!
Many thanks to Undraw for the cover image!