"Good communication is the bridge between confusion and clarity" according to Nat Turner. If confusion grips your project on a daily and weekly basis, as I often find for many projects, then it befits the entire team to recognize, accept, and address the root cause: we are not doing a very good job communicating our ideas.

Good communication is the bridge between confusion and clarity

I would even make the case that the majority of the more recognizable smells, anti-patterns, and mistakes are just specific instances of failures to communicate: incomplete requirements, wrong abstractions, ticket deadlocks, and failing processes to name a few.

Defining Communication

The concept of communication is deep, and should rightly be considered a critical skill needed for success in any endeavor, and one that has to actively be honed. With that being said, the fundamental fact of communication is that the ability to express oneself pales in importance to the ability to listen. Being mindful of this listening component is important when understanding how it impacts a software project.

I also highlight an ofter overlooked fact, source code is a form of communication. It is probably the most complex way that people communicate in a regular basis. When writing source code, the author is writing for at least two audiences, humans who will read it to derive specifications and to maintain it, and for compilers that will execute its instructions in the most strict of adherence to grammar and syntax. When evaluating the competency of a prospective software engineer, their ability to speak, write, read, listen, and communicate is going to be a much better predictor of their capacity to read and write source code than something more relatively banal such as calculating time and space complexities of a given algorithm. This is why I repeatedly endorse the merits of linguistic skills over all others, and that the right way of judging code is by clarity, lucidity, and understandability, and not complexity, sophistication, or even elegance. Experienced engineers write code that is easy to understand, not code that is so complex that only experienced engineers could comprehend it.

Outside of code, consider all of the following things and how they are manifestations of communication: unit tests, designs and diagrams, READMEs, meeting notes, agendas, emails, Slack threads, discussions, tickets, comments, code reviews, and on and on... All of these activities are chances to contribute to the success of the team, or to miscommunicate.

Examples of miscommunication and examples

With so many ways to fail to communicate, one should never underestimate how much these failures can harm a project.

A Thought Experiment

To further cement this idea, just think back to the last hardship or failure on your current project. Was it caused by bad communication, or could have it been prevented with better conversation? I thought so 😀.

Recommendations

For you and your Career

My first recommendation is to understand the true gravity that miscommunication has on a project. Additionally to this, and my objective of the article, is that I want you, as civilly as possible, to call out miscommunications loudly and often as they create hardships on the project.

Secondly, I highly recommend improving your own communication skills. This topic is beyond the scope of a single blog post, but aside from the obvious recommendations, which one would immediately find after a few minutes of googling such as reading, using a thesaurus, and brushing up on grammar, I would attribute a large amount of failure to a not-so-obvious source: coloring and obstructing information through the prism of one's ego. While it might feel dropping an endorsement of a self-help book in a communication blog, reading The Power of Now has been very instrumental for me to pick up on these errors and how they happen.
In addition, I think that staying up-to-date on the latest industry trends through constantly reading articles like these are a great way to hone this skill, but taking on a writing hobby does wonders as well. I personally think that engineers should hone their writing skills just as much as one's coding skills.

What your Team can do

• Research

There are plenty of resources on the internet that can help your team communicate better. It would not be a waste of time to implement some of the suggestions offered by more authoritative foundations, such as Atlassian.

• Define Ubiquitous Language

I'll let Martin Fowler layout the case for it. Practically speaking, if your project doesn't have some sort of pattern for documenting the specific words that you use throughout the project, an easy win is to write it up and share it with the team.

• Introspection and action

recognize the dynamics of your projects 'office', being especially cognizant of any hybrid or remote colleagues on the team.

• Improve your code review process

This topic is getting a lot more attention lately, and deservedly so. This particular article by Erik Dietrich really distills the vitriol of the practice into words

• Improve your meetings

A lot of communication anti-patterns are on full display at a typical project meeting. Fixing these meetings are a good starting point. Elon Musk has a lot of thoughts on the topic as well that resonate with my experience.

Conclusion

Software engineering is a discipline of communication, and software is built as a team. Great communication skills will serve you greatly as an engineer, and is paramount to becoming a leader in the field. You owe it to you and your team to make sure that the ideas that we share and receive are done correctly.