Why Writing is Important?

Hey, hope you are doing well! In this post, I am going to write a bit on why I think writing is important, especially in the work environment. Here are some examples where you might want to practice your writing.

Writing for meetings

Let’s say, we have something to discuss and then off we go, we do the discussion and wrap it up. However, we don’t write the summary of the discussion. It creates a risk that in the future, we might forget about what we discussed. By having some kind of Minutes-of-Meeting (MoM) document, not only could revisit what we discussed, but other people (who were not in the meeting) could also refer to that document if they have related works.

You might argue that we could rewatch the meeting recording, but even then, it might be hard to pinpoint in which minute we talk about something that piques the interest of the watcher. Let’s say that we discussed A, B, and C. How does the watcher know when exactly we started discussing C? None. They will most likely need to skim the meeting recording bit by bit until they find the parts that they need.

The above hassles could have been eliminated if we had written the MoM document. In Google Docs, for example, we could utilize headings to indicate the “topic” that we are talking about in the meeting, in case the meeting was lengthy and there were a lot of points being made, so it might be best to separate by sections instead of just bullet lists.

Other than that, we can also utilize writing to prepare for meetings. If we already have notes written on what we might want to discuss (better yet, we share it with the meeting members), we could make the meetings more efficient, provided that every meeting member does their homework.

Writing for increasing reach

The second case is, for example, you want to discuss something with your colleague. To the meeting room you go and it wraps up nicely. Then, turns out in the future, you have to do it again with other stakeholders with the exactly same topic. What are the risks?

1. Inconsistency: what you said to A might not be the same to B because they are done at different times. This poses a risk because, at a later time, A might say different things than B because they heard different things from you.
2. Time inefficient: imagine if each meeting with A and B costs you 30 minutes. That means the whole set of meetings costs your company 120 minutes (3022) of people’s time. And even then, there is this inconsistency risk in the above point as well.

Regarding time inefficiency, it’s not like it’s strictly forbidden to have meetings. I think it’s acceptable, as long as the meeting itself is productive.

Instead of having to do a meeting with each stakeholder one by one in different instances, why not just create a document that outlines your idea, then have them review the document and let them know if they need clarification? That way, we achieve 2 things, the first being reaching multiple people asynchronously at different times and the second one is your idea is documented so that if you are unavailable in the future, there is still a “source of truth” for the stakeholders when they want to revisit the topic.

Writing for improving structural thinking

In software engineering, usually, the flow is: “input, process, output”. Sometimes we know the input and what is the output, but we haven’t discovered the process (yet). If we talk in that state, it’s very possible to “blabber” without direction, which I experienced during my job hunt 2 years ago.

Turns out it helps if we start documenting our thought process first. It can be as a small note, it can be in a proper document, whatever. How we will be able to achieve the output given an input? What are the steps? What are the risks in each step?

In software engineering, we often think that the “process” is the responsibility of software engineers. It’s not. I think a good example is cooking. Given ingredients and tools, convert them into food. As a disclaimer, I’m not a cook (and I’m not good at cooking either). Let’s say you want me to cook Soto Betawi, something that I have never cooked before. You give me the ingredients (input) and the photo of the result (output). I will try to guess the process, despite my inexperience. This guess is a very high-level one, something around below. Note that this is my guess, I did not cheat to look at the cookbook at the time of writing.

1. Prepare the spices for the broth
2. Boil up spices in the water along with other broth ingredients (e.g. chicken bones, maybe)
3. Filter out the bones from the broth
4. Somehow slow-cook the beef
5. Combine (3) and (4)
6. Add some veggies, such as small tomato chunks and chives

That’s very general steps, right? I believe the cooking process would be more complex than that, maybe it can take more than 1 hour if I am the one who does it.

Even then, the process that I wrote above might not be correct. That’s the neat part, we can learn from it. The more we learn about the “birds-eye view” process, the easier we understand how it will be implemented later (even if it’s just the “behavior”). The most important part is, we will not be a sitting duck if someone asks us about it.

Closing words

Hopefully, this post is useful. I encourage you to practice writing (if you haven’t). Remote work is becoming more common these days and it’s very unfortunate if we don’t practice our writing skills. It is a very good skill to have in our skillset regardless of role, not only to make our job easier but also to increase our added value.