Title: Speak Up! (Part 2)

Author: Martin Moene

Date: 09 January 2017 21:07:06 +00:00 or Mon, 09 January 2017 21:07:06 +00:00

Summary: Pete Goodliffe talks to us about communication.

Body: 

First learn the meaning of what you say, and then speak.
~ Epictetus

In the previous ‘Becoming a Better Programmer’ column I started to look at how we, as programmers, communicate. We reminded ourselves that code is communication, and considered how to improve our communication in that medium.

Now, let’s look at the communication most people would expect us to ‘talk about’ – interpersonal communication. Programmers are never solely confined to the act of writing code. We have to work with other people: with other coders, with the wider development team (testers, UX, managers), and even – shock horror – with the customer.

Interpersonal communication

We don’t just communicate by typing code. Programmers work in teams with other programmers. And with the wider organisation.

There’s a lot of communication going on here. Because we’re doing this all the time, high-quality programmers have to be high-quality communicators. We write messages to speak with, even gesticulate at, others all the time.

Ways to converse

There are many communication channels we use for conversations, most notably:

• Talking face-to-face
• Talking on the phone, one-to-one
• Talking on the phone in a ‘conference call’
• Talking on VoIP channels (which isn’t necessarily different from the phone, but is more likely to be hands-free and allow you to send files over the same communication channel)
• Email
• Instant messaging (e.g., typing in Skype, on IRC channels, in chatrooms, or via SMS)
• Videoconferencing
• Sending written letters via the physical postal system (do you remember that quaint practice?)
• Fax (which has largely been replaced by scanners and common sense; however, it still has a place in our comms pantheon because it is regarded as useful for sending legally binding documents)

Each of these mechanisms is different, varying in the locations spanned, the number of people involved at each end of the communication, the facilities available and richness of interaction (can the other person hear your tone of voice, or read your body language?), the typical duration, required urgency and deferrability of a discussion, and the way a conversation is started (e.g., does it need a meeting request to set up, or is it acceptable to interrupt someone with no warning?).

They each have different etiquettes and conventions, and require different skills to use effectively. It is important to select the correct communication channel for the conversation you need to have. How urgent is an answer? How many people should be involved?

Don’t send someone an email when you need an urgent answer; email can sit ignored for days. Walk over to them, ring them, Skype them. Conversely, don’t phone someone for a non-urgent issue. Their time is precious, and your interruption will disrupt their flow, stopping them from working on their current task.

When you next need to ask someone a question, consider whether you are about to use the correct communication mechanism.

Master the different forms of communication. Use the appropriate mechanism for each conversation.

Watch your language

As a project evolves, it gains its own dialect: a vocabulary of project and domain-specific terms, and the prevalent idioms used to design or think about the shape of the software design. We also settle on terminology for the process used to work together (e.g., we talk about user stories, epics, sprints).

Take care to use the right vocabulary with the right people.

Does your customer need to be forced to learn technical terms? Does your CEO need to know about software development terminology?

Body language

You’d be upset if someone sat beside you, sparked up a conversation, but spent the whole time facing in the opposite direction. (Or you could pretend they were from a bad spy movie; I hear the gooseberries are doing well this year...and so are the mangoes. [1])

If they pulled rude faces every time you spoke, you’d be offended. If they played with a Rubik’s cube throughout the conversation you’d feel less than valued.

It is easy to do exactly this when we communicate electronically; to not fully respect the person we’re talking with. On a voice-only conversation, it’s easy to zone out, read email, surf the Web, and not give someone else your full attention.

Having fully embraced our modern, always-connected, broadband age, I now default to selecting a video-on communication channel. Often I’ll kick off a conversation that might have been via phone or instant message with a VOIP video chat. Even if my conversant will never enable their own video, I like to broadcast a picture so that my face and body language are clearly visible.

This shows I’m not hiding anything, and fosters a more open conversation.

A video chat forces you to concentrate on the conversation. It engages the other person more strongly, and maintains focus.

Parallel communication

