Twitter github

Feminism in the testing bubble

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

Resources:

The Moment

photo of a flying fish

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.

Thanks @rdy for teaching me about pairing.

Do the simplest thing first

red_kite_cropped

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.

Your code is a novel

What is the story told by your code?

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.

Bringing back the Riot Grrrl

2009 was the year I rode zeitgeist like a motherfucker.

me in 2009

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.

photo of Kathleen Hanna

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.

 

zineOver 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.

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.

selfieThanks 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.

 

The grassy roots of growing developer skills with Growstuff

In my last post, I wrote about how I’m transitioning into a development role.  A big part of that transition has been working on the Growstuff open source project led by Alex “Skud” Bayley and they are in the last few days of their IndieGoGo campaign to fund API development by Frances Hocutt.

This Summer, I got to meet both Alex and Francis, although I had been following Alex for quite a while on Twitter and I was first introduced to Francis through her beautiful writing for Model View Culture.  Allow me to introduce you to our feminist corner of open source.

Screen Shot 2014-10-18 at 1.05.02 PM

Food Stuffs:
Growstuff is an open source platform that helps connect people who are growing their own food which people do for many reasons.  Aside from the pleasure of gardening, growing your own food means that your food will likely contain more nutrients.  In areas where a good supply of high quality produce choices is lacking, it can allow you to grow produce that you otherwise would not be able to find.  It is also a way to shortcut the cost and expenditure of fuel needed to transport vegetables from farm to store to your home.

If this has peaked your interest about the benefits of food gardening, this Mother Jones article is a great in-depth look at the benefits for you and for the planet of growing your own food.

Open Source, Technology and Learning Stuffs:
Open Source and Good Software Engineering are two things that, I have learned, cannot always be put together in the same sentence.  There are good, non-trivial reasons for this.  Open source projects typically have to be distributed which means fewer opportunities to pair and fewer opportunities to mentor.  It also means a project might have to compromise on good engineering if it wants to move forward.

That said, one of the paths to web development, the path that I am following, is to write code for an open source project (Not everyone has the privilege of time and money required for a “bootcamp”). This creates the conundrum of learning good software habits and finding a project that is willing to work with intermediate web developers who are slower and will need help.

Growstuff has solved this problem by adopting a focus on agile and learning culture.  It is ok to ask questions.  Pull requests are not eviscerations.  Everything is organized between a wiki, Pivotal  Tracker and Discourse.  Pairing and TDD are emphasized wherever possible.  The CI is kept green.

I feel safe here.  That is an accomplishment.

Feminist Stuffs:
Encouraging diversity in tech is about so much more than teaching kids and also grownups to code and love computers.  There are a lot of efforts right now to help women and other diverse groups learn how to code, but there is a dirth of places for an intermediate engineer to go after they’ve done tutorials and small side projects.

With my intermediate skills, I put out feelers for writing code and helping out in a few places and was pretty shocked at some of the places that proved, shall we say, less than welcoming.

Growstuff has been the place that has finally let me work on some code.  I’m slow, I have to work with a pair, and sometimes I really don’t know what I’m doing, but that is ok.  I know that whatever I end up contributing will be something the project needs that will be of value for users.  This means the world to me.

The reason why Growstuff is running their funding campaign is to bring on Frances Hocutt as an api developer.  I had the privilege of meeting Frances along with her mentor, Sumana Harihareswara this Summer at the AdaCamp conference in Portland.  They both helped me immensely with the guts of a talk I did this Summer with Ryan Dy on mentoring.

You can help!

If the news about diversity in tech feels overly depressing or intractable, throwing a few dollars at the Growstuff campaign is a very direct way to encourage support for women who, against the odds, have kept going and will keep going in tech.  I’m including myself in this category and hope you’ll give to this project that has already given so much to me.

My role in the new world of testing

tweet about testing

 

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.

 

Another testing tweet

 

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.

 

tweet about testing

I just want to add…watch me.

Changing the World with a Breath and a Test

Today is Friday and it’s time to relaaaaaax.

Chilling out in tech can be so hard sometimes.  There are so many places the stress comes from, I don’t even feel the need to explain it because it exists for all of us in one form or another.  Yes, you can say, “that’s life,” however, I feel it’s intensified to a fever pitch in tech almost every day at even the best workplaces.

