Finding your self-confidence in tech is like finding your voice in a black hole.
Maybe it was functioning perfectly well when you entered, but if you try and make a noise, all you will hear is the sound of air being sucked out of you.
Last summer, I reached what I felt was a dead end in my career. I went to AdaCamp as part of figuring out what was going on and why I was miserable despite putting in so much effort. It is often the case that people who look to be highly successful from the outside are actually living in their own vacuum of pain and self-doubt.
The hot, humid summer in Portland dragged through my lungs as I walked to the AdaCamp venue for the first morning of the conference. Voiceless, tired and beaten, I sat in a chair for the imposter syndrome training session. This session was the traditional kickoff for AdaCamp and had a large attendence. I made a few notes:
“The reason you have imposter syndrome is that you’ve been treated like an imposter…”
…If there are people around who are trying to learn and you say to yourself, I’m too far beyond to help them, you are treating them like they are imposters…
…We are trained to say we understand things when we don’t…
…We are trained to pretend to know the answer when we think we can look it up later…
…You need to be able to look at someone and see that they are having a hard time, even if they act ok.
This workshop kicked off a weekend of recognizing the denial happening in my own life and career. It was like looking in a mirror for the first time in ages and seeing that, indeed, the bruises were real and in no way self-inflicted. It’s not like Imposter Syndrome training and AdaCamp magically fixed everything, but it gave me permission to start believing in myself again and to start seeing that I had been dealing with some endemic problems tech likes to hang around the necks of women and people in marginalized groups.
Although there will not be an AdaCamp this summer, The Ada Initiative will be doing Imposter Syndrome Training in Oakland, California and Sydney Australia during August. I highly recommend that women working in tech, especially women in tech who do not have a developer job title attend this training.
Imposter Syndrome is the feeling that you aren’t qualified for the work you are doing and will be discovered as a fraud. It is prevalent among women in open tech/culture, who’ve been socialized to value others’ opinions over their own and to do things “by the book”. Imposter Syndrome is a common reaction to doing publicly visible and publicly criticised work like that done in open technology and culture. In this workshop, The Ada Initiative will discuss solutions for overcoming Imposter Syndrome. This workshop is only open to women, and those who identify as a woman.
I will miss AdaCamp, but if it means more time for The Ada Initiative to do Imposter Syndrome Training, I say it’s a net win.
Just so you know that AdaCamp wasn’t all heavy, intense moments, here is my drawing from the Riot Grrrl session.
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.
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.
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.
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.
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.
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.
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.
I can describe it for you. The staccato percussion of keys is a low hum against the raucous din of pairs talking back and forth through coding problems. Product managers and designers hammer out the details of functionality with the squeak of markers on whiteboards. Distinct bytes of conversation ebb and flow in crunchy wavves much like the sound of a stratocaster guitar screaming out riffs in your parent’s garage.
Is it work or is it a party?
As an introvert, my idea of a party is talking to another person I already know while we duck dive under wavves of code stretched out against a large black screen. Is it a party or is it pairing?
So far in my tech career, I’ve learned what it is to build great software with Agile and Extreme Programming practices. I know that it works because I’ve painlessly released software with it many, many times. I know that if you want to ride the big wavves, your stories have to be small. If you want the code carrying you through to make sense to other people and be maintainable, it is important to WRITE A TEST FIRST. This is how you deliver value to customers in releases that are perfect, even sets of wavves.
Lucky me. I’ve found a place that is ready for me to jump in and get my feet wet in their big blue ocean. XP is somewhat new school for them, but they are shaking it up. The staff is currently 50% women. Their walls are covered with drawings, the monitors come in sets of twos, the tests come first and are abundant and there is the blessed, blessed noise of collaboration ringing through the office.
Although doing the impossible sounds like a chunk, the reality of impossible is usually that it is a canvas draped over many, many smaller pieces. Some pieces are uncomplicated and straightforward while other pieces, though tiny are exquisite in their complexity. Even the flow of working through the pieces can result in its own set of knots.
Impossible can take the form of something as large and physical as free climbing El Capitan in Yosemite or it can be as small as a Celtic knot that barely reveals the mystery of its form even beneath a magnifying glass. Impossible can be something that is universally recognized such as landing on the moon, but more often than not impossible is what we tell ourselves cannot happen in our own lives through personal choice or because of outside forces we think are beyond our control.
The voices fill our heads:
I’m just not smart enough.
I don’t have time.
But I have to take care of _________.
It’s just not going to work.
I need the money too badly.
This is so ruined.
I can’t go back.
Even though hope is typically represented as a ray of light or a tiny boat on a stormy sea, I don’t know that I believe in hope as much as I believe in the human heart and its stubbornness. The human heart will continue to seek out its deepest desires through every impossibility. It’s what defines us.
How thin is the line between passion, desperation, insanity and brilliance?
How willing are we to admit to ourselves the reality of what we want in deep our hearts?
Do we even recognize it and, if so, are we ready to claim it?
This is the thread that holds our dreams together if it is not keeping us awake at night.
Claiming what you want deep in your heart is a liberation. It is also a wrecking ball. You might finally know what you want in the deepest part of you, but the moment your deepest desire snaps into focus is also the moment when everything else falls away. It can be a landslide.
Friends and family will roll their eyes and bounce into a shrill chorus about what’s good for you. Rocks and silt will cover over your outstretched arms as the challenge itself pushes you into an overwhelm of stress. You might even sacrifice some of your long term vision as you focus on short term execution. All of the little things you do to reach the impossible cover you in a slag heap of dead weight.
In the end, who knows if you will reach that impossible goal? This is the impossible, right? If that’s the case, why do we keep doing it? Why don’t stubborn hearts just explode in a bloody tangible mess? Fire in the hole.
The truth is, reaching for the impossible is not about an end goal at all. It’s about self-preservation and unburdening yourself from the chains of desire. Sometimes, the only way for that happen is to pursue something so utterly ridiculous that it won’t make sense to anyone but you. The pieces you work through on the way to the impossible are yours. They are your strength and your effort. Even if you feel them dragging you down, these pieces are what will eventually uncover you, just your friends will be there to help dig you out. The slag heap that covered you inverts itself into a mountain where you stand on ground made solid by all of your pounding and wailing. You are standing on top of your heart. It is still strong and it is still beating. That’s the impossible.
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.
The thread of communication between you and your pair is a long, tensile line attached to a sharp, silver fish slicing through cold water and swift currents.
“We are in the fetch method. This is where we are extracting the data object. Array. Sibling. Child. Child. Map…wait.”
Snap.
Your line is now slack, adrift in black water. It billows in empty ripples and all of your thoughts are gone. Where are you? Are you rightside up or upside down? In deep waters, the human brain loses all sense of orientation.
In pairing, this is the moment when you have drifted into silence as your brain plunges further and further inward. This is the moment when shadows creep into place along with voices telling you at varying levels of loudness to figure it out, just think harder. The unluckier of us will see a red face shouting about how we are not enough, we never were and who do we think we are anyway?
This is a moment of vulnerability. Our culture of tech hubris has given us plenty of go-to excuses for denying reality. You may say that the silence is because you are processing or that your brain cells are talking to each other, but that’s not really it. Really, what is happening is that you are too scared to open up to the person sitting next to you and you are hoping, hoping, hoping that the connection happens before anyone notices.
This is the moment pair programming is designed to turn around, replacing hubris, denial and fear with vulnerability, trust and communication.
This is EXACTLY when it is time to recognize where you are, to open up and to start talking even if you don’t know or even if you guess that what you are thinking is wrong.
I’m lost.
I don’t know.
It left me.
I don’t know what I’m doing.
Help.
Ok, what just happened?
These are words we don’t say enough. Often there is no reward for them. In fact, saying these words is often turned into an act of shame because they reveal an uncomfortable truth: we’re not perfect and we don’t know everything. We are not computers. We are human.
This is a moment of being human.
For pairing to function as it should, you must be able to tell the person next to you that you are lost without any fear that they will shame you or fear that you will be punished for not knowing something later.
The essence of pairing is that you are underwater together, you are thinking together and, most of all, you are vulnerable together. When the line of feedback between a pair snaps, it’s not one person adrift, it’s two, but one person doesn’t know it yet. The power of pairing is that two people will be able to rescue each other more often than not.
That person in the seat next to you might be as far as it is humanly possible to be from your idea of embodying crystalline elven magic, but they are your light in dark places when all other lights go out. You have to trust them to light the way and they have to trust you to send them a signal the moment you are aware that you are over your head.
A good pair will tell you that it’s ok and you will get back on track together.
Trust, vulnerability and communication in this moment is the bedrock of pairing. It is also the bedrock of building great software.
The road to redemption sometimes starts with a software mantra.
In test driven development, doing the simplest thing is a guide intended to keep you unblocked and moving:
When you are writing a new test…do the simplest thing first.
If you have something complicated to implement…do the simplest thing first.
If tests are broken…do the simplest thing first.
However, doing the simplest thing can still be a challenge and might not even look like it is immediately moving you forward. Often, the simplest thing is a hack that looks like a badly drawn picture or a step in the opposite direction.
It takes practice to rewire a bold and busy, future-driven, human brain for this type of thinking. The trick is in repeating and following the mantra. The challenge is in continuing to follow the path. Your steps and tests won’t be perfect every time and your brain won’t like the fact that you are discarding so many fancy plans, but this is the practice. You are walking a path and each next step is the smallest, simplest one you can take.
This path will wind itself further into your thinking slowly and steadily over time. Your brain will relax into the small steps. The architecture of your code will change. Your focus will sharpen until you see only the step in front of you.
Although this may look and feel like tunnel vision, you will eventually find yourself reaching for the simplest thing when you are faced with larger challenges either in software or in real life. It is this focus on taking a single simple step that will start to open some doors and help you break through limitations in your code and also within your own mind.
Often, when viewed from the outside, the simplest thing equates to something far beyond easy. It could be making a change that breaks all of your tests or it could be admitting that you were wrong about something or, even harder, wrong about someone. It’s here that doing the simplest thing means tearing down a wall you’ve built inside yourself. That’s not easy.
Although the software lesson is in the accumulation of small, simple tests that become a safety net for experimentation, the larger lesson has more to do with how we approach our own inner limits, choices and patterns. As humans, we have a tendency to remain stuck in our own lives, unable to see what is blocking us as we debug, console.log, and pry ourselves until we can’t pry anymore.
When we are in a state of discomfort, the simplest thing can appear to be a tiny kite hovering far above and out of reach, amidst the thick dark storm clouds we hang over ourselves. It might look far away, but it’s not. This is when the simplest thing turns into whatever it is that takes you one step away from frustration. This might mean walking away or it might mean doing something you feel certain is wrong or something that is scary but that will keep you moving.
In the end, that is what doing the simplest thing is all about: keeping you moving with smaller steps. This focus in a moment when you are wracked with self-doubt and frustration is not going to give you a test suite, but it will give you something far deeper: a sense of relief. With practice, relief eventually turns to confidence and you will see the clouds in your own mind begin to disperse.
The story in your code gives someone looking at it for the first time a sense of where they are in the codebase. The tests invite them in and give them a sense of who the code was written for and what they can expect from it. The overall structure of the code has a coherence with each piece needing to be where it is. Each line of code serves a purpose. Names have meaning in the context of what the app is doing and each line of code continues the journey of the line before it much like the sentences in a novel.
Tests tell the story
Tests are the entry point into thinking about the intersection of coding and writing. Have you looked at what your test titles look like when you execute them? If you have, do they tell a coherent story? It is easy to smash a phrase or two into a test title, but these are the first, tiny glimpse of your code to the outside world. These tests are also an expression of questions you’ve asked about what you are building. If there weren’t too many questions asked or there aren’t any tests, it is highly likely that there was never a shared understanding about the story the code is supposed to tell.
Test-driven development helps with this because, with your tests, you are creating the outline of what you are about to build. Picture writing a draft novel of 300 pages and then realizing that your main character is flat because they are not conflicted about anything. That’s a lot of writing to toss out because you didn’t do the outlining steps in the beginning.
Plot and structure
Great writing hangs together because there is a polished structure in place. Writers agonize over how conflict is exacerbated by a character’s fatal flaw or how well they have set up their character for the ultimate fall. This same attunement to structure turns into an eye for low coupling and good cohesiveness in code.
An application is not just about one method but about the patterns that emerge through classes and/or components. This shows in the way that each line of your code reads and each piece of code is in place because it needs to be where it is.
Editing as Refactoring
A friend told me that great engineers are not afraid to throw something away even if they have spent a significant amount of time working on it. I’ve frequently heard the same thing whenever I listen to novelists talk about how they edit their work. Experienced novelists won’t just throw away a scene, they will re-write everything from a different point of view or ditch a plot line completely.
Aside from larger edits, there is a joy in tightening down a piece of writing or a piece of code. Although it is important to do the simplest thing first to get something on the page or to get something working, that’s only part of the equation. It is also important to go back through a shitty first draft and excise anything that doesn’t belong, much like a sculptor winnows away until all that remains are the edges that truly tell the story.
Meaningful Brevity
There is a fine line between verbosity and names that are so short they have no meaning. In software engineering, there is a practical reason for brevity. That reason is performance. Extra loops, extra characters and extra method calls stretch out the time required for a browser to render a page just as too many words and writerly flourishes will take the reader out of a story. In a great piece of writing, every word is in place because it serves the purpose of the whole and because it must be there.
Semantics Matter
The semantic names of variables, methods, objects and classes can have a long life and are often repeated throughout a codebase. Not only do they have meaning in the context of where they are being defined but they are creating meaning every time they are reused elsewhere. What will those sentences look like to your reader and how will they live over time? Are the names you are choosing attached to some structure that is likely to be refactored away. If you are choosing names to reflect what a user will see in your app are you using the same language as your teammates who won’t be looking at your code?
It’s about the journey
While it is an accomplishment to hold the book you wrote in your hand or to point to the app you built, this is not the greatest joy of writing or coding. The joy is in the creation. The best days are the days when thought after thought and page after page comes tumbling out. As an engineer, you know what you are building and have broken the problem down into enough small pieces that challenge after challenge lasts a moment, or two moments and then you are writing the next test and building the next object. In pair programming, these are the moments when you’re deep in a two way communication and the code spills into your editor like swift waters rushing in a river and you are floating along.
Writing is a longing to experience this feeling of floating time after time. It’s about setting up your life to maximize the time that you spend in that space of words and thoughts coming together. Just as writers often figure out if they work best in the morning or at night, engineers learn about their own style and how to support it. It might be that your best work happens alone and at odd hours in your own home or it might be that you prefer an office filled with noise of collaboration because that is what comforts you.
Although software engineering has historically been pitched as an activity for people who think in logic symbols instead of words and human emotion, there is value in exploring the strong relationship between great writing and great software engineering. It is worth exploring your own relationship to writing and how that relationship expresses itself in your code. It is often the case that great engineers are also great writers which is proven out in their code. Your code is a novel.
2009 was the year I rode zeitgeist like a motherfucker.
Portrait of a woman with her shit together
My blog became more widely read in software testing circles. I presented what still stands as one of my favorite talks on software quality and data visualization at the PNSQC Conference in Portland. One week later, I presented that same talk, my first ever conference talk at Adobe Software in Seattle and again at Microsoft in Redmond. After graduating with an MS in Software Engineering I moved to Australia to work for a company making killer software development tools.
From the outside, my career was taking off and there were no limits. My twitter exploded, I was in contact with a lot of conference organizers and I met so many people. But, at work, I found my opinions being questioned and put down in ways I hadn’t expected. In going from one job to the next, I found that, each time, what I had to say felt diminished. I didn’t feel listened to or heard. I was told I should be less abrasive, less aggressive, less defensive and take things less personally. When I did that, I was told that I shouldn’t bottle up my emotions.
I was #thatwoman.
Zeitgeist has a way of turning around and moving on without you. I could feel its energy and power withdrawing as a particular stack of books grew taller on my bedside table: The No Asshole Rule, Crucial Conversations, The Sociopath Next Door, What Every Body is Saying, The Five Dysfunctions of a team, The Emotionally Abusive Relationship, Behind Closed Doors: Secrets of Great Management and Good Boss, Bad Boss.
If it made you tired reading all of those titles, think of reading each one cover to cover and making sure you apply what you learn from them every day at your job because you’re trying to survive and be the employee management seems to want. That’s what I did over a period of 6 years.
What I found is that no matter how much I read and worked at not being an asshole or finding the “right way” to say things or get my opinions across, I could never be silent enough. Quiet crept into my head and started to expand there like a cancer.
What? Quietness? Me?
The writing I do is smart, ambitious and full of backbone because that is who I am. These qualities, however, can lead to suffering at work…particularly for women. This is called tone policing.
Tone policing shows up in one-on-one meetings, performance reviews, chats with well-meaning co-workers, beers with friends, meet ups with strangers. It even comes from the mouths of well meaning women and men who consider themselves feminist and/or interested in equal rights for women…that’s right. It is everywhere and it will chip away at you and chip away and chip away until it becomes something else entirely and you are being erased and even erasing yourself.
This is the equivalent of clear-cutting and terraforming your emotional acre and it can happen to anyone, even those who appear, on the outside, to be highly successful.
Here I am, on my birthday last year at the lowest point in the country, Death Valley. The low was also metaphorical. Yep, I was down. Way down. Further than ever and talking to no one.
I had erased myself. My writing no longer made sense because I couldn’t allow myself to say anything. My tweets were more polite than ever and slowed to a trickle.
What I didn’t anticipate at the bottom, was that zeitgeist, would once again, turn and present itself at a different angle, an angle I wasn’t expecting.
Punk Singer
This is Kathleen Hanna. She’s one of the firestarters of the Riot Grrrl movement. I hadn’t heard of her before going to see the film about her titled “Punk Singer” on a get-to-know-you outing with San Francisco’s feminist hacker space, Double Union. DU was, at the time, just getting started and looking for new members.
Riot Grrrl was a punk-rock, DIY focused movement born of Pacific Northwest, 90’s grunge zeitgeist. Kathleen Hanna was the lead singer of punk band Bikini Kill and the person who spray painted the phrase “Smells Like Teen Spirit” on Kurt Cobain’s wall. When taking the stage, she would call for all women to go to the front so that they could dance because, at the time, men had turned the front of the stage into unruly and unsafe mosh pits.
As I watched “Punk Singer,” I couldn’t stop looking at Hanna’s hair. I couldn’t stop thinking about how I had worn that same shade of hair back in my heyday. I fingered strands of my own long, brown hair and had a cry as the movie neared its conclusion. After the film, I went home, cued up Bikini Kill’s Rebel Girl on YouTube and made an appointment with my hair stylist.
Sometimes finding your voice starts with a hair color.
For me, it was changing my hair color back to black and finding my place among those bringing the RiotGrrrl zeitgeist back around and into San Francisco’s tech scene where it is so sorely needed.
I got accepted as a member at Double Union and I began learning. I’ve learned that the more smart and ambitious you are as a woman, the larger a target you become for other people’s projected insecurities and assumptions i.e. the more I follow Sheryl Sandberg’s advice to be bold, the harder and more damaging the knockbacks are likely to be. I learned that it doesn’t matter how much I work at erasing myself, it will never be enough. I learned that not all women are feminists and even women who think they are feminists are capable of tone policing other women. I learned that anger is a beautiful, inspiring emotion that I’ve earned the right to feel in every cell of my body, and above all, I learned that it’s ok for me to have a voice and to use it.
I’ve been using that voice lately and sometimes it’s harsh. Sometimes my voice shows the anger, grief and frustration of a woman who has been cut down time after time but who is still, somehow, a fighter. Sometimes this takes people by surprise and they don’t know where the anger comes from, they only see me letting it go. There was a time when I would have said, “don’t mind me,” or “so sorry, I don’t mean to offend,” but, I’m done with that. To some extent, this means that I might lose some followers and that some people will shake their head and say, “she used to be so accommodating.” So be it. I’d rather be myself.
Over the holidays, I went to see the art exhibit Alien She: Examining the lasting impact of Riot Grrrl exhibit at Yerba Buena Arts Center. Looking at the huge wall of Zines (pronounced zeens) assembled for the exhibit, it reminded me of the amazing zine community we have at Double Union. In looking at the hot pink, barbed wire fence made of yarn, I thought of the large number of members at Double Union who have brightly colored hair. The sound of the punk music strewn throughout the exhibit on iPods tracks not only with our collective frustration that tech is so fucked up and we’re just trying to survive it, but also with the happy chaotic noise of gatherings at DU. The exhibit is open for another week until January 25, by the way.
Photo by Leigh Honeywell/@hypatiadotca
In the meantime, another legendary Riot Grrrl band, Sleater Kinney has reunited and is releasing a new album today.
Between Double Union, Punk Singer, Alien She, Sleater-Kinney, Model View Culture, AdaCamp in Portland last Summer and the upcoming Alter Conf, it’s as if there is a badass, feminist zeitgeist that has ridden into San Francisco on the back of Karl the Fog. It has, for now, decided to settle on the 4th floor of the The Fog Building in the Mission. I show up there and breathe it in. It, along with some great friends and a wonderful partner have helped take me back to the powerful, unafraid woman I was in 2009. It’s help me slough off the dead weight of jobs past and prepare me to advocate for myself more, to give myself more credit and to sing and sometimes shout like a motherfucker.
The Riot Grrrls are back and so am I.
Thanks to all of my friends at Double Union and to my non-DU friends who have shoved the microphone back in hands. I am shouty-singing.
