One of my first experiences pairing was with my least favorite co-worker. In my previous programming jobs, I’d always been the only Rails developer, or one of two, and we’d had a lot to do. Too much for us to be able to “afford” to pair on a regular basis. I was great at translating my thoughts about code into code, but not at translating them into words. This co-worker wanted to talk about patterns and theory all the time, and it almost seemed like he was doing this to avoid the “writing actual code” part. We were on a deadline, and I wound up relegated to the backseat in our pairing. Pairing seemed like both an aggravating experience and a colossal waste of time.

Another early pairing experience was with a brand-new boss on deep legacy code neither of us was familiar with. He flipped through tab after tab after tab of under-tested code while driving. I read pretty fast, but… not that fast. I had no idea what was going on, and he kept telling me that we didn’t have time to slow down and write characterization tests. I was really scared of letting on how confused I was. Not only was he my new boss, not only did he have at least fifteen years more experience than I had… I was the first female engineer this company had hired, this was the largest codebase I’d ever worked on, and I was petrified that people would think I’d gotten a “senior” title because I was friends with the CTO. So I kept on trying to keep up, feeling – and probably looking – stupid, because I didn’t know how to get the pairing session back on equitable ground.

But then I had some really great pairing experiences. It started with the time that I was stuck in the middle of this ugly ElasticSearch multi-tenancy problem. I was trying to make searches across multiple tenants reassemble themselves seamlessly for end-users. I’d spent a week at 80% done, not quite able to keep the full thing in my head at once. But then I started pairing with someone who got the other 20% of the problem and we just flew through the rest.

Today I pair a lot more often than I did back then. It’s not sunshine and roses all the time, but when it works it works. I get to learn new things from other developers, and get parallax on tricky problems! I get to share new tricks with people and empower them to be even more awesome! And, now that I’ve faced down absolutely horrific distributed-systems bugs both alone and with a pair… I have learned that having a pair won’t make SFTP behave itself, but that at least I’ll have someone to vent to when it has yet another weird connection lag!

Pairing works better for me nowadays because I realized that pairing is a programming skill. Just like for loops, code review, or domain modelling. And like any other skill, it can be taught and learned.

We don’t teach people how to pair, usually – we throw a second chair at a desk, maybe a second keyboard, and hope for the best. Or when we do teach people to pair, it’s usually in some hyper-organized Pivotal-style fashion where you pair all day. It’s exhausting, and you don’t really know how to translate it to “real life.”

It’s no fun learning to play doubles ping pong when neither you nor your partner have ever played or seen doubles before. It’s no different with pairing: learning a few basics around expectations and communication makes the difference between awful and wonderful pairing. Here are some techniques that you can use to avoid classic pairing traps!

Technique #1: set up a pairing structure

It doesn’t entirely matter which pairing structure you use – some people switch keyboards every twenty minutes, and some people after every test. Other people switch keyboards whenever one of them wants to Google something! This can feel silly and artificial at first. But, even though it’s artificial, it’s not silly at all. Most of the work of pairing isn’t code, it’s communication – and communicating about who should be driving is surprisingly hard sometimes! Letting a pairing structure figure out keyboard switches for you frees up your brain for important things, like “naming variables properly” or “figuring out where that browser event is even coming from.”

Technique #2: make it easy for your pair to give you feedback

You can start out by making it clear to your pair partner that they can give you feedback at any time. Structure helps here, too – maybe you can designate 15 minutes for feedback before lunch, and another 15 towards the end of the day. These strategies don’t always work, but they’re a good start! To really help your pair out, don’t just use your words – make sure your actions match them. When pairing, you have a lot of decision points where you can choose to make the pairing session safer and more collaborative. If your pair makes a suggestion that seems dubious, try saying, “I’m not too sure about this, but I’m okay giving it a try. Can we timebox exploring it to twenty minutes, though?” That way, you’ve shown your pair that you’re receptive to their ideas – and when that fifteen-minute feedback session rolls around, they’ll be more comfortable talking about what’s on their mind.

Technique #3: own bad pairing experiences

Practice empathy for your pair! It can be easy to blame your pair if you’re not working effectively with them. To think, “oh, they’re not really paying attention,” or “they’re not pulling their weight.” But the signs of a pair partner who’s “lazy” are the same as the signs of one who’s confused, or who’s having a rough personal week. Empathy for your pair doesn’t necessarily mean needing to know what’s going on with them. (Think about it – if someone can’t concentrate because of a family emergency, do they really want their co-workers prying into their business?) Empathy for your pair means assuming good intent, and trying to make things easier. Sometimes, the most empathetic thing you can do is take ownership of your negative feelings about the pairing session: “Hey, I feel like my head isn’t in the game right now. Can we take five minutes, grab more coffee, and have you take a turn driving when we get back?”