As I worked on finding ways to chip away at my personal incarnation of stress, I began to think of how a web app could address the larger topic of workplace stress and chilling out when you need it the most.  I won’t ask you to raise your hand if you’ve suffered anxiety at work, because I now assume that most of us do.  This was on my mind as I was doing lots of testing of text fields for my job such as names, comments and descriptions.  Testing text fields often involves pasting some text into those fields, usually from a dummy text generator commonly referred to as an ipsum generator.

Every tester has their favorite Ipsum, from the meats of Bacon Ipsum to the irony of Hipster Ipsum or even the NSFW Samuel L. Ipsum.  One day as I was pasting another lengthy sheaf of text while taking some deep breaths, it occurred to me that it might be helpful to see the meditative phrases I’m often muttering to myself staring out at me through my test data.

This is how I came to build the app I’m releasing today, Relax Ipsum.  I built it with help from friend and javascript developer, Ryan Dy.  It’s a fairly simple, straightforward, static app that uses HTML, CSS and Javascript with a guest appearance from JQuery.  You can look at the source here.  In the process of building this app and working together on some other JS projects, Ryan taught me a lot about thinking in Javascript vs. Java (the language that began my programming journey), test driving code and taking Javascript from tutorial-grade to a real-world implementation.  

Our mentoring relationship has been the difference between me putting this app in your hands vs. me building another fake twitter cobbled together from web tutorials and stack overflow.  That’s power.  Having someone tell me that, yes, I can do this even if I feel like an idiot, is a machete cutting deep into imposter syndrome.  I carried this confidence with me to AdaCamp where I discussed the power of mentoring with others who have had similar experiences with mentoring and I even helped some people get started on their own web development journey.

I feel like Ryan and I discovered the path to change the world. The folks organizing this year’s Cascadia.js conference agree that we are onto something.  Ryan and I will be talking about Hacking Mentor.js at this year’s Cascadia.js conference in Portland.

In the meantime, let’s take a deep, everybody-chill-out-we-made-it-to-Friday breath.

The Conversation of Code Review: Using Satir modes to improve your code review skills

I recently got to see a terrific talk about Better Code Review by Doc Ritezel at the March SF Ruby Meetup. His slides are posted here and are worth a look. Meetup talks can be a mixed bag, but with detailed examples and useful takeaways, I found the talk itself to be that rare mixture of entertaining and thought-provoking.

Doc’s talk follows in the wake of another huge discussion about hostile workplaces, this time at Github. His presentation focused on what a positive workplace looks like and what’s missing from most workplaces in terms of code review. He first illustrated the difference between authoring and reviewing code, then covered what can go wrong on each side of the table through a few example scenarios. These scenarios were, sadly, recognizable by more than a handful of audience members. Finally, he made a few suggestions about how to modify feedback to be more positive.

If you’ve ever participated in code review, either through static comments on Github or real-time pair programming interactions, you know how easy it is to spoil someone’s day by saying the wrong thing. If you’re the author, to use Doc’s parlance, you could be working with an otherwise-great reviewer whose comments suck all the pleasure out of working with them. Likewise, it’s important as an author to know how to be open to feedback. Building software is a highly collaborative process, and understanding how giving feedback can go wrong is important.

I found myself noticing Satir Categories in some of the slides that Doc presented. One of my recent reads, “More on the Gentle Art of Verbal Self-Defense,” by Suzette Haden Elgin, talks about personality categories developed by Virginia Satir, widely known as the originator of family therapy. I definitely noticed my own personality in the group. There are five categories, and you might recognize yourself in one of them, too:

The Blamer places permanent responsibility on anyone else’s shoulders. Although the Blamer could be identified by someone who loves shouting and pointing fingers, in reality the Blamer can speak with a soft voice. Professor Snape, for instance, was pretty good at cutting people down with his voice at a minimal volume.

A good way to identify the Blamer is the use of absolute language: “always,” “never,” “only,” “everybody,” “not even once” and so forth. For example, “Never use strings as hash keys,” “Only smart people use vim” or “Always use git add -p.”

It’s worth thinking through this a step further. Imagine phrases that don’t necessarily use these keywords but imply an absolute rule like: “When you don’t use git rebase, a kitten dies.” Notice that there’s an implied “Always,” like “always use git rebase.” Or maybe “these tests are so redundant,” which carries an implication that “every test should be unique.”

The Blamer’s actions universally carry a single subtext: I disagree with your code, so you should feel ashamed.