Your computer is having many conversations at once: talking to the operating system, other programs, device drivers, and other computers. It’s really quite clever like that. We have to make sure that our code communication with it is clear and won’t confuse matters whilst it’s having conversations with other code.

That’s a powerful analogy to our interpersonal communication. With so many communication channels available simultaneously, we could be engaging in office banter, instant messaging a remote worker, and exchanging SMSs with our partner, all whilst participating in several email threads.

And then the telephone rings. Your whole tottering pile of communication falls over.

How do you ensure that each of your conversations is clear enough and well-structured so it won’t confuse any other communication you’re concurrently engaged in?

I’ve lost count of the number of times I’ve typed the wrong response into the wrong Skype window and confused someone. Fortunately, I’ve never revealed company confidential information that way. Yet.

Effective communication requires focus.

Talking of teams

Communication is the oil that lubricates teamwork. It is simply impossible to work with other people and not talk to them.

This, once more, underscores Conway’s law. Your code shapes itself around the structure of your teams’ communications. The boundaries of your teams and the effectiveness of their interactions shapes, and is shaped by, the way they communicate.

Good communication fosters good code. The shape of your communications will shape your code.

Healthy communication builds camaraderie, and makes your workplace an enjoyable place to inhabit. Unhealthy communication rapidly breaks trust and hinders teamwork. To avoid this, you must talk to people with respect, trust, friendship, concern, no hidden motives, and a lack of aggression.

Speak to others transparently, with a healthy attitude, to foster effective teamwork.

Communication within a team must be free-flowing and frequent. It must be normal to share information, and everyone’s voice must be heard.

If teams don’t talk frequently, if they fail to share their plans and designs, then the inevitable consequences will be duplication of code and effort. We’ll see conflicting designs in the codebase. There will be failures when things are integrated.

Many processes encourage specific, structured communication with a set cadence; the more frequent the better. Some teams have a weekly progress meeting, but this really isn’t good enough. Short daily meetings are far better (often run as scrums, or stand-up meetings). These meetings help share progress, raise issues, and identify roadblocks without apportioning blame. They make sure that everyone has a clear picture of the current state of the project.

The trick with these meetings is to keep them short and to the point; without care, they degrade into tedious rambling discussions of off-topic issues. Keeping them running on-time is also important. Otherwise they can become distractions that interrupt your flow.

Talking to the customer

There are many other people we must talk to in order to develop excellent software. One of the most important conversations that we must hold is with the customer.

We have to understand what the customer wants, otherwise we can’t build it. So you have to ask them, and work in their language to determine their requirements.

After you’ve asked them once, it’s vital to keep talking to them as you go along to ensure that it’s still what they want, and that assumptions you make match their expectations.

The only way to do this is in their language (not yours), using plenty of examples that they understand – for example, demos of the system under construction.

Other communication

And still, the programmer’s communication runs deeper than all this. We don’t just write code, and we don’t just have conversations. The programmer communicates in other ways; for example, by writing documentation and specifications, publishing blog articles, or writing for technical journals.

How many ways are you communicating as a programmer?

Conclusion

A good programmer is hallmarked by good communication skills. Effective communication is:

• Clear
• Frequent
• Respectful
• Performed at the right levels
• Using the right medium

We must be mindful of this, and practise communication – we must seek to constantly improve in written, verbal, and code communication.

Questions

• How does personality type affect your communication skills? How can an introverted programmer communicate most effectively?
• How formal or casual should our interactions be? Does this depend on the communication medium?
• How do you keep colleagues abreast of your work without endlessly bugging them about it?
• How does communication with a manager differ from communication with a fellow coder?
• What kind of communication is important to ensure that a development project runs successfully?
• How do you best communicate a code design? They say a picture speaks a thousand words. Is this true?
• Do distributed teams need to interact and communicate more than co-located teams?
• What are the most common barriers to effective communication?

Reference

[1] See the ‘Secret Service Dentists’ sketch from Monty Python’s Flying Circus

Notes: 

More fields may be available via dynamicdata ..