95% of your Project Hardships are Caused by this One Thing, a Failure to Communicate.
Tags: sdlc, career
Published: 2022-11-06 00:03:25

"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
| Miscommunication               | Example                                                                                                                                                               |
|--------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Ambiguity                      | A colleague raises a discussion about a bug, but assumes that everyone knows which bug they are talking about, when in fact there are many bugs                       |
| Wrong Audience                 | A colleague authors a guide, but its voice drifts from deeply technical to more of a sales pitch, and entirely without a target audience in mind                      |
| Wrong Information            | the wrong date for a deadline is set                                                                                                                                  |
| Concealed Information             | A colleague with critical project or corporate knowledge and information fails to disclose or document the knowledge.                                                                                                                                  |
| wrong context                  | A discussion of pros and cons fail to take into account whether it is in regards to meeting an immediate need, or for long term planning                              |
| absence of communication       | A technical ticket is written with no description, a README or document doesn't exist.                                                                                |
| unresponsiveness               | A colleague 'ghosts' requests, creating a bottleneck for some result                                                                                                  |
| assumptions about the audience | A speaker assumes that the audience is highly technical, or knows obscure acronyms.                                                                                   |
| failure to listen              | Every effort is made to inform colleagues about a concern, but no action is taken.                                                                                    |
| failure to discuss             | Unforeseen challenges arise, instead of raising these new issues and alerting that deadlines may have to be pushed back, nothing is said, and the work silently fails |
                                                                                                                                                                                                                                                                                                                              
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](https://www.amazon.com/Power-Now-Guide-Spiritual-Enlightenment/dp/1577314808)_ 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](https://www.atlassian.com/blog/teamwork/effective-communication-in-the-workplace).

- Define Ubiquitous Language

I'll let [Martin Fowler](https://martinfowler.com/bliki/UbiquitousLanguage.html) 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](https://daedtech.com/how-to-use-a-code-review-to-execute-someones-soul/) 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](https://news.yahoo.com/walk-meeting-elon-musk-six-154936765.html) 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.