When I think back to some of my worst pairing experiences, I realize that – even if I couldn’t have rescued them – with the skills I have today, I could probably have made them better. Some parts (microaggressions, rudeness, or hostility, for instance) shouldn’t ever be my responsibility to fix. But even so: when I think about the pair who “couldn’t keep up” with me, who was “talking about patterns instead of fixing the problem,” I wonder: what if I’d asked him to type what he meant, instead of talking about it abstractly? When I think about the pair who wouldn’t slow down to write characterization tests – what if I’d asked to drive? Then at least I would have been in control of the tab-flipping. And maybe I could have said “can we humor me and write just one characterization test?” Then, I could have shown that even if characterization tests might have slowed my pair partner down, they would have sped us up – as a pair.

Pairing always involves two people. I used to hate pairing, and now I don’t. Some of that is that I work in different environments now. But a lot of it was just – learning more! And the great part about that is that anyone can do that, too.

This guest post is written by Betsy Haibel of Cohere, an engineering leadership and management training organization. You can learn more about pair programming in the Let’s Pair! Zine and Workshops series.

Mandy getting ready for "Tech The Halls 2017!"

Male Allies and Being Mindful with Sibyl Edwards and Priyanka Komala

Sibyl Edwards, President of DC Web Women, cofounder of Technicolor DC, a coalition uniting diversity-focused tech groups to advance the color of tech, and BFF (Black Female Founders) and Priyanka Komala, a technology leader, distinguished speaker, and DCWW champion, talk about organizing the Tech The Halls event and why they do it, and the importance of having male support as women in technology.

Philanthropic Initiatives and Workplace Gender Diversity with Julia Rodenas

Programming Co-Director for DC Web Women, Julia Rodenas, is helping to organize a charity drive for Thrive DC, a nonprofit that helps to battle homelessness in the area, during the party.

Tech For Everyone with Nicole Mathews

Nicole Mathews, the event coordinator for DC Web Women, and I talk about how it can be intimidating to get into tech, and feel comfortable saying that we're in tech, especially when people usually just associate the field with software development. Our consensus is that we belong here and you do too!

Thrive DC with Greg Rockwell

Greg Rockwell, the Community Relations Manager for Thrive DC, talks in depth about what they do for the homeless population in the DC area. They provide vulnerable people with a wide range of services to help stabilize their lives and serve as a safety net for people experiencing homelessness, unemployment, housing instability, and food insecurity. With their help, and the help of supporters and donations, clients take the first steps toward independence and self-sufficiency.

Mindful Leadership, Managing Culture Change, and Cultural Wellness with Melisa Rivera

Melisa Rivera, of LuxQuest Media, talks about her job as a Creative Director. Her goal is to tell stories that inspire social change and impact through powerful storytelling. She talks about the importance of being well: mindfully, spiritually, and physically, and the impact that it has on your life and in business.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode.

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Amazon links may be affiliate links, which means you’re supporting the show when you purchase our recommendations. Thanks!

Ding! Ada’s¹ phone buzzed, telling her about a new JIRA² ticket assigned to her. It seemed like a fairly straightforward ticket – just fix this tiny bug in one of their older libraries.

Hours later, Ada was banging her head against her keyboard. The code in this library had tentacles entangled everywhere. It felt like the butterfly effect applied to software – delete one parameter from one function, and another thread breaks under a particular race condition. But she was nothing if not persistent. A git blame on the line in question showed that no one had touched it literally in years. No surprises there. As a last bastion, she decided to look at the git logs for the two files side by side, hoping some past author left any breadcrumbs of how these two pieces interacted.

Ada face-desked. Abject horror flashed across her face, which she promptly buried in her hands in despair. The commit read: Add param to function so other thread doesn't crash, and she knew the author used “-m”.

Commit Kindly

A lot of git tutorials instruct beginners to do something like the following:

git commit -m "my first commit"

I get it. If you don’t instruct them to use the m flag, you have to talk about gitconfig, EDITOR, and probably how to exit vim. That adds cognitive overhead to the task of “learning git” that may discourage initial committers. But – I would argue – it’s fundamental to using git well, and further that not talking about it reinforces bad practices.

Committing from the command line encourages conciseness over verbosity. If you make a typo or come up with a more clear phrasing, you probably won’t bother to whack the arrow key to go back and fix it. But commit messages should be verbose! Commit messages are not just a gratuitous step that we go through to appease git (although some people may think this). Writing commits – just like writing code – is fundamentally an exercise in communication. They will eventually be consumed by humans, and, when they are, they ought to provide value to the human.

With this in mind, I advocate the following practices when committing changes.

Keep It Small

Commit small, coherent sets of changes. This has nothing to do with how you write commit messages, and everything to do with how you stage your changes. “git add -p” is your friend here. Ensuring your diff is small and coherent will make the next practice far easier to follow.

Context is Everything

Commit messages should be structured as follows:

High-level summary of the changes. Keep it short

Paragraphs upon paragraphs of _actual prose_, providing any relevant
details about the changes. If you want to take advantage of
`git shortlog` to have prettier logs, you should wrap the lines at 72
characters.

