In software engineering, we work as a team. And communication can be a massive bottleneck to delivery in large groups or distributed teams.
‘Communicate with Purpose’ is one of the Gojek values. This particular value has always drawn my attention. However, it comes across as a little cryptic to me at times. I have felt shy in seeking help or asking questions in the past. And more often than not, it takes enormous courage to speak up when something doesn’t feel right.
The phrase ‘Communicate with purpose’ talks about communication and doing so with purpose. What does that mean? The closest I can get to comprehend this concept is to understand my intention behind any communication. In rather general terms, it demands me to think before I speak and find clarity on a good reason to say something out loud. That is very different from posting anything on Twitter. Why? Because
You only get what you ask for
In this post, I will use aphorisms from the Zen of Python to understand communication. These aphorisms are a collection of guiding principles of Python’s design. They can be beneficial while writing software that is a delight to work with for all its users.
Code is the way two programmers communicate with each other. This communication happens over very long time durations at times and is primarily asynchronous. These constraints demand finesse while writing any program. However, communicating with other humans is more straightforward than writing code. Our facial expressions and body language do half the job. Eyes speak louder than our words. Still, these ideas from the Zen of Python inspire me to improve my day-to-day communication skills.
Let’s see what this doctrine has and how we can draw analogies to better our communication concerning software engineering -
“Explicit is better than implicit.”
from zen of python
We assume all the time. But, while we do that, the other people we are communicating with also make their own assumptions. It all becomes a Chinese whisper in everybody’s head. Person A says X while he means Y, and person B thinks person A means Z. It can all become chaotic as the number of parties involved in the communication increases.
“In the face of ambiguity,
refuse the temptation to guess.”
from zen of python
With every new node in the communication graph, the overhead increases not linearly but combinatorially. Because the rise in complexity is so steep and we can not get away from the large distributed teams that most of us have worked in, clear and crisp communication becomes the utmost necessity in such an environment.
State the obvious - Manage surprises
Often, we don’t voice our opinions because we feel that what we are going to say is obvious. But, if you think about it with the Chinese whisper perspective shared in the previous paragraph, you see that nothing is evident in such a scenario. People can take different meanings out of the same conversation. So, always state the obvious.
There is nothing like over-communication.
There is a common sentiment to not communicate over and over again over a while. This sentiment leads to us not sharing when changes in the plan or progress or issues are faced. There can be instances of Too-much information but not over-communication. Too much information can happen when you delve into the details that are not interesting to others. However, it is different from communicating iteratively.
Repeat that narrative
I often spend a lot of time on an idea to think it through. Brainstorming the pros n cons is a part of my process of making informed decisions. And the process involved repeatedly thinking about the same narrative from different perspectives or lenses. So, let’s do it more often with the broader groups to discuss the ideas in more open settings. It will also help build the ground for the concept or its successor before it starts to happen. So, repeat your narrative, and keep doing it tirelessly.
from zen of python
In the context of communication, the grasp of the idea counts. Think about why you have a particular opinion if you were to explain it to a kid and how you will go about it. How clear are you with your ideas? Another rule from the zen of the Python comes to the rescue -
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.