Why communication is important
Communication failure will eventually make its members fail to understand what makes themselves more efficient, because they themselves fail to get feedback from others on the team.
I believe that it is better to be looked over than it is to be overlooked — Mae West, Belle of the Nineties, 1934
We can learn from the quote above. It’s not just what we think, but how we package it. Having the best ideas, code with the best approaches, or even the most pragmatic thoughts will eventually evaporate, unless we can pass them on to others. Brilliant ideas will be in vain without effective communication.
As developers, we also communicate at various levels. We spend hours in meetings, listening, and talking. We also meet with end users, trying to understand what they need. We also write code, indirectly we also communicate with machines and pour our thoughts into lines of code. We also write SAD (service architecture diagrams) or memos to report on the status of work, or maybe give advice to superiors if we come across a new approach. And don’t forget, we also work in teams. Most of our day is spent communicating at various levels and in various forms. So, we need to do well.
Treat “bahasa indonesia” (or whatever language we use) like any other programming language. Write our conversations as we write code: respect the principles of DRY (don’t repeat yourself), ETC (easier to change).
English is just another programming language.
Know your audience
We communicate only when we have information that needs to be shared. To do that, we need to understand the needs, interests, and abilities of the other person. Imagine we are in a meeting where the product engineer team is staring intently at the VP of Marketing with a long monologue about the benefits of using microservices. The situation is not communication. It was just a lecture, and it was very boring.
Let’s say we want to suggest the use of the microservice for next year’s Harbolnas campaign. We can describe the system of the microservice in several different forms, depending on the audience we are talking to. Explain that by using this approach, customers will easier to find banner campaigns, just from the homepage of our application or website. The marketing team will also easier to upload banner campaigns according to the targeted market.
Managers in the marketing division have at least two positive reasons to use the microservice: the marketing team can easily run their campaigns and the target market is right on target. Finally, the idea that the product engineer team proposes can be seen by even non-tech people. And meeting participants will also be excited to execute the project.
Know what you want to say
| Photo by Kyle Glenn on Unsplash |
Perhaps the most difficult part of a more formal style of communication is knowing what you want to write. Fiction novelists often plan their books in detail before they start writing. But people who write technical documents often sit at the keyboard, and directlt write:
- Preface
and start typing whatever pops into their heads.
Plan what we want to say. Write the outline. Then ask ourselves, “does this communicate what I want to express to my audience in a way that works for them?”. Complete the writing until we think it is clear.
This approach applies not only to document writing. When you’re faced with an important meeting or phone call, jot down the ideas you want to communicate, and plan some strategies for conveying them.
Now that we know what our audience wants, now plan how to go about it.
Choose your moment
Imagine it is six o’clock in the afternoon on a Friday. Some of our coworkers are already packing to leave their desks. Some went straight home, some stopped by the cafe to meet their old friends. They are ready to welcome the weekend, and this might not be a good time for us to ask them to do a code review for our pull requests.
As part of “know your audience”, we need to know their priorities at that time. It’s Friday and our co-workers want to end their working hours. Code review is certainly not something urgent. We can postpone until Monday to ask him for help.
Sometimes all we need is a simple question, “is this a good time to talk about it?”.
Choose a style
Adjust the writing style to the people who will read our writing. Some people want to-the-point writing, others like long chats before getting to the heart of the message. Also pay attention to their level of expertise and experience. Are they experts, or are they just beginners?
If we see that the person receiving our message is having a hard time understanding our style of language, then always be open to feedback. From their input, we can be better.
Make it look good
Your ideas are important. They deserve a good-looking vehicle to convey them to your audience.
Many software engineers (perhaps at the manager level) focus solely on content when creating written documentation. It would be better if we also pay attention to how to convey the message, the diction we choose, to the arrangement of paragraphs that make the reader comfortable.
| Photo by siriwan arunsiriwattana on Unplash |
There is currently no excuse not to produce bad documentation. Many modern software can produce good output, regardless of whether we are writing using markdown, or using a word processor. We just need to learn some basic commands. If we use a word processor (Microsoft Word or Google Docs), use the style sheet to make it consistent. Learn how to set page headers and footers. See also sample documents (usually companies already provide this as a reference). Check the spelling of the word so that nothing is missed by the reader.
Involve your audience
We often find that the documents we produce end up being less important than the process we went through to produce them. If possible, involve the target audience of our document from the start. Get feedback from them. We can build a good working relationship from the process.
Be a listener
There is only one technique we must use to get people to listen to us: listen to them first. When we are one of the people who understand the most about a concept in a forum, or when we are presenting in front of dozens of people with suit-and-tie, if we don’t listen to them, they won’t listen to us either.
Encourage them to talk by asking questions, or by asking them to summarize what we have told them. Turn stiff meetings into dialogue.
Get back to people
If we ask someone directly, they will feel rude if they don’t answer our question. But how often do we fail to get a response from others when we ask via email or memo?
In the daily grind, this is often forgotten. If you get an email from someone else, always respond immediately, even if it’s just “I’ll call you later”. Such actions make them feel that we have not forgotten them.
The key is to be effective. As much as possible make the communication that we establish as effective as possible, even though the communication activities do not occur directly face-to-face.
Documentation
Usually, software engineers don’t pay much attention to documentation. Documentation is often seen as an unfavorable requirement, or at least if we are working on documentation, the task is given the lowest priority. “Of course. It’s more important to make feature A than to sacrifice time to make documentation.”.
Documentation should be used as an integral part of the entire development process. With documentation, our work will be easier because we don’t need to waste time or “copy-paste” our previous work.
It’s easy to generate good looking documentation from comments that we embed in the source code, and it’s also advisable to insert comments into the exported module or function so that other programmers can understand quickly.
However, that does not mean adding comments in every function, data structure, declaration, etc. is justified. This method is only suitable for short-term solutions. If we always add comments every time we add a function, it means that the function that we created is not explicit because it needs an explanation from the outside instead of the written function already explaining the logic being done.