Relevant details can include:  potential “gotchas”, reasonings behind
changes, motivations, relevant context for the changes, or anything
else that may be helpful to some future developer spelunking through
the commit history.

These details should be much more of “why” behind the change, rather
than a “what”. The "what" can be obtained by looking at the diff.

Minor Nits

The main point of my writing this is to talk about the content of commit messages, rather than the format, but because of Reasons, there are two formatting nitpicks that I need to talk about. The high-level summary should not end in a period, because of git send-mail. There should, however, be an additional newline to separate the summary line from the detailed notes. I’m actually not sure whythis is, but Linus has spoken, so maybe we’re all just too stupid to get it (he once actually said “if you still don’t like it, that’s OK: that’s why I’m boss. I simply know better than you do.” Ouch.).

Commit Showcases

I went looking through some repos to pull out some examples to illustrate my point. Here’s what I found.

The Good

[Derek Prior](https://github.com/rails/rails/commit/13fd5586cef628a71e0e2900820010742a911099) (Rails):

Add `redirect_back` for safer referrer redirects

`redirect_to :back` is a somewhat common pattern in Rails apps, but it
is not completely safe. There are a number of circumstances where HTTP
referrer information is not available on the request. This happens often
with bot traffic and occasionally to user traffic depending on browser
security settings.

When there is no referrer available on the request, `redirect_to :back`
will raise `ActionController::RedirectBackError`, usually resulting in
an application error.

`redirect_back` takes a required `fallback_location` keyword argument
that specifies the redirect when the referrer information is not
available.  This prevents 500 errors caused by
`ActionController::RedirectBackError`.

Sean Griffin (Rails):

Allow `Relation#or` to accept a relation with different `references`

Note that the two relations must still have the same `includes` values
(which is the only time `references` actually does anything). It makes
sense for us to allow this, as `references` is called implicitly when
passing a hash to `where`.

Fixes #29411

Ariel Ben-Yehuda (Rust):

typeck::check::coercion - roll back failed unsizing type vars

This wraps unsizing coercions within an additional level of
`commit_if_ok`, which rolls back type variables if the unsizing coercion
fails. This prevents a large amount of type-variables from accumulating
while type-checking a large function, e.g. shaving 2GB off one of the
4GB peaks in #36799.

Marcus Buffett (Rust):

Catch IOError

If config.toml doesn't exist, then an IOError will be raised
on the `with open(...)` line. Prior to e788fa7, this was
caught because the `except` clause didn't specify what
exceptions it caught, so both IOError and OSError were
caught

Alex Crichton (Rust):

rustc: Don't use DelimToken::None if possible

This commit fixes a regression from #44601 where lowering attribute to HIR now
involves expanding interpolated tokens to their actual tokens. In that commit
all interpolated tokens were surrounded with a `DelimToken::None` group of
tokens, but this ended up causing regressions like #44730 where the various
attribute parsers in `syntax/attr.rs` weren't ready to cope with
`DelimToken::None`. Instead of fixing the parser in `attr.rs` this commit
instead opts to just avoid the `DelimToken::None` in the first place, ensuring
that the token stream should look the same as it did before where possible.

Closes #44730

Sean Griffin (Diesel):

Allow ad-hoc inserts using tuples

This provides a more lightweight API for inserts that mirrors what is
possible with `.set` for updates. The implementation provided ensures
that all elements within the tuple are valid for the same table, and
that there's no funkiness like sticking an upsert value in there.
(Secret way to break Diesel -- It will totally allow you to stick a
`Vec` in there, and will generate invalid SQL as a result. We should fix
that one eventually, but it's pretty low priority)

One thing I would also like to allow is to allow mixing ad-hoc values
and `Insertable` structs. (See 10374a5
for rationale). I tried a naive approach where I moved the parens out
from the `InsertValues` impl on tuples, and into `InsertStatement`, but
that breaks PG upsert, so I'll need to spend more time on it. I've left
the test cases for that in place, but I will defer actually making them
pass for a later PR in order to keep the PR size and scope reasonable.

I expected to need more tests/compile-tests, but what's included here
felt like it pretty exhaustively tests everything.

Fixes #789

Sean Griffin (Diesel):

rm `IntoInsertStatement`

This gets rid of `IntoInsertStatement`, and turns `BatchInsertStatement`
into the only visible type for constructing queries. In its
implementations of `LoadDsl` and `ExecuteDsl`, it ends up constructing
`InsertStatement` which is what actually performs the execution.

The names are now super poor and misleading. The reason I've opted not
to rename them in this commit is that I actually think I'm going to end
up getting rid of `BatchInsertStatement` entirely, and only have
`InsertStatement`. If we don't end up going that route, I'm going to
rename `InsertStatement` to `ExecutableInsertStatement` and rename
`BatchInsertStatement` to just `InsertStatement`.

Aside from simplifying our codebase, this change also makes sure that
all insert statements constructed will include the 0-row checking case.
I think we can eventually just move this into the `QueryFragment` impl
by doing `SELECT returning_clause FROM table WHERE 1=0`. This would mean
the only thing we have to special case is SQLite batch insert.

Fixes #797

Sean Griffin (Diesel):

Refactor `InsertValues` for tuples

This changes the implementation of `InsertValues` on tuples to not care
about its interior type, and moves the SQLite special handling to
`ColumnInsertValue` directly.

The addition of the `Table` parameter on `InsertValues` is required for
the tuple implementation to enforce that all values are targeting the
same table.

One side effect of this structure is that it will (eventually) allow
arbitrary nesting of `Insertable` types. This is important for use cases
like rocket, where you will likely have a `user_id` field which comes
from the session, but we want you to derive `Insertable` and `FromForm`
on the same struct. This means we should be able to write code like the
following:

    #[derive(Insertable, FromForm)]
    #[table_name = "posts"]
    struct NewPost {
        title: String,
        body: String,
    }

    #[post("/posts", data = "<form>")]
    fn create_post(data: NewPost, user: AuthenticatedUser, conn: DbConn)
        -> QueryResult<Redirect>
    {
        use schema::posts::dsl::*;

        let created = insert(&(user_id.eq(user.id), data))
            .into(posts)
            .returning(id)
            .get_result::<i32>(&*conn)?;
        let url = format!("/posts/{}", created);
        Ok(Redirect::to(&url))
    }

This should also let us simplify the `default_values` code dramatically.

This commit message is fantastic! It has all the detail you could possibly want to know about the change, along with a code sample showing what the change is going for!

The Bad

Me! (Conway):

single commit implementation :O

Yup. I committed (get it?) a sin here. I am ashamed, and I should feel ashamed. All I can do is try to be better in the future.

Sean Griffin (Diesel):

Don't look at this commit

It's too embarrassing

Sean brought this commit up on The Bike Shed. His commits are usually so good (see above) that I couldn’t not put this here to tease him a bit.

The Ugly

Warning: Most of these contain expletives, and are not safe for work. But if you want to see some really poor commit messages, check out Commits Logs From Last Night.

In Closing

Commits are meant to be read by humans. Provide lots of context when describing your changes. It’s like taking the time to eat well or get enough sleep – you may want to take shortcuts, but the benefits to doing it Right will pay off in major ways in the long term.

PS: In the original story, I played both roles. That is to say, I was both Ada and the Bad Committer. Sometimes, the reader of your breadcrumbs is Future You. So at the very least, be kind to Future You, and don’t commit with “-m”.

¹ Yes, the Ada Lovelace.
² Believe it or not, JIRA was around even then.

A few days ago, when I was applying to speak at a conference, I went to take a peek at one of my old talk videos on YouTube, I found that one of my Internet Fears had been realized: 4chan had found one of my conference talks. The first thing I noticed was the dire ratio of 15 thumbs down votes to 0 thumbs up votes. Ouch. There was a comment about how my talk “actually wasn’t a bad idea,” but should have been “a side presentation that is not marketed as important.” (Interestingly, I think this person thought he was standing up for me, because he noted that he “couldn’t believe he had to say this,” but that “for once the SJW is okay,” although he also added, “that being said, I would have liked if the presenter did not look like an autist.”) Also, I knew that it was posted on 4chan specifically because someone else helpfully replied, “Yeah dude we all saw your post on /g/ you don’t need to repost it here.” Ouch for everyone involved, I guess.

Anyway, as you can imagine, finding this post took the wind out of my sails when it came to my conference talk. But, it also got me thinking about why. Am I really the kind of person who can’t handle the little number 15 next to the thumbs down icon? Or a comment that was only like, half mean? Saying that my talk should have been marketed as not important was a little brutal, but it’s not like it was the first time I’ve heard that my talk about chronic illness and diversity wasn’t technical enough to belong at a tech conference. I think the thing that bothered me was the realization that people had been discussing me on 4chan without me knowing. It felt almost like being back in high school, knowing that my classmates who didn’t like me were gossiping about me behind my back. Although I know it’s unrealistic, it made me wish I had more control over where my stuff got posted on the Internet… and then suddenly, I was struck by an old memory.

When I was a kid, I loved the X-Files. I seriously cannot express to you the depth of my love for that show when I was in middle school. I also wrote a lot of fanfiction. One day, I found some of my own fanfiction on a review site called, “The Mary Sue Report,” after searching Google for my own name. The entire purpose of this website was to unearth and make fun of bad fanfic featuring “Mary Sues” – original characters added to existing casts who are too competent, too attractive, too desirable and otherwise too perfect. In fairness, my stories were a particularly egregious example of what they were trying to make fun of. They featured a self-insert character with color changing eyes, who was the youngest agent to ever join the FBI, and everyone loved her, and she had a telepathic dog. It was bad, I get it. This is what somebody there had to say about finding and reading my stories: “You know how when you pick up a big old rock in the woods, and you find all of those gross bugs and grubs squirming around underneath it? That’s what it was like, only not really, because bugs are gross in a cool way.” Double ouch.

At the time, I was mortified. I was 12 years old. It had never really occurred to me before that anyone could read the stories I posted AND that they might not be as big fans as my friends, who were all also around 12 years old. I was so embarrassed that I ended up deleting all my fanfiction off the web not too long after. I remember that even at that age, the thing that bothered me so much about it was that anyone could search Google for my name and these awful reviews would come up. I was convinced that this shame would follow me forever, that somehow these reviews would foil my future book deal and career as a novelist. Of course, I was publishing under a cringey fake goth name at the time so it didn’t follow me at all, but this is distinctly the first time I ever remember worrying about my brand, which is something I think about all the time now.

22016163_10159589173560413_1956529453_n.jpg

Dropbox is a free service that lets you bring your photos, docs, and videos anywhere and share them easily. Never email yourself a file again!

These colorful floppy discs may be the only remaining copy of the fanfiction in question.

Now I’m able to look back and laugh at this story. I know full well that I wrote some truly unfortunate, self-indulgent fanfiction when I was a kid, and I’m not ashamed of that! Still, even when I’m laughing about how embarrassing it was, I have a gut reaction that nobody else can read it ever. To this day, I never shared any of those stories again, not even when my fiancé begged me to let him read it and share in the joke. I started to wonder if this experience affected how I share my work on the Internet even today. These days, I’m pretty open about sharing what I’m working on, so maybe not. Still, I did have a very similar visceral reaction when I found those negative comments on my Polyconf talk, so I think there’s some part of me that’s not quite over it. Even if I’m still ultimately the same oversharer that I always was, I’m sure that other people have been discouraged from going public with their work because of experiences and stories like these.

And for what reason? What are people’s problems anyway? While I wasn’t crazy about the thought of people talking about me on 4chan behind my back, I also never would have realized it was even happening if someone hadn’t chosen to repost his comments on YouTube, where the speaker would conceivably see it. When I think back to the reviews of my fanfic on The Mary Sue Report, I can’t help but wonder: did the presumably grown-ass people commenting there realize that they were tearing apart stories that were written by an 11-year-old? And why did they care so much if my fanfiction was a literary masterpiece or not? Yes, there’s a lot of terrible fanfiction out there, and a lot of it is written by young girls, trying to express themselves doing awesome stuff and being taken seriously by their role models. Seeing older people spewing such negativity about a hobby dominated by young girls really bristles me, particularly since the way young girls express themselves is already so policed in our society. Growing up and finding one’s place in the world is already hard. Who is this bad fanfiction hurting? Who cares if 11-year-old Jamey wanted Fox Mulder to love them, if it made them happy to write about it?

Not only that, but at least in my age demographic, who among us hasn’t posted stuff on the Internet that they’re later embarrassed by? Kids my age grew up having access to the Internet early. I was born in 1990 and have been online since I was 8 years old. And since the technology was new, we didn’t really have anyone to teach us how to use it. Of course I didn’t have a good sense about what I should share, how public it really was, and how long it might continue to persist on the web. None of us did! We’ve pretty much grown up in a world where we all kind of acted like idiots online when we were younger and it’s just something you had to accept. Rebecca Sugar, for example, is 3 years older than me and now known for her work on Steven Universe and Adventure Time. She wrote Invader Zim fanfiction when she was 15 under the pseudonym Muffins Magee, and it was recently unearthed by some of her fans using web archive. And honestly? I loved every second of it and so did most of her fanbase. I think it was a collective sigh of relief as we all realized she was like us when she was younger and it didn’t matter and now she’s doing amazing things.

f0b.png

Dropbox is a free service that lets you bring your photos, docs, and videos anywhere and share them easily. Never email yourself a file again!

This is one of my favorite images on the entire Internet.

The fact that fans were even able to find her old work is pretty incredible. It made me start to wonder what traces of my younger self were still searchable online. They say that once you post something on the web, it never really goes away, but I found that wasn’t quite true. Like I said before, I nuked my fanfiction in a fit of insecurity and it’s nowhere to be found now. (I did the same thing with my LiveJournal entries when I was in high school, so that minutiae of my daily life as a preteen also seems to be gone forever.) The only fanfiction I was able to find was a few Matrix stories that were written by an old internet friend. And that only came up because she used some of my characters and credited me using my old pseudonym! Even though it doesn’t exist anymore, I found my old website about Silica Gel via the Internet Archive Wayback Machine. I found my old DeviantArt account, where a younger version of myself amusingly lied about being Canadian. I was able to find the bad reviews I mentioned before, but only because I remembered the name of the forum and poked around in their old posts, as it didn’t come up on Google. I also found my name on fanlistings and on other people’s guestbooks. (Remember guestbooks, by the way?) It was all tempered by a sense of nostalgia and the deeply strange realization that 11-year-old me never expected that 27-year-old me would someday be reading my offhand comments about my favorite anime.

radical_edward_and_tomato.jpg

Dropbox is a free service that lets you bring your photos, docs, and videos anywhere and share them easily. Never email yourself a file again!

Since I shared Rebecca Sugar’s Invader Zim fanart, it’s only fair that I share my own Cowboy Bebop fanart too.

Once you post something on the Internet, you pretty much immediately lose control over where it’s posted and who it’s seen by. That’s a very legitimate thing to worry about and take into consideration before you click that share button! But, it’s also an important thing to consider before being too critical of something you see online. It can be very easy to forget that there’s a real person on the other side of the screen and that can very easily lead us to being harsher than we may have been otherwise. It’s so sneaky that we might not even realize we’re doing it; I used to think it was hilarious to make fun of furries online until one day I woke up and realized that they were all just enjoying themselves without hurting me and oh my God, I was the asshole! I don’t necessarily think the people who made fun of my terrible X Files fanfiction are inherently mean people. I just don’t think they ever considered that the 12-year-old author was reading the things they were saying. And it’s not just my terrible X-Files fanfiction that the world is missing out on. Real art and worthwhile, thoughtful opinions are also being held back for fear of being misappropriated, shared recklessly or made fun of. Sharing our work on the Internet, while often rewarding, is also something that makes us profoundly vulnerable. If we all spent a little more time appreciating that, perhaps we’d be less likely to respond with negativity and we could all feel a little bit more comfortable sending these small pieces of ourselves out into cyberspace.

Are you Greater Than Code?
Submit guest blog posts to mandy@greaterthancode.com

The systems we build—whether they are technical, social, or organizational—are increasingly complex and distributed. We’ve reached a point where we can’t understand, see, or control all the moving parts, yet we are responsible for the resilience and performance of these systems.

How do we build websites that perform well, scale to millions of users, and are always up? One place to start is breaking down the wall between development and operations. The following is an excerpt from my recent article, The Evolution of DevOps, in which I explore the impact and expanding influence of DevOps culture, and how to leverage DevOps at your organization.

The Culture of DevOps

There’s a continual debate within the DevOps community about whether DevOps is fundamentally about culture, or whether it’s about processes (like CD) and tools. I’m sympathetic to the idea that DevOps is first and foremost about creating a culture in which developers and Ops staff work with each other with mutual respect. But to take either side of this debate by itself invites trouble. Effective DevOps is a good resource for balancing the roles of culture, methodology, and tools.

Many tools are associated with DevOps. I’ve mentioned some of them (in a very general way). But one of the biggest mistakes management can make is mistaking the tools for the reality. “We use Chef to automate deployment” doesn’t mean you’re doing DevOps. All too often, we see organizations that “automate deployment” without changing anything about how they work: they’re using the tool, but they’re still doing big, complex, multi-feature releases. Or they’re using the tool in production, but not in development. Managers need to avoid “cargo culting” at all costs: adopting the terminology and the tools without changing anything significant.

A less common, but equally fatal, mistake is to swallow uncritically the line that DevOps is about culture, not tools. So gather all your devs and Ops staff around a campfire and sing Kum Bah Yah. DevOps is all about automating everything that can reasonably be automated, and that inevitably involves tooling. You’ll see tools for testing, for continuous integration, for automated configuration and deployment, for creating containers, for managing your services, and more—even for randomly breaking things. The tools can’t be ignored.

Focus entirely on culture, or entirely on tools, and you’ll lose. You need both.

Doing DevOps

How do you get an organization “doing DevOps?” “Doing DevOps” isn’t that good a phrase, but there are some answers. Don’t go out and hire a bunch of “DevOps specialists.” Thinking about DevOps as a distinct specialty misses the point: DevOps is about getting existing groups working together, not about creating a new specialty or a new group. Definitely don’t go out and pick new DevOps-friendly office furniture. (I won’t give you the link, but that’s not a joke.) Seriously: mistakes like these send the message that you don’t know what you’re looking for, and will drive away the people you really want to hire. Though you may end up with better office decor.

If you want to get started with DevOps, start small. It started as a grassroots movement, so let it be a grassroots movement at your company. Pick a project—perhaps something new, perhaps something that’s been a problem in the past—and see what happens when you get the development and the operations groups working together. See what happens when you build pipelines for continuous deployment, use modern tools for monitoring, and get your developers and operations staff talking to one another. A top-down “We are now going to do DevOps across the company” message is likely to fail. Instead, start small, and let everyone see the results. The report DevOps in Practice shows how DevOps was introduced at Nordstrom and the Texas state government.

You don’t need to start with the project that’s most excited about doing DevOps—that might backfire. It’s hard to evaluate your progress if everyone is heavily invested in seeing a new practice succeed. By the same token, you should probably avoid groups that are resistant to change, or that see ideas like DevOps as a fate worse than death. They’ll only be convinced when they see results in other groups.

It doesn’t matter a whole lot where you start, as long as you start. DevOps isn’t about heroes, rock stars, ninjas, or unicorns; it’s about regular developers and Ops staff getting out of their silos and working with each other. It’s about automating everything that can reasonably be automated, because doing so reduces the time spent fighting fires and increases the time you can spend improving your products and services. Ultimately, that’s what’s important.

To learn more about how to leverage DevOps at your organization, attend the O’Reilly Velocity Conference, taking place in New York City (Oct. 1-4) and London (Oct. 17-20).

Alizah Epstein of Epstein Creative sat down to talk to me about designing with purpose. She aims to help mission-driven organizations (nonprofit and for-profit) clearly communicate their messages, capabilities, and brands—online, on paper, or in person.

Working in Big Business as an Underrepresented Person in Tech

This is an interview with a woman who works at bigcompany who wished to remain anonymous. We talk about what it’s like to work in a male dominated company, the importance of getting tech into young people’s hands, and why it’s important to attend conferences like Code(Her) Conference.

D.C. Web Women and Code(Her) Conference with Sibyl Edwards and Kristin Jolda

I talked to Sibyl Edwards, President of D.C. Web Women, and Kristin Jolda, the Code(Her) Conference director about the conference and what they hoped to (and did!) accomplish!

Building Community with Ksenia Coulter

Ksenia Coulter (a Greater Than Code fan already!) came in to talk to me about what she loves outside of programming: social dancing, and how the tech community could take notes on their community’s ways of socializing.

Celebrating Yourself with Abena Orteng-Agipong and Evie Series

These women: Abena Orteng-Agipong and Evie Series, have a lot to be proud of and feel accomplished about! Here, I talk to them about their achievements and goals as women in tech!

Wonder Women Tech with Lisa Mae Brunson

I was so nervous to interview Lisa Mae Brunson, the founder of Wonder Women Tech, but I did it and she was awesome.

Wonder Women Tech produces national and international conferences that highlight, educate, and celebrate women and diversity in STEAM innovation and entrepreneurialism. Their conferences and programming offer a variety of speakers, panel discussions, coding classes, workshops, hackathons, community inclusion activities, through leadership, and other dynamic programming geared towards empowering women, girls, people of color, the underrepresented, and other diverse communities.

Hear Me Code with Shannon Turner

My last interview was Shannon Turner of Hear Me Code. It’s a program she started in her apartment after not being taken seriously in tech where she taught other women to code, who taught other people to code, who teach other people to code! I thought it was an awesome concept.

I want my team to be diverse. Both for higher performance, and because it makes the world a better, fairer place.

But diversity doesn’t magically lead to higher performance.

I’ve been reading Journal of Organizational Psychology (it was a birthday present) and it has some great stuff on diversity. I had heard that diverse teams can outperform others, but that’s only under certain circumstances. Those circumstances turn out to be interesting in themselves.

Diversity (in various dimensions) can help or hinder a team’s performance. This particular article studied education-level diversity, relative to team communication quality, innovation team climate, and subjective performance.

Team communication quality. What is “quality”? Here, it is not frequency or amount of communication. It is “defined as the extent to which communication among team members is fluid, effective, clear, on time, and complete.” This relates directly to team performance.

Innovation team climate. What on earth is that? It is about “a shared perception by team members about the extent to which new ideas about work are implemented in the team.” This affects whether diversity has a negative, positive, or unmeasurable impact on a team.

When we’re looking for better ways to work, and we value the input of all team members (especially input different from our own), then we get the benefits of diversity. Hmm, this sounds familiar…

agile

I used to think that the retrospective was the core process of agile development, because it is all about soliciting ideas and implementing new ways to work. But it isn’t about the meeting — the meeting is a structured way of introducing this climate of reflection and experimentation.

Retrospectives move us toward high innovation team climate. Once we get there, we can dispense with our formal meeting. And once we have that innovation climate, we can adjust everything else — that’s why this is the most critical part of agile.

When we have appreciation of new ideas, and the whole team knows it, then we can benefit from diversity. Because we know we’re different and we like it that way, we make a conscious effort to extract information from each other. This leads to “group information elaboration — the exchange, discussion, and integration of task-relevant information and perspectives.” Higher quality communication.

scrum

On the other hand, if we have a low innovation team climate, if “members are likely to follow the standard, set procedures,” then novel approaches are seen as threats that “could disrupt normal team functioning.” Now, diversity becomes a negative.

By default, diversity leads to less communication in a team. Our human tendencies lead to categorization, the establishment of an in-group and out-group. The in-group trusts each other but not the rest of the team. Everything sucks.

conclusion

If you don’t want new ideas, diversity won’t help you. In fact it’ll hurt, and make everyone miserable. In this study, it took very high innovation team climate to get a measurable benefit from diversity, but only slightly low innovation climate to get a negative effect.

This study looked at bank branches. We might experience a stronger effect in software development because diversity, especially functional diversity (areas of expertise) is “more positively related to performance in groups with members higher in need for cognition.” The more motivated we are to process information from all team members, the more benefit we get. More complex tasks benefit more, and software is as complex as it gets.

So until you’re ready for it, diversity isn’t gonna raise your team performance. “Groups typically are poor users of their distributed information and rather focus on the information group members have in common from the start.”

If you’re looking for diversity in order to improve your team’s performance, then don’t wait for hiring to do this for you. Work on your innovation climate and your communication quality.

If you’re looking for diversity to make the world a better, fairer place, then work on your innovation climate and communication quality — because otherwise, you’re not doing any favors to the people you hire and then sideline.

References

1. Linking educational diversity and team performance: Team communication quality and innovation team climate matter
2. Richard J. Crisp. The Psychology of Social and Cultural Diversity (Social Issues and Interventions) (p. 257–264). Wiley. Kindle Edition.

The editing process is not easy. I pride myself on complete, quality audio editing and a typical episode takes me from start to finish ~ 5-9 hours. I even attend each recording live in a producer role to remind the panelists of segments that need to go in each episode! Sometimes, I’ll even ask that they go back and record certain parts for listener clarity.

After the interview is completed, the editing process itself includes editing out your typical slips of using “ums” and “ahs”, pulling together long and short pauses by panelists and guests, talking out sections where people mess up and/or start over, and editing out other nervous mistakes such as repeated words, slips of the tongue, and other blips. It also includes much, much more.

As a Penn State graduate with a Professional Writing major and Communications minor, I am also super inclined to remove other unnecessary English faux pas (but, so; so, and), and edit down sentences to make everyone’s sentence structure as concise and cohesive as possible. There’s no need to say the same sentence twice in two different ways. K.I.S.S. and all that jazz, you know what I mean?

I do not use special programs. I do not simply go in and level and compress audio. I don’t just stick intro and outro music on the beginnings and ends of shows. I edit every second of audio in each episode by hand. I listen to what people are saying and in the back of my head, I am always asking myself, “How can I make this person sound more awesome?”

After I am done the audio editing process, I go back and re-listen to the shows to make sure there aren’t any mistakes that I missed, because normally, of course there are! I edit out more “ums and “ahs” and unnecessary words and pauses. While I am doing that, I glean show notes from each episode and gather links to articles, talks, websites, etc. that were mentioned in each show. In essence, each show gets twice-over, quality control sessions.

I then pull it all together and release the episode. I publish it to RSS feeds and package everything up into a nice, little blog post for the world to enjoy. I send the shows out for transcription, and once those come back, add them in and check over them to the best of my ability.

But wait!!! My job doesn’t even stop there! Because I care about the shows that I produce, I am also very active on social media, whether it be from the actual show account or my own. I am also very vocal in Slack communities and will give behind the scene peeks into each episode process, just ask! I also work before each show is even recorded. I prepare the guests and tell them what to expect. I connect them with the panel and our listeners in various ways so that they don’t enter the conversation blindfolded and so that they have ample time to prepare to make an episode as great as possible for especially YOU as the listener!

Now here’s what I need from you to keep the show going:

We have a Patreon crowdfunding site.

We have perks for said Patreon site. If you donate just $1, you’ll still be added to our Slack Community where you’ll get exclusive opportunity to ask questions to our guests and get behind-the-scene sneak peeks and chat-time with the people you love to hear. Even if you only donate for a month, you’ll still be included in our Slack community. For life! (aka, we won’t kick anyone out if you choose to end your Patreon-age.)

We need $950/month to publish 2 episodes per month. We are going to give you two episodes per month, but we are so into giving you more. We want to do weekly episodes which doubles that cost to $1,900.

Remember how I said that we recorded our first episode of >Code yesterday? Well, we also published the show yesterday, nine hours after recording it. Normally, I ask for a week of turnaround time (transcription included) from all the other shows that I do.

Here is my personal perk for you as listeners of this particular show:

If we meet our $950 mark, you will get two shows per month and you will get the show the very same day it records. Transcription will follow a few days later. That is a process that I, myself, can not speed up.

If we double our goal, you will get four shows per month and you will still get the show the very same day it records. It’s a win/win. I get to give up more shifts at my “other job” and you get to listen to hot off the press magic-ness that is the panelists and guests of >Code.

Right now, we are completely panelist and listener supported. We are open to having a corporate sponsor or two. Our goal is to not flood the shows with 3 minutes of ads in the beginning of the shows. We’d like to spread them around and make them easy on the ears, while advertising companies and products we believe in that we also believe could benefit our listeners. If you know someone who we should reach out to, please get in touch with me directly at: mandy@greaterthancode.com.

Thank you again,

Mandy Moore(@therubyrep, DevReps, LLC)