Tag: software

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.

Reblog: Cascadia.js — A javascript revival in Portland

Reblogging this post about Cascadia.js 2014 because Cascadia.js 2015 is in full swing and I’m feeling all nostalgic about last year.  Note that I’m posting an epilogue/update at the end.

chalk drawing of cascadia

This is my trip report of a javascript conference, Cascadia.js, which took place under a tent in Portland’s sunny, summery…ok, it was really hot.  It was hot like a church revival.

Revival Tent at Cascadia.js

Usually, when I do a trip report, I’ve taken lots of notes in conference talks and this is my chance to regurgitate them.  Happily, all of the 2014 Cascadia.js talks are online and, since the organizers had 170 proposals to choose from for 21 speaking slots, they are all phenomenal talks, so no regurgitation here.  Here is a bold statement: this was the best conference experience I have ever attended which includes speaking or just attending. This was not my first conference.  (Note: I was also on the roster to give a talk with friend and mentor, Ryan Dy.)

 

What made this such a great freakin’ conference?

There are some very specific reasons why I had such a great time and I hope that other conference organizers will take some of these reasons into consideration when organizing their own conference.  (If you know a conference organizer, please share this post with them.)

1. Code of conduct

This is not a standard yet, but all conferences, meet-ups, etc. should have one. NO EXCUSES.

If you are STILL wondering why this is so important, Leigh Honeywell has written an excellent blog post which puts this in simple terms even a nerd can understand.  

The standard you walk past is the standard you accept — David Morrison via C.J. Silverio

Cascadia.js was very up front with their COC and I’m sure it made the conference better.  If you are a conference organizer and don’t where to start, have a look at this template.

2. Single track…ftw!

Having been to both extremely large conferences and peer conferences that included about 10-15 people, I am now convinced that small and single-track is my favorite conference format.  It gives everyone at the conference a conversation starter.  There are no choices about which talk to attend, and the talks are usually better because there are fewer speaking slots.

3. The speakers had a wide spectrum of experience for speaking and for javascript

I’ve been to conferences where the speakers have all been “industry experts with X years of experience.”  I guess that’s one way to sell the value of what someone is saying, but people who are new to a language or to speaking have their own lessons to offer. For example, what Ruth Baril had to say about the anxiety of asking questions at meet ups was something that I think everyone needs to hear as it addresses approachability within the tech community.

4. Creating a wider audience for a conference

Watching Lydia Katsambaris’s talk on Bookmarklets and releasing her first code to the world resonated deeply with me since I’ve just had my own first release.  In fact, it resonated in a way that any of the deeper code talks wouldn’t have because it speaks to my personal experience.  I would much rather watch a talk that speaks to me in that way than to watch a man in an aloha shirt, stomping up and down a stage yelling out excessively boring metaphors about how building software is building a house. (This happened years ago and I walked out of that talk.)

5. Interspersing technical talks with cultural talks meant that more people watched both

There were talks I would not have watched but that I very much enjoyed.  I watched them simply because I was already seated and couldn’t be bothered to move.  This is how you get a talk out to people who need to hear the message but who might not purposefully watch it.  This conference was purposefully stacked with cultural talks intended to send a very clear message about inclusivity and there were also plenty of deep, code-y talks.  I listened to super-technical talks that I probably might have avoided, such as Nick Niemeier’s talk on event emitters because sometimes those talks intimidate me.  Listening to them anyway proved to me that I now know a lot more about javascript and web development than I did when I was sitting in the audience last year and it gave me something to aspire to for future talks.

On the flip side,  I’m sure there were people listening to my talk about mentoring who probably would have skipped it otherwise.  Because we were all sitting down in a hot tent, everyone was listening to all of the talks.  

