The interpreter approach

One of the most difficult things to understand for software developers, when they are at the initial stage of their career, is that coding is all about communication. Not only communicating intention in the source code, like a good clean coder would do, but to communicate with your fellow developers, as well as with other stakeholders in the project you’re working on.

Today I want to showcase an example that, is in my opinion, a really good instance of smooth and clear development team communication. Let’s see the following screenshot:

Pull request discussion

Click to enlarge

At we use a pull request approach to code review between teammates. The purpose is two-fold: we get our code reviewed in terms of quality, but we are also sharing the knowledge with other members of the team. This way nobody is the only one to have looked over an specific piece of code.

In this specific pull request, the lead developer is trying to correct a small “misbehaviour” of the developer, and happily enough, he’s trying to make him communicate the code intention in a better way. At first, the developer reply seems like no big deal, but if you read it paying just a bit of attention, it could come across as a little defensive. Sort of passive-aggressive reaction to what he’s asked to do, or to the critique he’s receiving.

From what the lead said, you can guess that this is not the first time that the correction is being made, but as an empathetic person you can understand why the developer felt the need to defend himself: the word “always”, as he states, seems a bit too strong. So here comes the CTO…

A previous version of myself would have waited until they resolve the situation. Sometimes the best action is to take no action, but that doesn’t come without dangers. An even younger version of myself would have said something short and harsh to any of them, “teaching” them “how to behave properly”; but only making things worse. On the surface the problem would look like it was solved. Beneath it, feelings would start to take over for the developer or the lead.

What I took here is what I call the interpreter approach. A good CTO has to be able to speak different languages (business, technical, formal, casual) depending on the context. But if you want to be an excellent CTO you have to understand one extra language that is not so evident: feelings.

So what were the goals when I started typing my comment on the pull request? Let’s see:

  1. Translating to the lead what the feeling of the developer was when he read the word “always”.
  2. Making the developer see that there was no bad intention in the phrasing, teasing a bit the lead  on the way about his english level.
  3. Explaining with a neutral language that should not hurt anybody the reason of the correction.
  4. Make everybody smile with the joking image, so the general feeling at the end is a warm friendly one.

As you can see, it’s all about appealing to the feelings, trying to soothe them down, while still being able to communicate the technical message to everybody.

And what about the reaction of the lead to the little teasing? Brilliant!

So, in brief, if you want to be a good team leader, but also a good team player, communication, empathy and language mastery is key. Because coding is communicating.