I decided to dedicate a whole chapter to this topic because it’s one of the most common questions I get asked. Making the transition from QA or some other technical role to being a software developer can be extremely difficult.
I made the transition myself—in fact, I had to do it twice.
The first time I made the transition was when I had just started out in my career.
I had been a self-taught programmer and had taken a year of college in a computer science program, but I couldn’t find a job as a programmer, so I started a job doing QA as a contractor for HP.
Initially, my job was brainlessly simple.
I’d go through stacks of printed tests, which were compared to a “master” printout that had already been flagged, and I’d look at the differences to see if they were known issues or new bugs that had been introduced in the latest printing firmware.
The job was pretty boring.
We were just supposed to look at flagged differences and decide if they were a big deal or not.
I wasn’t happy with that. I wanted to know what caused the differences, so I started digging a little deeper.
I asked to have access to the actual print instructions which were sent to the printer for each test.
The print instructions were either in PCL or PostScript, two popular printing languages.
I spent my own time and any downtime to learn both PCL and PostScript.
I became an expert in both.
Then when I looked at errors, I would go through the printer test and modify them, using my understanding of the printer languages to test my theories about why specific printer language commands were causing the problems.
Pretty soon I was filing detailed bug reports with snippets of printer code, indicating exactly what printer language commands were likely to be behaving wrong and causing the errors.
It didn’t take long before the software development team became interested in pulling me in as a resource to show them how and what I was doing and for me to do more of it.
I was eventually asked to write printer tests, and thus I officially became a programmer and got an actual programmer title.
Later in my career, I went through a similar experience when I couldn’t find a software development job and again found myself at HP, this time in the role of a QA test lead.
This time, I was sitting next to a fairly new software developer who didn’t have too good of a grasp of C++.
When we’d chat about some of the problems he was facing, I’d come over to his cubicle and give him some tips and help to get his tasks done.
I didn’t take any credit and only tried to make him look as good as possible.
After a few weeks of this, he started telling his boss how much I knew about C++ and how it seemed like a ridiculous waste to have someone who knew this much about software development writing test cases.
When a big deadline came up, the software development team asked to borrow me as a resource to help meet the deadline.
Once I was working with the development team, they didn’t want to give me back. Thus my role was switched to software developer once again.
The Biggest Hurdle You’ll Face
Perhaps the biggest hurdle you will face in switching from QA or some other technical role into software development is the perceptions people have of you.
Once you have a role within a company, people tend to always see you as that particular role, regardless of your skill set or how you grow.
In the software development world, in particular, there is usually a sharp distinction between software developers and testers (or QA).
Because of this bias, coming into a new company as a software developer is often easier than transitioning to a software development role from being a tester or other position.
This can be extremely frustrating—especially if you’ve outgrown your previous role.
You will have to be patient, and realize that although it will take time for perceptions to change, they eventually will.
The more you can involve yourself in the software development side of the organization and take on more programming tasks, the more that other people in the organization will start to see you in the new role.
Sometimes, though, you may have to move to a completely different company to escape the box you’ve been put into.
Let’s talk now about some strategies other software developers and I have used in the past to make the transition from a non-developer technical role to software developer.
Make Your Goal Known
My first piece of advice for you would be to go ahead and make your goal known as widely as possible.
Let your coworkers know that you are aspiring to move into development.
Ask for a meeting with your boss or manager, and frankly tell them that you’d like to move into a software development role and that you are willing to do whatever it takes to get there.
When you talk about this goal with your boss, make sure you discuss how your testing background will benefit the company when you eventually move into a programmer role.
Talk about the benefits your company will gain from you making the transition.
The more it is known that you want to move into a software development role, the more you’ll start to chip away at the bias people might have about keeping you in your current role, so don’t be afraid to openly talk about it.
But talk is cheap.
If you keep saying that someday you want to become a software developer and you aren’t doing anything about it or learning programming, you are going to sound like a hopeless dreamer.
Make sure you back up your talk with action.
When you do have this conversation with your boss, see if you can get a list of requirements or a course you can take that will move you from your current role to one working as a software developer.
If you can nail down a list of things you need to learn or milestones you need to achieve, you can create a much more solid case for making the transition, when you are ready.
I’ve used this exact technique to not only switch into new roles but also to get promotions.
I’ve simply asked what I would need to accomplish or what skills I would need to improve to get a promotion, then I’ve gone and done all of those things and asked for the promotion.
It’s not foolproof—you could still be denied your request—but if you’ve got a list of what you need to do and you’ve done it all, then it’s pretty difficult to form a case against your advancement.
Ask for Opportunities
If you really want to move into software development, don’t wait for someone to hand you the title and assign you work. Instead, ask for opportunities to do some programming even while you are in your current role.
Ask your boss for one or two simple assignments.
Ask if there are any bugs you can fix.
And keep asking.
You may be refused the first few times or it may seem like too much of a hassle to assign you a task that someone is going to have to explain to you how to do, but if you are the squeaky wheel and you keep asking, there is a good chance you’ll eventually get something thrown your way—even if it's only to shut you up.
Make Your Own Opportunities
Sometimes, though—quite often, actually—you are not going to get opportunities to do software development, even if you ask.
Like I said, it might be because explaining a task to you would take more time than it’s worth, and most projects are always behind.
It might be because, frankly, your boss or coworkers don’t believe you have the technical chops to take on software development work because they see you as “just a tester” or “Linux admin” or “technical support person,” or whatever it might be.
You might have to make your own opportunities.
You might have to take it upon yourself to look for areas where you can help out and contribute without getting in anyone’s way or taking up their time asking questions.
Often these opportunities lie in what I call the “dirty work.”
That is the stuff that no one wants to do.
It’s the coding equivalent of cleaning the toilet.
Perhaps it’s debugging this really nasty bug that no one has been able to figure out.
Perhaps it’s writing up documentation for an API or building a tool to make things easier for everyone else.
It’s probably going to be the boring work that is difficult, but if you want to find a project that no one will fight you for, it’s likely to be “dirty work.”
Be ready to roll up your sleeves and dig in.
Use Your Own Time
Some bosses might assign you some small programming tasks you can do as part of your regular workload.
Some bosses might be ok with you spending some of your time picking up the “dirty work” kind of projects I mentioned above.
However, that will not always be the case.
In fact, in many work environments, you are likely to get a slap on the wrist if you start doing software development work when you are supposed to be doing your regular job.
In those cases, if you really want to get your shot at software development, you are going to have to be willing to give a little—or a lot—of your own unpaid time to further your mission.
Even if you are given some work time to work on software development tasks in your current role, it’s still a good idea to devote some extra, unpaid hours to those tasks, so that you can move the needle much further, much faster.
Be willing to get in early or to stay after work to get extra projects done.
If you are having a difficult time finding anyone who will let you work on tasks involving software development, you will probably have much more success if you are willing to do the work on your own time.
It’s an offer that most companies would find difficult to refuse.
Look for Bridges
One really good way to make the transition from a job like QA to software development is to find a bridge job that will put you between the two roles.
For many testers, automation is a great bridge.
If you can start taking on test automation tasks, you’ll get a chance to write code to automate manual tests.
Convincing your boss to let you do test automation is usually going to be an easier sell than convincing him to let you become a junior developer without any real experience.
It’s a win-win situation because you gain valuable, real programming experience, and your company gains the benefit of automated tests, which make the entire organization more efficient.
Once you have the title of test automation engineer or software developer in test, it’s going to be extremely easy to move into a regular software development role at any company because now you have real experience being paid to write code.
In fact, you might find that test automation is more fun and rewarding than doing testing alone or regular software development.
(I love designing automated testing frameworks. It’s one of my favorite technology areas, which I find extremely rewarding and challenging.)
There are bridge opportunities to software development from many other technical jobs as well..
For instance, Linux administrators can become tool developers or easily move into devops positions where they can use their Linux administration skills, scripting, and programming to automate tasks and build tools that benefit everyone.
Technical support people can move into roles where they do technical support for developers or even become higher-tiered support technicians who dive into the code to try and solve customer problems or gather information to send to developers.
Look for ways you can leverage your existing skills and responsibilities in some kind of development capacity, and you can create your own bridge job.
Moving to a New Company
Most of what I’ve talked about in this chapter has assumed that you’d be making the transition from QA or some other technical role to software developer within the same company, but that is not always possible or desirable.
How, then, do you go from a tester at one company to a developer at another company?
Actually, most of the same advice I’ve given you in this chapter still applies; it’s just that your job title doesn’t change until you switch companies.
What I mean by this is that you should be trying to get some kind of development experience at your current job—even if you can’t move into a software development role—simply so that you can put that experience on your resume when you apply for a software development role in another company.
Even if you built some tools that helped you do your job, that no one blessed, and you did on your own time, you have the opportunity to put that on your resume as real development work, which is going to greatly help you get your first development job.
Bridge jobs are also going to be extremely useful here, especially if you can get your title to have developer or engineer in it.
My Last Piece of Advice
Don’t get discouraged.
It’s often more difficult to transition from another technical role into software development, simply because of the bias I talked about before, where people tend to see you as “just a tester” or “just a server admin,” etc.
However, if you are willing to do the extra work and be “so good they can’t ignore you,” as Cal Newport says in his book of the same title, you are eventually going to hit success.
Keep learning, keep improving your skills, keep looking for opportunities and making your own, and you’ll get what you are after.
Patience and perseverance are key.