The harm that results from placing shame on another teammate, someone who is presumably making an effort to work with you on building something complex can have far-reaching consequences at the individual and the team level. These issues are beyond the scope of this post, but for now, let’s just say placing shame is something to be avoided if you want to foster collaboration.

The Placater feels quiet anxiety and fear while trying to please everyone. Playing the victim role comes naturally to the Placater, as does using appeasement to defer any decision-making responsibility. You won’t identify the Placater by tears or yelling; they’re most likely too tightly wound.

Key phrases sound like “Let’s do things your way” and “I don’t know enough about this.” What’s sad here is that the Placater really does know what they want, but doesn’t feel comfortable putting themselves in a position where they might be wrong later. After all, being wrong would open the Placater up to persecution, which they fear above all else.

The Placater’s actions have their own subtext: I wish I wasn’t here.

Okay, now imagine that the Blamer and the Placater have to do a code review. The Blamer wants to shame the Placater for disagreeable code, and the Placater takes the abuse while trying to make the Blamer like them personally. This is a dangerous dynamic to have in place because it will re-enforce the blamer’s pointy finger and make the Placater feel even more victimized than they already do. If this is happening on your team, it’s time to get some help for yourself or for your team.

The Computer, in addition to being named the same as the thing in front of you, is another Satir Category. People in Computer mode hide as much emotion as possible. Science fiction loves this part of the strong, silent masculine image such as the character Dr. Spock from Star Trek.

In hiding behind a facade of detachment, the Computer is able to avoid projecting emotions, and thus avoids placing blame on the other person. Any blame is therefore directed at the code, or something abstract. This category is marked by a lack of referenecs to “I” or “me,” or really to any person at all.

Although Doc mentions using “I” and avoiding “you” as positive takeaways in his talk, this is a half-measure compared to the total detachment of the Computer. While it has obvious utility for reviewers who are purposefully trying to avoid shaming an author, becoming the Computer can also be useful for authors dealing with the Blamer.

The Distracter cycles through Blamer, Placater and Computer giving an impression of disorganization, panic, silliness or all three. Although this mode is trickier to pin down, think about it this way:

Reviewer [Placater]: “I’m not sure, but you might want to parse out the xml here. There are a few libraries to choose from, feel free to choose any of them.” Author: “Ok, I’ll use Beautiful Soup” Reviewer [Blamer]: “No, don’t ever use Beautiful Soup.” Author: “Ok, I won’t use that one. Is there one you prefer?” Reviewer [Computer]: “There are several libraries preferred within the Python community.”

In this case, the reviewer gives the author a choice, but doesn’t support the choice being made by the author. Besides being very confusing to the author, it also puts them in a no-win situation because it doesn’t matter which action the author takes. Anything they do appears to be wrong in the eyes of the reviewer.

The Leveler matches up what they are thinking and feeling with their words and body language. This is also defined as congruence which I wrote about here. This is someone taking in the context of the situation and being straight-up about what they are saying without resorting to blamer, computer or placater mode.

The advantage of leveling is that you know you are getting an honest response upon which you can rely. The downside is that it might be very harsh or more intense than someone is ready to hear which can throw your audience off guard.

In a code review situation, this is the mode I personally appreciate even if the feedback I am getting is not puppies and kittens. Even if the reviewer is not totally happy with my work, if they can manage to avoid the other modes mentioned, it’s easier to get on with the business of correcting what needs to be fixed or to engage in more of a discussion.

What do I do with these?

  • If you feel like you are in hot water in a code review, go to computer mode. In fact, think of this as “safe mode” for your conversations. It will be harder to work through choices because you are not expressing much of an opinion, but you won’t be taking as many risks. This buys you time to figure out what’s going on or to get in touch for a face to face conversation. However, if you are speaking in Computer mode most or all of the time, it might be a sign that you are shying away from voicing an actual opinion
  • Unless you’re pretty sure that the other person is in leveling mode, don’t match Satir modes. For example, two blamers will end up in violent disagreement that will be challenging to repair. Two placaters will find it challenging to come to a decision. Two computers, well… there’s a reason why it was Captain Kirk and Spock. If Star Trek had been Spock and Spock, the Enterprise would never have undertaken a mission as risky as exploring unknown galaxies.
  • Avoid using Distractor mode as much as possible unless you deliberately want to look crazy in your code review.

