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.
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.
Some tweets are like a Rorshach test and it’s much easier for people to project onto them what they want to see. This tweet is such a case. The quote can be interpreted in a few ways, all of them insulting. It really hits the tester nerve, especially for testers who take pride in their testing skills and have worked to make them better. I can see how it especially hits the nerve of testers who have worked to set themselves and the activity of testing apart from development as its own industry and job role with its own set of skills.
It makes sense that the natural reaction to this is to reach for pride and say, “I’m a tester, FUCK YEAH!!!”
What’s been missed, though, is that this tweet was part of a mini-rant. I was actually going for something more complicated that speaks to where testing is going within the broader context of the software industry and my place in that paradigm shift.
The Fun
Let’s take a moment to acknowledge the fun side of testing that we all know and love so well. We poke, we break, we question, we investigate, we discover. It’s fun!
The Baggage
Now, let’s examine the rest of what comes with a career in testing:
You will be seen as an also ran.
Developers (or management that doesn’t work with you day to day) will see you as not that smart or technical unless you get a chance to prove them wrong.
There is significantly less opportunity for promotion, especially as “testing departments” get smaller or go away completely.
Even if you learn how to write code, it’s assumed you will only ever work on test code and that your code will be shittier.
You will have far less decision power.
You will be paid less.
I’m sure there are people who would argue that the subset of baggage listed above doesn’t mean much in comparison to how much they loooooove testing and the pleasure they take in breaking things. If they want to stay in “testing” forever, that’s fine with me.
I disagree, however, that I should be content with less pay, a smaller set of career options and a position where I’m consistently marginalized on a team or even in tech.
It also occurs to me that the women’s restrooms at testing conferences are always crowded compared to the ghost town that is the women’s bathroom at any tech office or developer conference. There is no mystery here.
I started my rant because I had occasion to send someone I respect two of my favorite testing posts by Trish Khoo and Alan Page. When Trish and Alan suggest that testing teams are going away, that testing is an activity done by many on a software team and that testers should level up their coding skills, I see a role coming into focus where I am more empowered and more of an equal on a software team. I see a role where I’m even more in the thick of the software engineering process than I already am. I see a role that uses my testing skills and develops my problem solving skills as well. I see myself as a developer who is great at testing. One feeds the other and I am making great software as part of a team. All of this fits particularly well in the Agile XP process which includes TDD.
I’ve been working at building my web developer skills and I’ve found a team where this type of contribution will be welcome. It hasn’t been easy and this is all still a work in progress, but I can see the tipping point fast approaching.
No one can make you feel inferior without your consent.
—Eleanore Roosevelt
By the way, the short-sighted person quoted in my original tweet wasn’t a developer. It was another tester. I am surrounded by developers who see what I’m doing and who couldn’t be more supportive.
Now that you have the full story, let’s look at my tweet again.
Les Speakers photo credit Lillie Chilen (@lilliealbert)
In my credo, I state that I will always be a writer first. I’m working on the 2nd draft of a novel, I write everyday and I attend a writing class every other week. This class is precious to me, but recently, I made the extremely painful decision to skip a writing class in order to attend the event “An Evening of Talks with Double Union and Ashe Dryden.”
And so I gathered with others, our reflections co-mingling with the Bay lights in abstract patterns and crossing signals releasing an energy collected through resistance into the San Francisco night. The purpose of the evening was to raise funds for San Francisco’s first feminist hacker/maker space, Double Union. You can read more about that effort, here.
The featured speakers were Ashe Dryden (@ashedryden), Valerie Aurora (@adainitiative), Missy Titus (@missytitus), Dr. Kortney Ryan Zeigler (@fakerapper), Alaina Percival (Women Who Code) @alaina, Shanley Kane @shanley, Amelia Greenhall @ameliagreenhall.
It was refreshing that:
I didn’t have the usual space bubble around me that I normally do at tech events. Unless I go with someone, I find most meet ups and conferences are actually pretty lonely and there is usually this space bubble of a chair in every direction between me and other people even if I use double deodorant. Ok, it’s usually guys who are at the outer edge of the bubble. Although I didn’t know too many people, the crowd was quite friendly which cut down slightly on the terror. (Yes, I actually am very shy like everyone else in tech).
Shanley’s slides emphasized the general state of fucked up-edness in tech and software and it was like basking in the harsh daylight of reality. We need more of this.
There were none of those stupid, heckling, troll-types in the audience discounting the points the speakers were making or trying to play the speakers off of one another. I get so sick of stupid people saying, “well HER blah blah blah was SO MUCH BETTER.” Like it’s only ok to allow 1 female to be good at anything. There were 7 people on that stage and they were all awesome.
What I learned:
That I need to take stock of my own privilege. I hadn’t heard about this before last night, but it makes sense. Before you can understand who is different from you, it’s important to know your own self and the benefits that you’ve had in life.
Ashe Dryden suggested wearing a color to a conference and introducing yourself to others wearing the same color so you get a different type of cross-section. I really want to try this and see what happens.
There is a need for a harassment policy at every conference, even ones that are all women because women can be homophobic and/or culturally insensitive. I’ve reached out to Cascadia.js about their policy and pointed them towards the template on geek feminism.org
I’m really really really really done with tone policing myself online, on my blog, etc. Although I’m already fairly WYSIWYG in my writing and in life, I can do better. This includes engaging with men I know already in the tech community. The post I wrote on Medium still stands because I’m committed to supporting people around me when they try to do better. It’s just that I’m done with people patronizing me or playing me off of other women online. This will likely require me to educate myself more about feminism, and I look forward to that.
I want to write more about diversity in tech AND THAT’S OK. I can write as many blog posts as I want about being a woman working in tech AND THAT’S OK TOO. I’m tired of feeling guilty every time I have an idea for a blog post on gender or diversity as if I’ve written too much about it or that the world doesn’t need to hear more. At this point, I’ve written a few (Links: 1, 2, 3, 4, 5) and every time I think to myself, “How badly do I need to say this at the expense of looking less technical.” This is who I am and what I want to write about it. If you want technical, go check my Github. FUCK IT.
The Bay Lights on Bay Bridge (romanboed)
I feel an awakening in the tech world and in San Francisco.
It’s needed in many ways. Aside from the misery of the many who are marginalized, tech has been invading San Francisco’s friendly, collaborative culture and razing it to make way for Nerds Acting Like Jocks. It’s about time some of San Francisco began bleeding into some part of the tech community because we’ve bled enough of our own city.
Ashe specifically mentioned the need for everyone in the room to bust out of our own tech bubble and put more energy into experiencing the non-tech world. In San Francisco, we live in the heart of the counter-culture and it’s time to be more open to the lessons our neighbors and our city have to teach us.
Even without much of a membership or much of a space, the collective of people that makes up Double Union has already managed to bring us together in a way that reverberates through time and our own static-y channels. It was a privilege to attend this signal gathering.
My process of learning code originally went something like this:
Find a book with lots of examples. Favorites are Kochan & Wood’s Unix Shell Scripting, Head First Java and Kernighan & Ritchie’s C Programming, and I’m finishing up Head First Javascript.
Work through as many of the examples as possible. It might take a year but that’s ok.
Make my own crappy stuff.
This strategy went to hell for several reasons when I decided to get more serious about learning web development for the following reasons:
1. Any half-way useful web-stack has many pieces and a considerable amount of time can be spent just getting those to work together.
2. The pace of the web typically outstrips any book.
3. I’ve gotten serious about a novel I’m writing. Every morning, I spend an hour writing creative fiction. Between that and working 8 hours a day, when I get home, I am usually D.O.N.E.
But I’m still serious about learning more web development. Since I work at Pivotal Labs in test and support on Tracker, when fellow Pivot, Sarah Mei mentioned a Railsbridge workshop, my ears perked up. Railsbridge is an intensive Friday evening installfest plus all-day Saturday learning extravaganza. Recognizing the opportunity to commit to myself with a date, I signed up and have attended a couple of Railsbridge sessions. The thoughtful detail put into Railsbridge shows in how they divide people up by skill level, how they make sure you have what you need installed on your computer, how they have a great student:teacher ratio and do a retro at the end of the Saturday. I honestly wish I’d had the benefit of an experience like Railsbridge in college.
Oh yeah…college
There will always be a debate about whether people should get a CS degree or not. I have one. Many successful people I know don’t. Many places require them for employment, but a lot of places in San Francisco don’t. While I believe there are benefits to college, specifically, liberal arts degrees, I’m becoming a believer in the community education system I see emerging here in San Francisco.
In the case of Railsbridge, while the program doesn’t cost money, it is a sacrifice of a Friday night and most of a Saturday so there is an opportunity cost and some commitment involved. It’s true that there are many beginners, but I’ve met plenty of people there who are beginning to get pretty effective at building Rails apps. In fact, at the last Railsbridge I attended, I was greeted by someone who got a job after attending and learning from Railsbridge. I’m sure she worked really hard on her skills outside of Railsbridge as well, but she did the work and got results.
One argument I hear about meetups is that they’re full of people who don’t know how to code or who aren’t serious about their programming skills. While there are plenty of people at these Meetups who are learning on their own schedule and may never work as a programmer or even in tech, there are plenty of people who go to Meetups such as the Javascript one and will spend the better part of 2 hours on a Wednesday night writing some code. I’m routinely impressed whenever I show up at these events by the focus of my fellow attendees.
If you think that these types of group learning only cover a few “beginner” topics, what about Algorithms or Scala?
Part of what’s fueling this ecosystem is the proliferation and refinement of online learning. I remember when the M.I.T. open courseware was a bunch of syllabi. I also remember the agony of pre-millenial online classes. Those were definitely the dark ages. Now we have Khan Academy, Code Academy and CourseEra. Between these and the ease of setting up a gathering with Meetup, the SF tech community is turning into it’s own community college, and I’ve learned a whole lot more about Rails.
What I like about this system is that it’s not just the students who win. If you’ve ever taught someone how to do something you’ll understand the benefit the instructors are getting out of it too. As a bonus, I can see that anyone who learns something out of this community system is also likely to turn around and give back. I dream of the day when I’m good enough at web development to be the one pointing out CSS and Rails typos.
