Introduction
Before we dive in, let me ask you three questions:
Have you ever talked to someone who often speaks in circles?
Have you ever read a message that felt frustrating and confusing?
Have you ever talked to someone whose points people always find hard to understand?
Personally, I have experienced this many times. In fact, in my younger years, I was a horrible communicator. I was that person people would find frustrating to communicate with.
Communication is an important skill. Both oral and written. This doesn't only apply to software engineering, but to many things in life.
I can state this without a doubt: Effective communication is pleasant. Ineffective communication is frustrating.
For transparency: I asked ChatGPT to generate the examples.
Let's dive in!
What is communication?
Communication in software engineering happens on many levels. Excitingly, code itself is communication!
In this post, communication means spoken and written communication. For instance, chatting in Slack or discussing over a video call.
Effective communication
I have worked with, helped and interviewed many developers. Both at and outside work. I have seen both effective and ineffective communication take place. The contrast is visible.
Concise
Keep it concise. Get to the point. Don't talk in circles. If you find yourself often end up talking in circles, take more time to think before speaking!
This applies to written communication too. People are taking their time to read your messages. Keep the messages efficient, short and clear.
The last thing people want is to read a long message and still not understand your question or the point you are trying to make.
For instance:
It is of the utmost importance for us to conduct various forms of testing procedures on the software in question before it is made available for public release in order to ensure that it functions as intended and contains no bugs.
A better version of it:
The software needs to be tested before release.
Don't repeat yourself
You may have heard this in middle school. I did many times. It is important though.
Don't repeat yourself. It is more text to read. It is frustrating. I'm taking my time to read your message and you're bringing up the same thing three times in slightly different ways.
Repetition can come in a direct form or slightly different ones. Be aware of this.
For instance:
The feature is ready for launch and we have completed all of the necessary preparations and testing, and as a result, we are able to schedule the launch for next Tuesday.
A better version of it:
The feature is ready for launch, we can schedule it for next Tuesday.
When writing a message, make it easy to read. Don't make it hard to read. One point I already brought up is keeping your sentences concise.
However, this isn't just about the sentences. It is also about the way you structure your message.
Give some space in your messages
Use bold or italic styles when they make sense
Keep related sentences together.
For instance:
The new feature we are working on is really important for our customers and we need to make sure it is implemented correctly. First, we need to gather requirements from the stakeholders and then we need to design the feature. After that, we will begin development and testing. Once the feature is completed and all the bugs have been fixed we can finally launch it. This whole process is going to take some time but it's worth it in the end because it will greatly benefit our customers
A better version of it:
We're working on a new feature that will greatly benefit our customers. Here's what the process looks like:
It will take some time, but it's worth it for our customers.
Background story
Not everyone will know what you're working on. Even if they do, they might not have the entire context.
If you plan on asking something that requires more context, share the necessary background information.
Remember, keep things concise. You don't want people to read an entire essay, although a few sentences were necessary.
This also applies to oral communication. Don't start ranting for ages. Rant for a moment, then check in with the listeners whether they have grasped the context or not.
Ask or repeat the question
This is a mistake I see many candidates that interview at our company do. They answer questions right away.
A few points to bring up about why this isn't good:
Blindly answering things
End up answering the question wrongly, and instead answer another question that wasn't even asked
A bad approach to solving problems. A red flag in our notes.
You don't always have to reply with a question (to better understand the problem).
You can repeat the question and make sure the other person is on the same page. When repeating the question, it doesn't have to be the same phrase but repeat it as you have understood it.
Just to emphasize, this doesn't only apply to coding interviews!
The right language
Keep the language in mind. It is not befitting to speak to everyone on the team as you speak to the developers. Everyone on the team may not understand the technical language of developers.
However, it depends. In some companies, product managers code and are technical.
Yes, having fostered a ubiquitous language in the company or team will help with this aspect of communication drastically. Though, not all companies do that!
For instance, speaking to a non-technical product manager:
We're running into some issues with the scalability of the system due to the way the data is being stored in the database. I think we should look into using a NoSQL database instead of the current relational one. We can also implement some caching mechanisms to improve the performance.
A better version of it:
We're having some problems with the system being slow when more users are using it. I think we need to change the way we're storing information in the computer to make it faster, and also adding a way to temporarily save information so the system can access it faster.
Disagreements
The ability to productively navigate disagreements is a crucial skill in communicating effectively. I have written about it here.
If I could summarize approaching disagreements:
Don't reply with an answer, reply with questions that help both parties get to the same conclusion
Celebrate productive disagreements: During these times exciting discussions occur, discussions we can learn most from.
Conclusion
Communication is a vital part of software engineering. Becoming a more mature software engineer includes bettering how you communicate.
Communicate effectively, save your team time, make lives easier and avoid frustration.