Where do I even start?… It can be really hard to sustain an emotionally safe work environment. Since making software is highly collaborative, the challenge is increased even further. I am hopeful that the days of choosing CS as a major because you won’t have to work with people or talk to anyone are over, but even then, we’re still left with the fact that we are human. In fact, many of us who work in tech come from a background of being taunted at school or picked on by parents to the extent that we were driven inward, towards the machine, towards the code and away from the responsibility of external relationships with real people.

  • One quick win is to practice avoiding words that signal blamer mode (always, never, only, everybody, anybody, ever, not even, once) If you know of things you’ve said in a code review that are in blamer mode, can you think of a way to re-phrase them?
  • Watch this talk by Jenn Turner about Non-violent communication from Cascadia.js. She brought the house down and her talk was recorded.
  • Read more about Satir Modes in More on the Gentle Art of Verbal Self-Defense or start at the source with Virginia Satir’s groundbreaking classic, New Peoplemaking.
  • Read about non-violent communication in the book, Non-violent Communication: A Language of Life by Marshall B. Rosenberg and Arun Gandhi

Forgive yourself for mistakes you’ve made and take a deep breath! You get to try again tomorrow.

A big thanks to Doc for helping me put together this post and to Sarah Mei for organizing the SF Ruby Meetups.

Underwater Blues: Getting Down into the Second Draft

“You see, in my view a writer is a writer not because she writes well and easily, because she has amazing talent, because everything she does is golden. In my view a writer is a writer because even when there is no hope, even when nothing you do shows any sign of promise, you keep writing anyway.”

Junot Díaz

From Becoming a Writer/ The List, O Magazine, November 2009

 

It is easy to write the first draft.

Starting with a blank page means that your characters can be anyone you want.  The story world is yours to build anywhere you choose.  It’s easy to tell yourself that eventually the plot points will line up, the heroine will save the day and maybe end up with a hot guy.  This is because the first draft is essentially a brain dump, the worst version that will exist.  Expectations are low.

By the second draft, however, you are working with something that came before.  There will still be big changes, but they have to fit in with the existing framework.  The blank pages that caught tragic flaws and mistakes so easily before are now filled with words that can be their own sticky web of tangles and snarls.  The layers of story you’ve built might fit together but it’s more likely they’ll run over each other or sit across the widest chasm waiting for the bridge you have to build between them.

It can be hard to feel forgiveness in your own writing.

Even worse, life and world events change your perspective on your own story and what used to look like a battle to save the world is now chick lit where the heroine’s big task is rearranging her closet…in 300 pages.

There is also the fatigue.  In the first draft, you are a fresh-faced, new grad with no mistakes or missteps marring your record.  As the plot winds on, however, every challenge seasons you.  For the most part this is good, but in the second draft, self-doubt can creep in as you read back over your previous pages.  The shitty first draft you wrote turns into its own performance review and your own words tell you that you are, undoubtedly, under-performing.

That under-performance affects what you think you’re capable of writing next or whether you are capable of building the bridge.  The inner critic shows up to explain in voluminous detail how each word is a failure and the tragic flaws of your characters become your own.  Instead of your monumental achievement, your precious first draft becomes the written warning sent by certified mail and you are on notice about your own writing.

This can be a death spiral.

It is important to recognize the inner critic if only to banish it.  Everyone, no matter what they do, has one of these.  Sometimes, it’s your past coming back to haunt you, which is truly sad.   No one deserves being made to feel as if everything they do or write is a mistake, but for too many people, at some stage in their lives, a person exists who does that very thing.  Even if it’s only your own internal pressures, it’s important to learn how to let go of these harsh voices and continue laying down the pages word by word.

Letting go is the key.  Letting go is how your initial draft came to be in the first place. It is the release from your own high expectations or any thoughts that this next draft will be better at all than the last one.  Even if it is worse, who is counting?

So let go of the page count and the chapters.  Let go of the location of your story and your character’s point of view.  Let go of what must be and let go of “the message.”  It’s ok to float and ok to release what you knew about your story.  Let it all go, all of it.

I’m sure that for every story, there are some pieces that float away and won’t return, but there are also the pieces that stay.  This is the kernel of truth about your story and this kernel makes it the story that only you can tell.

When I let go, my characters come back to me.  They take my hand and they walk me back to the story world we created together.

We are walking and I am writing.