Some really good advice in the article, and I like the examples too. I agree with the author that communicating effectively is an important skill in a developer's tool box, but the article only covers written communication. In reality, effective communication involves speaking and listening skills as well. These skills are important enough for developers that I wrote a whole chapter on communicating effectively in my book[0].
Here are a few more points I think are helpful:
* Communicating isn't just saying something. People might not understand your ideas, or they may interpret what you're trying to say in a different way. Sometimes you need to repeat yourself in order to drive your point across, and you may need to communicate your idea in multiple ways for people to really understand what you're trying to say.
* If possible, try not to communicate through other people. Don't ask Tim to ask Alanna to do a favor or a task that you need to get done. It may feel like good delegation, but the more hops your message takes before it reaches its destination, the more chances for the message to get distorted, like a game of telephone. Try to communicate your message directly to the intended person if you can. Sometimes this isn't possible and you need to communicate through other people though.
* Understand the audience you're communicating with. Are they technical? Then it's okay to use technical jargon and concepts. Are they not technical? Try to use more common terms and phrases. You may need to come up with examples and similes so it's easier for them to understand something that's technical or abstract.
* Clear writing is critical in code reviews. If you think a line or block of code needs to be changed, explain why in the code review, don't just say it's wrong and it needs to be changed—that's not helpful. Especially with younger engineers that could benefit from understanding why their code could be improved.
* If conversations turn in to long discussions on a code review, move the discussion to a video call or in person conversation. No one wants to follow a thread where two developers are arguing about whether something is right or wrong. Settle the disagreement outside of the code review.
* You'll be writing a lot of technical requirements in your project management system as you get more experienced and lead more projects and features. What you write in the ticket won't always get interpreted exactly how you think it will, so try to write as clear and thoroughly as possible when describing what needs to be done. Sometimes you may need to describe how it needs to be done as well if you'd like it done a specific way.
[0]: https://www.holloway.com/g/junior-to-senior/sections/how-to-...