This is how you expand someone’s mind.  
man expanding his mind in red pants
6. There was no Q&A section
Q&A at conferences is less of a discourse and more of an insult delivery system.  Cascadia.js wanted people to ask the speakers their questions face to face after the speaker had left the stage.  I like this because, aside from keeping the conference moving right along, it means the person asking the question is more accountable for what they say.  It also means if the question is really a way to patronize the speaker or to insult them,  it won’t be happening in front of a huge roomful of people who might even collude with the question troll to create a miserable speaking experience.  
I know how much work it takes to put together a conference talk.  It means you’ve shoved other responsibilities aside to practice and are working through any personal fears of getting onstage in front of lots of people.  I would much rather that people watching my talk remember the message I worked so hard to send rather than someone’s stupid, troll-face question they took 5 minutes to think up.
Does this mean people don’t get to ask questions? On the contrary, it means that people get better, more meaningful answers to the questions they ask.  Ryan and I were asked some questions after our talk and because we weren’t in front of a large crowd, faced with a time limit, we were able to answer the someone’s question thoroughly and specifically for their context with no constraints on time.  In fact, there were other conference attendees who were able to chime in during the conversation with some valuable input. This type of deep discussion can’t happen when you’re on the stage.  
7. Conferences are more fun when you go with a friend
I hate going to conferences alone.  You’ve made plans, spent money and gotten all excited about a conference.  Then you show up alone and feel like an outsider right away.  This doesn’t make it easier to make friends, rather, it makes it much, much harder.  Especially if you’re female, I’ve noticed that there will be a space bubble around you at all times.  People don’t sit next to you.  People don’t introduce themselves to you.  You really have to go an extra 500 miles to introduce yourself and then it’s assumed that you won’t be able to able to participate in a technical conversation. (Insert inevitable eye-roll here).
For these reasons, I’ve made it a habit of sticking out my hand and introducing myself if I am in line, if I am sitting at a bar or if someone sits down one seat away from me.  It doesn’t mean that I feel any more brave when I do it, but it’s more of a habit now.  I’ve also learned to let the first minutes of awkwardness ride.  It’s never going to be non-awkward to introduce myself to someone I don’t know, so I’ve accepted it.
That said, it is much, much easier to conquer these things with someone you already know standing by your side.  This was the 2nd time Ryan and I have attended this conference together.  It was refreshing to have someone sitting next to me, someone to eat with me and someone who understood that I was freaking out before my talk because he was freaking out too. After our successful talk, we got to sing together at karaoke too.
cascadiakaraoke
This made it a lot easier to reach out to other people and I met some folks with whom I hope I get to keep in touch.
We were both melting, but it felt great to get up on stage and say the things we did after so many hours of work.
Thanks to the conference organizers for including us in such a heavy-hitting roster of talks.
As a bonus, I tend to sketchnote conference talks, but this time, Willow Brugh (@willowbl00) sketched out mine!
vizthink
Revival at summer camp…
Javascript hasn’t had the easiest year, but if there is any message sent by the talks at Cascadia.js, it’s that the javascript community is not held in the hands of any one person or any one man.  If we’re talking about revival, maybe the revival is that Javascript is now in the hands of its own community more than it ever was before.
Deep messages aside, the tent + being outdoors + flip-flops everywhere meant that the conference felt very much like a summer camp.  We broke the hotel’s ice maker, bonded over crazy javascript projects, drew all over the sidewalk and looked at way too many cat pictures together.
I’m still in withdrawal.  
Every conference should be this way.
Epilogue
A conference is a snapshot of a community at a moment in time.  This one left such a feeling of joy in my heart that I don’t know if it’s an experience that will ever be topped.  If anything, it shows that there is, indeed, a way to harness this type of joy in the tech community.  It can happen and I hope it happens again.  I hope it happens for everyone.
This year, Cascadia.js is experimenting with a festival format where each day has a theme.  It’s taking place at a resort in the San Juan islands, so it really is a summer camp!  I’m not there this year, but chances are pretty good that I’ll be returning at some point.
As for me and Ryan, we’re working on a new talk that we will be giving at Strangeloop in September about javascript, functional programming and collaborative sketching.  I can’t wait!
Photo credit:
The lovely professional photos seen throughout this post were shot by Matthew Bergman
https://www.flickr.com/photos/matthewbergman/
https://creativecommons.org/licenses/by-nc-nd/2.0/

 

Feminism in the testing bubble

I’ve described myself as a feminist for years and, for many of those years I didn’t take too much time to stop and think about what that meant to me.  My definition was fairly straightforward and one that I’ve seen in many other places.  Feminism meant equal rights for men and women.  My definition didn’t go much further than that.

 

In my earlier days of blogging, I didn’t particularly want to write about feminism.  To an extent that’s still true.  There is a tax for people who are part of any marginalized group.  The tax requires that you will spend your time and energy not on the actual topics you care about and want to write about such as software, but that you will spend time and energy defending your participation in the space and your right to be there.  The tax is so far-reaching and insidious that you will end up paying before you even realize what’s happening.

 

Payment comes in many forms:  your influence, showing actual emotions on twitter, a boss’s anger, exhaustion from explaining yourself (again) and then there are all of the requests people make of you to teach them because they don’t feel like finding answers for themselves.  Eventually you become #thatwoman who has opinions on feminism.  This turns you into a “go-to” whether you want to be or not.

 

There was a time when I was willingly paying all of these various forms of tax.  I’ve done organizing, participated in “visibility” efforts and written about feminism.  At the end of it, I found myself exhausted and needing to focus on my own career rather than continuing to feed the testing community with all of its various requests.

 

I largely disengaged from the testing community a few years ago because I’m pushing my own career in a different direction and it is taking all of the energy I have.  In the meantime, I’ve paid attention to what has been happening in tech around gender and diversity outside of testing.  For the most part, I focus on listening and signal boosting other people because, as a straight, white, cis woman who already has a tech job, I have my own share of privilege.

 

Through all of this listening and signal boosting, my feminism has grown and changed.  It has outpaced my old definition and is now anchored in bell hooks

 

Simply put, feminism is a movement to end sexism, sexist exploitation, and oppression.

 

I’m done arguing, debating and/or discussing the meaning of quality, but I don’t think we talk enough about feminism, what it means to us, how it touches our lives and what it looks like in our communities.

 

The testing community, in particular, seems to operate under this two-headed shadow of a certain leader with mysoginist tendencies coupled with other leaders who don’t seem to have an awareness of what is happening in tech diversity outside the walls of testing.  (Yes, that is a challenge.  I don’t mind if people communicate with me to tell me how wrong I am about that, just don’t expect me to give you a cookie.)

 

One thing I’ve learned in this new world is that if I am part of a marginalized group, it is ok for me to push back on taking responsibility for fixing things.  It is ok for me to voice a frustration or call someone out and leave it at that.  I don’t have to write tons of articles for different testing publications explaining myself.  I don’t have to be the one giving talks about this.  In fact, by not doing these things, it leaves space for other voices.  I’ve noticed that there are some great new voices in software testing who are paving the wave for even more change.

 

My hope is that people in software testing reach outside of the testing bubble for influence on multiculturalism and inclusion.  Prove me wrong. Show me that you are learning and listening.  I am not the person who will say to you that my opinion is the only one and you should blindly follow it. We’ve had enough of that in software testing.

 

Resources: