A Tableflip Guide: Transitioning from Tester to Developer

Writing code is power.

As someone who has found success as a software tester, I’ve long counted myself as one of the many people who “fell into testing.” I told myself over and over that I was content to be a “technical tester” and restrict my coding habits to testing scripts, test automation frameworks and tools. Nevermind that I kept having to prove my technical knowledge over and over again, once as a tester and additionally, as a woman.

Today, I consider testing (along with support) as the space I’ve been allowed to occupy in the power structure of tech. If you go to a testing conference you’ll find people talking about how you can stay in testing forever and how it is a great career path. I’ve noticed that, often, the testers who shout the loudest about staying in testing forever have carved out their own place in the power structure of the software testing industry.

Something else you will notice at software testing conferences is the long lines for the women’s bathroom or that people in testing talk about how it’s actually one of the more diverse areas of tech. Why is that? Hmm…I wonder.

Here’s another perspective on this phenomenon of testing being more diverse: tech has pushed women of all races and people of color of all genders into non-developer roles telling us that it’s because of skills, smarts or that our brains work differently. We’re told that our work is just as valued and necessary even though the pay is much smaller and prove it again bias means we will have to prove that we have skills over and over. I’ve now decided that the software testing career path is not so much about falling as it is about being squeezed into a corner and kept there.

Transitioning out of this has been a difficult, rebellious, empowering act also known in this year of 2015 as a tableflip.

A friend of mine who recently made a similar switch had this observation about it:

I hope that every tester no matter how long they have been in testing or how old they are considers whether they want, at some point, to try being a developer. In saying that, I understand that I’ll get 5 people telling me how they never want to code and love testing so much. If you are one of those people, have fun with that. This post isn’t for you.

This post is for testers who see that their reach could extend beyond testing into more areas of tech. In particular this is for women and members of all marginalized groups in testing who have likely ended up in the field due, in some part, to cultural bias. If you find yourself writing little scripts to help you do your job, learning how to write automated tests, or learning so much about the application you test that you are constructing api calls and looking at application code, please give yourself the gift of questioning how you could go further with your technical skills and that you might want to switch to a developer career path.

Before I share what helped me, it’s worth recognizing some of my own privilege. I’m a cis, white woman. I don’t have kids and I’ve purposely sought out jobs that offer work/life balance. That means nights and weekends are mine. I make a good salary and live in the tech hub of San Francisco so I have a good amount of access and a great network of friends. I did not, however, have the time or money to attend a bootcamp so you won’t be reading about that experience here. That doesn’t mean I think they are bad. It means that they are not an opportunity for everyone, even with a scholarship. Thinking the only way into programming is through a CS degree or a bootcamp is its own bias. There are plenty of us WHO ALREADY WORK HERE. We deserve our own bridge into developer land. That bridge is something I have found to be all too rare in the tech world. I hope that changes.

Here is some of what worked for me.

Attend community workshops

Here in San Francisco, there is always a meetup. I’ve been to Railsbridge, Girl Develop It! and some Women Who Code meetups. I suggest these as a first step because they will get you oriented and help you feel supported. Also, each has their strong points so attending different types of these meetups will help you figure out which workshop will be most advantageous at each stage of your journey.

Pick a stack and stick with it

Because I enjoyed Girl Develop It! so much and because I was surrounded at work by developers working in javascript all day, I focused on learning web development through javascript and React.js. Having been to some javascript conferences, I generally find the javascript community around the Cascadia.js conference and the Javascript/Node groups in SF to be very supportive and encouraging. Eventually I branched out to learn rails, but it helped my confidence to have a solid foundation in javascript, node and React.js.

Pick an editor and learn all of the shortcuts you can

Any developer you seek help from will want to sell you on using their editor. Don’t let them do it. Pick one and make them help you with that one. If you have a mentor relationship with someone in particular, it can be worth learning their editor, but the truth is that you need to pick an editor that feels comfortable for you and learn its ins and outs. This will keep you coding.

Keep learning the shortcuts in that editor, because being able to quickly navigate your code without thinking about it is only going to help if you are building something. Also, if you are asking questions or showing someone your code, it looks better if you are using shortcuts vs. mousing around and clicking. Trust me, developers will give you more respect if you use shortcuts. My favorite editor is pretty much anything in the Jetbrains family, particularly rubymine and webstorm. Sublime is also beginner friendly and used by many of my friends who are developers.

Find a workplace that will support you

I went through multiple jobs in my quest to switch careers and found that support varied from place to place. One thing I did find helpful was to be open about what I was trying to do, once I knew what that was. It could be that you decide to do this while you are working at a job that won’t support you. That happened to me. The only solution was to find a job that would support me. Although it sounds drastic, I found that once I was in a more supportive workplace, everything was easier.

Talk to a Career Counselor

This option is pricey and, sadly, not available to everyone, but I found it to be worth every penny. Tech is so broad and there are so many different types of developer jobs. This also helped to settle the question of whether this is really what I want and not just something I’m chasing because the developer job title is power.

[Mini-rant: Personally, I’ve found that so many people tell me I would make a great product manager and maybe that’s true, but the job that I do every day needs to be in line with my heart’s desire and not other people’s perceptions of my talent. Having worked with some brilliant product managers, I’ve seen what that work involves and I know it’s not what I want. Also, I suspect that women are often steered towards the role of product manager for reasons rooted in cultural bias.]

Talking to a career counselor helped me prioritize what I was looking for in a job and a company. As an example, I found out that I care less about being emotionally invested in the problem I am solving. I care more about how I am building software. This helped me shift focus away from companies building products to consultancies focused on pairing and TDD.

Build something

Once you’ve done some workshops and are comfortable with your editor, it’s time to build something! The thing doesn’t have to be particularly original or even interesting. In fact, you might simply repeat building something you’ve built in a workshop but give it a name-change or tweak. Lately, I’ve built several versions of the same rails app, but with a different name every time. Every time I’ve rebuilt it, I’ve learned something new or deepened my understanding in some way. At some point you will start thinking about building a thing you can release. This will help you when you start interviewing because it gives you something to point at and say, I built that.

Let other things go

I’ve just had about 6 months of not doing a lot of things I wanted to do. Once you are in the serious prepping for interviews stage, it’s time to Stop Doing Other Things. This is a painful but necessary step. Women are already pressured at every turn to take on more activities than we really have time for and to always be helpful and willing to sacrifice our time for someone else or their cause.

I found getting ready for tech interviews the ultimate excuse for taking a look at my responsibilities and removing myself from a lot of it. There were a couple of weeks when all I did was send out emails and talk to people to remove myself from responsibilities. It wasn’t fun, but it created the space I needed to proceed with deep prep.

Mock Interviews and Interview practice

I had former co-workers and friends mock interview me several times. In between, I would work on the feedback I received after the mock interview. This helped me strengthen and tweak what I was doing. In fact, since I focused on pairing interviews, it made me a better pair. Also, be sure to ask about what you did right. It is such a confidence boost to know that you have some things covered and don’t need to worry about them in an interview situation.

Don’t find a mentor — ask questions!

There is a general refrain I have heard over and over at different tech events: “find a mentor!” I wish people would say, instead, “keep asking questions!!” The truth is that you will need many people, some of whom will be more involved than others. Rather than explicitly looking for and asking people to mentor you, focus on reaching out with questions. You will need to practice and you will need to reach out and ask questions even if you are tired, even if you are shy and even if you don’t want to. At the other end of that reaching out, you will find people who will only half answer your question or people who prefer answering with their own hubris rather than the information you need, but you might, if you’re lucky, find someone who not only answers your questions, but will tell you to ask a few more. That is a mentor.

A good mentor will answer your questions and guide you in the right direction. A great mentor will be there for you many times in ways you didn’t even know you would need them. They will give you confidence when you don’t have any left and they will help you shape your career path in a way that best suits you. This is not a relationship you’ll be able to trivially go out and find just anywhere, but if you end up with one of these, thank your lucky stars and your mentor for it is rare and a true gift.

Don’t give up

There were so many days when I looked at my broken code and thought, “why am I doing this?” Especially if you are not at the beginning of your tech career, you will have some days when you seriously question this strategy of switching to developer. Currently, in San Francisco, there is an on-going parade of people marching through coding bootcamps and straight into jobs. This is discouraging to watch if you are someone who can’t afford to leave your current job for 3–6 months. Also, if you are older, especially in the Bay Area, it’s easy to look around and draw the wrong conclusion that development is for the under-30 crowd. Development should be for people who find it interesting and who are curious.

Curiosity is one of the most valuable skills a tester can have. In fact, I’ve told people for a long time that curiosity is necessary for great testing. The thing about curiosity is that it doesn’t have edges. This is the root of being someone who is engaged and who cares about what they do at work. If you are a tester and you are curious about where else you might fit into tech or where else you might find a challenge, you should follow that instinct and tech (and also other software testers) should be supporting you.

1 thought on “A Tableflip Guide: Transitioning from Tester to Developer”

Comments are closed.