How I'm trying to become a better communicator
Tags: communication, development, developer, leadership
Published: 2019-08-29 19:37:37

---
title: How I'm trying to become a better communicator
published: true
tags: communication, development, developer, leadership
canonical_url: https://roelofjanelsinga.com/articles/how-becoming-better-communicator
---

!["Teamwork"](https://thepracticaldev.s3.amazonaws.com/i/wgz30gnrg8rm02f64xou.jpg)
<a class="link" style="border-bottom-width:0;" href="https://www.freepik.com/free-photos-vectors/business">Illustration created by stockgiu</a>

# How I'm trying to become a better communicator
I'm trying to become a more skilled communicator to my peers and non-technical people. Being a good communicator is vital to work well in a team. By writing more often I'm hoping to improve my abilities to transform thoughts into comprehensive sentences. By writing for different audiences, I'm attempting to figure out what kind of word choices help to communicate my thoughts in more effective ways.

There are several ways I'm attempting to communicate my ideas, technical solutions, and progress. These are as follows:

- Writing blog posts
- Publishing README files as blog posts (these will follow in the next few weeks)
- Writing a lot of documentation for code I've written
- Writing, writing, writing

## Writing blog posts
As you might have noticed, I've published a few blog posts in the past few weeks. These are mostly used to help me track my progress over time. However, like code, ideas and solutions become vague over time. By learning to improve my writing I hope to communicate my ideas more clearly, so I can keep understanding what I was talking about when I originally wrote the text.

When looking back at my very first posts on this blog, I can already see very clear improvements. My posts have gotten a better outline, containing actual introductions and conclusions. Reading through the posts has become easier. Even though English isn't my first language, you can tell that my grammar and general language skills have improved. This just goes to show how important it is to revise your work after you've written down your thoughts. In a year or two, I will look at this post and think: "I was so naive, look at how much I've improved since then". And those kinds of thoughts are exactly why I write blog posts because measuring progress can be a real motivator.

## Publishing README files as blog posts
Laravel, a great PHP framework, became popular because it had great documentation. When you're able to communicate what you can do with a piece of software, people are more likely to pick it up. When you have a great piece of software, but you're the only one that knows how it works, you'll most likely be the only one that will be using it. 

This is why I'm making it a point to document a lot and do it well. Of course, I can always improve, which is why I'm going to publish my documentation here as blog posts. This will help me to keep revising and improving upon myself. I revise my blog posts quite a lot throughout a couple of days and I should follow the same process for documentation of my README files.

## Writing a lot of documentation for code I've written
Any time I write software, I try to document how it works and why the code exists. The reasoning is usually the deciding factor for keeping or replacing pieces of software, so making my intentions clear help when refactoring inevitably becomes necessary. Let's backtrack a little bit...making my intentions clear when writing software has a side effect. This side effect is that other people read your reasoning and might think "Hold on a minute, this can be done much more easily". In this case, my documentation has done its job, because it has made the software better.

Being able to discuss your ideas with peers, in any way you can, be it face-to-face, written or a phone call, helps you iron out your ideas and solutions. So when you get better at communicating, your peers will be able to help you quicker and more effectively. Part of this process is formulating what you're trying to accomplish. If you've been practicing by putting your thoughts into words, this will be much easier than when you've been inside your head the whole time. Sometimes by writing down your thoughts, you've already solved the problem you've had in the first place. So making a habit out of putting thoughts into words, formulating precise questions, and asking your peers for help, will ultimately make you a better developer and colleague.

## Writing, writing, writing
"Practice makes perfect" is what *they* say. I have to agree with this. Sure, you can have a lot of talent and be a very good writer, whether it is technical writing or creative writing. When you never write, you won't become a better writer. The same goes for programming, if you only follow tutorials but never actually write a piece of software, you're never going to get better at it. The only way to improve your skills is to put them into practice and repeat, repeat, repeat. With that said, if you want to become a better (written) communicator, you have to...well... communicate. You have to make the mistakes and learn from them. I've made plenty of mistakes trying to improve my communication skills and I've done my best to learn from them and improve myself. 

Do you have any tips for me? How can I improve my writing? Let me know on [Twitter](https://twitter.com/RJElsinga), I'd love to hear from you!