Twitter github

Author Archive

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.

Signal Gathering: An evening of talks with Ashe Dryden and Friends

Les Speakers photo credit Lillie Chilen (@lilliealbert)

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, San Francisco

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.

 

Enhanced by Zemanta

A little humor for those conference woes

There is a lot of pain and angst around the topic of the treatment of women at tech conferences right now (which will not be rehashed here).  Opinions are wide and varied and feelings are running high.  In the United States, we’ve actually been here before and on an even wider scale.

In the 1980’s, when Clarence Thomas was the first African American to be considered for supreme court justice, the highest judicial office, he was accused by law professor Anita Hill of sexual harassment.  It touched off a broad national discussion about the appropriate workplace treatment of women (and men). Rather than spend this post, comparing the two events, I’d like to offer up some humor.

One of the most popular American shows in the ’80’s was Designing Women.  It was a comedy driven by the, mostly, female characters in the cast  and took place in my hometown of Atlanta, Georgia.  During the furor of Clarence vs. Anita, Designing Women devoted an entire show to examining this topic.

There are times when comedy and fiction are better at capturing multiple sides of a tricky issue than any expert opinion or news coverage.  This particular episode of Designing Women falls into that category.  There’s not much you need to know about the characters or even the larger situation of Clarence Thomas and Anita Hill to get the humor.

It is likely that this YouTube link will not stay up forever, but if you’re hurting after the latest series of events, I hope this episode will at least give you a laugh or two.

The Strange Case of Clarence Thomas and Anita Hill

Enhanced by Zemanta