This past weekend, I had the pleasure of keynoting at Ruby Nation. I expanded on one of the core values at Corgibytes: Communication Is Just As Important As Code.
Below is pretty much a transcript of my talk. I got great feedback and am looking forward to presenting on this topic more. If you organize a conference and want to chat about me speaking, please get in touch.
Hasn’t this been a fantastic conference Let’s give a hand to all the folks who organized this and put it together for us!
Ruby Nation is near and dear to my heart because this was the first software conference I ever attended. I saw yesterday during one of the raffle questions that a few people in the audience today who are new to coding. Your first tech conference can be intimidating. I know how you feel because that was me six years ago.
A few months before my first Ruby Nation conference, I connected with a good friend, Scott, from high school at our ten-year reunion. He was the stereotypical computer programmer. When folks asked what he did, and he said he programmed computers, most people replied “Yep. Saw that coming.”
I was not your stereotypical programmer. While I grew up with technology from an early age, as a woman, my generation was actively discouraged from believing we could participate in that industry. When I was nine, I didn’t have Hello Ruby or Goldiblox. I had Teen Talk Barbie, who told me that math was hard, and shopping was fun.
So, I went in the direction that was culturally appropriate for me, and I became your stereotypical marketer.
Anyway, at the reunion, Scott approached me said he had a business. He had built a software product but hadn’t made any sales in eighteen months. He had a marketing problem. And suddenly, my skills weren’t annoying. They were valuable.
He wanted to know if I would join him as his CEO to help him achieve his dream. He’d be Woz, and I’d be Jobs. I knew a lot about building businesses, but I didn’t know about software but figured I could learn. So we started Corgibytes together and a few months later headed off to Ruby Nation.
In 2010, things were a little different. At my first technology conference, I was one of just two or three women in the room. Most of the room looked like Scott. But there was some diversity. Some of the men had different color hair and glasses, and there were even some who didn’t have beards.
I didn’t understand most of the talks. Right before lunch, I felt like an outsider who didn’t belong. I thought about leaving.
Then, at lunch, I met Dave Bock. Then later, Jim Gay. They both made me feel like I did belong, even though I didn’t look like everyone else and was new to programming.
As I kept learning, the Ruby community was incredibly welcoming. You told me:
- You belong here
- How can we make it better?
- I believe in you
One of the folks I met at my first conference was Jeff Casimir, who now runs the Turing School. He gave a talk about being a polyglot developer, which is someone who codes in several languages. I felt so welcome and encouraged by my new friends that I worked up the gumption to give a lightning talk.
I stood up on stage, brand new to coding, and suggested there was another language folks could add to their tech stack...English!
We are quickly approaching a world where communication skills are no longer optional. You can’t choose between being technical or non-technical. You have to be both.
So I’d like to teach you what I know about communication, just like you taught me how to code.
In twenty minutes, I’m going to give you the most salient points of what I’ve learned about communicating in the past fifteen years. Now, this was tough to distil down. I could probably write an entire book on this topic, but I think it starts by asking the question: what is communication?
We can look at events. Some events have to happen at the same time. They’re synchronous. Others don’t have to happen at the same time. They’re asynchronous.
There are some obvious examples here;
Phone calls, meetings, Screenhero. Those are synchronous. Twitter, text messages, email; those are asynchronous.
Then there are some non-obvious forms of communication.
On the synchronous side, things like eye contact, body language, whether or not you show up to an event on time or late.
Those happen at the same time, but because they’re non-verbal, we don’t often think of it.
There’s also idle chit-chat. If you’re talking about work in a non-work context, that’s still communication. When you’re in the buffet line at your cousin’s wedding, and someone asks what you do, you are having an impact on the sales of your company whether you know it or not.
On the asynchronous side, we have things like commit messages, which we believe will always be the best form of documentation. Think of the times you’ve run git blame and then it came up as yourself. Explaining the rationale of your commits is super helpful to others, even your future self.
We also have names: variables, methods, classes. Writing scenarios in Cucumber and examples in RSpec. Are you naming things in a way that makes sense to other people? Or are foo and bar your best friends? If you want to know more about naming, I suggest reading Arlo Belshee’s series on How Naming is a Process, Not a Single Step.
Okay. Back to the grid.
Many of us are consultants and have to fill out timesheets. Do you fill out the comments? That’s a form of communication.
We do code reviews on Pull Requests. Those comments that you leave? Yep. You guessed it. Communication.
And finally, my biggest pet peeve: error messages. How many of you have ever come across a completely useless error message when you’re working? It's so frustrating! I sometimes feel like my mission in life is to rid the world of bad error messages by teaching developers how to communicate well.
So here’s how I define communication.
It’s just the artifacts of your ideas. That’s it. Communication isn’t that different than code, and it’s just as important.
So at Corgibytes, all we do is legacy code. We do a lot of upgrading from Rails 2 or 3 apps, adding automated test suites, paying down tech debt. I sometimes say we’re the janitors of the internet.
But we’re the happiest damn janitors you’re ever likely to meet. We really like what we do. And a lot of that has to do with how much emphasis we put on communication.
Most people hate working on legacy code, but I think part of the reason is that legacy code is notoriously void of communication.
Michael Feathers defines legacy code as “code without tests”, but I’d like to expand that. It’s code without communication artifacts, of which tests are just a small part. Without communication, working on a codebase you didn’t write is difficult.
Okay. So why does this matter?
Three reasons.
First, getting better at your communication is the best way to level up your career.
If you want be a Lead Dev, a CTO, or own your own business, communicating effectively with people who don’t code every day is a big part of your job.
If you want people to contribute to your open source project, communication is what makes them feel welcome and keeps them around.
And if you want other people to use your ideas, you need to learn how to blog, speak, and maybe even write books. All of that is communication.
The next reason is that communication builds trust.
In her book, Daring Greatly, Brené Brown describes trust as a marble jar. Her daughter’s teacher would drop a marble in a jar when the class behaved, and when they got to the top, they got a pizza party. Trust works the same way. It’s built over time by a series of very small interactions.
Those small interactions are communication. Every artifact is a marble in the jar. Every time you communicate. Every time you leave an artifact of your ideas, you are communicating and building trust.
And finally, good communication is the best way to ensure you don’t run around and fight fires all the time.
At Corgibytes, one of our core values is Calm the Chaos. We believe the best solutions to problems don’t happen when you’re stressed out and pumped full of adrenaline. It comes when you’re calm, rational, and using your prefrontal cortex. That can only happen when your culture is soaked in good communication.
The good news is that there are several patterns and frameworks we can lean on to improve our communication. I’m going to go over my three favorites.
But first, let’s note how these aren’t static. In his book Refactoring to Patterns, Joshua Kerievsky talks about how you can move towards or away from patterns through all of the small choices you make. Improving your communication works the same way. It takes awareness and happens when you make the conscious choice refactor your habits.
The first concept we’ll touch on is about context switching. There is a real cost associated with this. You know it. But how do you communicate that with your teammates who don’t code?
Here's how I learned. (Check out the more detailed blog post.)
For years, when I needed to get Scott’s attention, I’d ask "Hey, Scott — you got a sec?". I thought it was polite. I wanted to honor his time and not bother him if he was busy. At the same time, I was usually blocked. I tried not to disturb him needlessly. The answer could have well been “no” and my response would have been, “No worries. Get back to me when you can.” But it never happened that way. Instead, I got complete and utter frustration.
One day, after Scott got frustrated, he responded, “I was at level Nine.”
“Level Nine?”
“Yeah. Like in the movie Inception.”
In the movie Inception, there’s the idea of a “dream within a dream.” This happens in engineering too: a mental model within a mental model. The more models you have to keep in your mind at one time, the more time it takes to build up to that state. If you come out of it too quickly, you almost get the mental equivalent of decompression sickness.
So we developed a framework to help us communicate whether we're interruptable.
If all he has to do is label where he is, he can communicate whether he’s interruptible without switching context. Anything above two, and he comes back to me when he’s safely back on the surface.
Next is what I call the Shattering Glass pattern.
You want to be less like Ted and more like Tina.
In the show How I Met Your Mother, Ted starts to notice how often he says the words, "Well, actually." And every time he does. Glass shatters above his brain as he realizes how much he does this.
This language is divisive. His friends don’t like it. And your marketing friends like this about as much as you like it when they say “Do you have a sec?”
A better way to do this is to replace your well actually with "Yes, and."
This comes from Tina Fey’s book Bossypants where she describes how she learned improv. "Yes, and" is language that unites.
For example, let's say a client comes to you with a requested scope change. That never happens, right?
“Well actually, that’s not in the contract….” promotes hostility and defensiveness. So here's a different way you can say the same thing that promotes collaboration.
“Yes. I see how that’s important to you. And we’ve already started a sprint. Let’s have a conversation about how that change will impact things and find a way that works for both of us.”
So the last pattern is how to avoid sounding like a jerk.
This is Kim Scott’s Radical Candor framework.
There are two axes. The way Kim Scott describes them is the vertical one labeled "Caring Personally" is what she calls the "give a damn axis." The other, labeled "Challenge Directly" she says is the "willing to piss people off" axis.
When you give feedback, you want to be both. And she gives the acronym of HHIPP to remember how to speak with Radical Candor:
"Radical candor is humble, it’s helpful, it’s immediate, it’s in person — in private if it’s criticism and in public if it’s praise — and it doesn’t personalize.” That last P makes a key distinction: “My boss didn’t say, ‘You're stupid.’ She said, ‘You sounded stupid when you said um.’ There's a big difference between the two." -Kim Scott
If you get nothing out of this talk, remember communication is a skill. You can learn how. If you can learn how to code, you can learn how to communicate.
And know that I believe in you. Just like you believed in me and told me I could learn how to code when I didn’t believe in myself, let me offer you my full support.
Here are some resources to help you get started.
My challenge to you is to think back to Elle’s first talk that opened this conference. Adopt a growth mindset. Believe you can learn and find a book or a class to get you started.
Dive in and get curious about communication the same way you learned how to code.
And I’m happy to help you. Here’s my contact information. I hope you reach out to me on Twitter and tell me about what you’re up to.
If you happen to like legacy code, I hope you join our community over at LegacyCode.Rocks. There’s a slack channel where you can hang out with other folks who love remodeling software.
And I blog over at Empathy Driven Development, so if there’s anything you want to contribute, please get in touch.
And here’s a link to my calendar so we can schedule a synchronous event and get to know each other better. I really hope to hear from you.
And yes, I have stickers.
Thank you.
This post originally appeared on Corgibytes.com