You might ask yourself how writing blog posts can help you become a better colleague? Well, writing can help you with several things. First of all, it makes you think more about the topic. Upfront. Before communicating. It also helps you articulate your thoughts more efficiently. It can help you realize which areas need improvement, without involving any other person. And so on.
There's one thing I want to emphasize. It's not about writing one blog post, it's about creating a habit to write about things you're doing. One blog post alone can't do a miracle. But if you stick to the plan and keep writing every now and then, you'll develop a sense of how to explain things to somebody else. It doesn't have to be public at all, it could be a Google Doc, although I would recommend publishing it.
Writing about things you are learning or dealing with as a developer can help you in many ways. To begin with, it can help you to structure your narrative. How to make sure that things you're talking about are easy to swallow. Even if you're talking about technical parts to non-technical people.
On the other hand, writing on a specific topic can help you address things that you still don't understand. If you can't explain it, chances are you didn't get it at first. And you just got yourself a topic for further exploration. Isn't it nice? To catch this early on and not in a meeting where you are supposed to know it.
As I said, writing blog posts can help you grow in many directions. Communicating your ideas is one of them. By writing a lot you'll learn how to delete a lot. And that's equally important to the writing part. Removing unnecessary words, phrases, verbs, while still keeping the same value in your sentences is a skill. And the good thing is you can practice it. You can get better.
This leads me slowly to the point. Communication is part of our everyday business, in so many shapes. You talk with your team, with a person in charge of the project, with your clients. You write emails and you write descriptions in the tickets. You write comments in the requirements, you write feedback forms and you write reviews on your colleague's pull requests. You are expressing your thoughts.
Can you think of a colleague who spends a lot of time trying to explain their problem? Those people usually unwrap the whole story and start with some unnecessary points that others find irrelevant. We all have limited time and attention span. If you don't deliver your point, you're risking that the other side won't understand you. Which is bad. That's why it's important to practice delivering the message as effectively as you can.
You don't want to be that colleague. We tend to skip listening to such people in meetings. It's exhausting to listen to everything they are saying and to connect the dots. Those dots may have a perfect sense in their heads, but not all of them are relevant to the topic we're talking about in the meeting.
It doesn't have to be only in verbal communication. Written forms also take time to read. Nobody has time for a wall of text in their email. Ticket descriptions with a bunch of text that doesn't bring value can also confuse the other side.
So, which colleague you'd like to be more? The one that starts explaining something since the dawn of time or the one that delivers the information in the shortest form possible? I believe it's a skill that can be trained. It's not something you're born with or without. Writing regularly can help you sharpen that tool. You don't have to write a diary. Start a tech blog. At least, we developers have plenty of topics to write on.