Communication Styles and Learning

2017/05/26

Before I became a programmer, my previous life was in the agency world - specifically, in our agency’s consulting division. Half of my job was managing projects and people as we crafted new branding and communcations plans; the other half was moderating workshops with executive teams to assure them that, no, they weren’t dysfunctional and yes, we could help communicate a broader message during change initiatives.

During my tenure at my old firm, we used several abstractions that we called “tools” to encapsulate ways that teams of people could better understand each other and communicate more effectively.

One of my favorite tools was a tool called “Speak to Think”. This tool was meant to show two different styles of communication, and how a person could help themselves be more easily understood in a group discussion. I’ve found it to be incredibly useful to think about when I need to communicate during a pairing session.

Here’s the basic overview. Essentially, a person’s natural comfort zone for communication can fall into one of two buckets:

Speak to Think

“Speak to Think” personalities do their best mental processing aloud - whether that means pacing the room, talking out their problems (or rubber-ducking), or just typing and deleting code, a “speak to think” personality thinks best when emoting.

I personally a more “speak to think” coder; I’m the sort of person who needs to put garbage or psuedo-code into my IDE and mess with it to comeup with a coherent solution. I noticed, during my early pairing sessions, that this was irritating to colleagues or just confusing, because they couldn’t tell which code was meant to be permanent and which was just my mental musings writ small. So, now I tend to say before I start typing:

Okay - sorry if this is odd, but I personally think best when I can type things out and see the code, even if it’s just psuedo-code and not actually syntacically correct. Do you mind if I start putting some stuff down and we can throw rocks at it? Not at all meant to be final, it just helps me process what we’re trying to solve.

99.9% of the time, the person agrees and we can go through it together. Just that simple act of being intentional and communicating your actions goes a long way. I know this sounds mind-numbingly obvious, but when you’re in a stressful situation or deep in a code problem, it can be easy to climb into your own head and start communicating poorly. I try to very intentionally say what I’m doing and what my intentions are, so my partner is on the same level.

Think to Speak

A person who “thinks to speak” is the opposite of a “speak to think” person, in that they prefer to solve the problem in their head or fully complete the thought before communicating or writing it.

I’ve paired with several of these people during my bootcamp, and would run into a similar situation: each time during our pairing session, there would be a period of time where the individual would stop typing, sit and stare at the computer silently for about a minute. They would say nothing to me, and give no indication of what they were thinking. As a very emotive thinker, I would get antsy during these long periods of sudden silence, wanting to start typing or start talking or just make sure I was working on the same problem as they were.

There’s nothing at all wrong with being a “think to speak” developer! Some of the most intelligent people that I’ve worked with in my career have this mentality - a favorite old boss was very “think to speak”. Just make sure that you’re intentional about communicating with your teams or your pairing colleague when you need this time, so that they’re tracking with you. Even something as simple as this:

So I’m the kind of person who really likes to think it out before I start putting anything down, so I might just need a minute to sit here silently and take everything in before I can start talking this out with you. Is that cool? I’ll let you know when I’m done, it won’t take too long, and then we can start working.

Mentally, this will do two things: it will put your partner at ease, because they better understand what you need and what you need from them, and it will give you an uninterrupted period in which you can do your thinking. Perfect!

Hybrid styles under stress

It’s rare that people are purely one way or another in how they process information and solve problems. Most of the people you meet will be some hybrid variation of the above two styles, reacting in different ways depending on the subject matter and environment.

Working in tech is a very stressful environment, and I’ve noticed that these patterns of behavior will get especially pronounced under stress. If I’m working on a very difficult problem, I’ve caught myself doing a very bad job of communicating with my partner - I’ll start changing code, trying to break things and testing different syntax, leaving my partner wondering what the hell I’m doing or thinking. Conversely, I may stop entirely and say nothing for a long period of time or give a distracted response because I’m very deep in my own head trying to solve one part of a problem - while my partner is trying to solve a different problem entirely.

Communication hiccups are normal during a pairing session, especially with two junior developers trying to solve an advanced problem. What I find helpful is to look for these triggers, and remind myself to take 30 seconds to communicate clearly and explain that any reactions I might be having are from my learning style, and not a deficiency of my partner.