I have heard more than once that the best way to learn something is to teach it to someone else.
I have found this to be true from my own experience as well.
When I was studying at MIT, I participated in multiple programs where I taught high school students simplified versions of the material I was learning in class. I found the act of creating a curriculum extremely helpful in reinforcing the material I had to study myself.
Writing has a similar effect as teaching.
This is because writing is essentially teaching. You’re imparting your knowledge to others.
I’m a perfectionist when it comes to teaching and thus writing. I hate bullshitting because the worst thing a teacher can do is teach something that’s false. If I say something, I need to know that it is unambiguously true.
However, in software development, I’ve come to learn that there’s rarely a single “truth.”
As a result, for every concept I present, every argument I make, I do a ton of research and I read multiple articles to study each side of the coin.
When is what I’m saying applicable? When is it not? Are there better ways of doing things out there?
One article I wrote last year was about setting up short-polling for api requests. We used short-polling because it’s a bad idea to make server blocking api calls when you know the request will take a few seconds to process. However, what I didn’t know prior to writing the article was differences amongst short-polling, long-polling, and websockets. All three of these methods can be used to handle computationally intensive api requests. What I also didn’t know was when to use which and why we decided on short-polling.
Writing forces me to research in breadth and in depth. Through writing, I started noticing details and I asked myself questions that are easy to overlook when developing on the job. As a result, writing had a tremendous impact on my development as a software engineer.
Writing is also a form of documentation.
I read something funny related to comments left in a codebase:
// When I wrote this, only God and I understood what I was doing
// Now, only God knows
(one of the answers from here)
It’s funny because it’s so relatable.
Every time I go back to files I have worked on after a long break, I have to actively try to remember what the code is doing and why I wrote it.
People forget. It’s impossible to remember every technical decision you have made and why you made it.
Writing documents my thoughts and my learning so I can recall information later.
When I reread my essays later, two thoughts often occur at various degrees:
Regardless of my now impression on the quality of my earlier work, one thing certain is that looking back at it, I never fail to realize how far I’ve come.
With a good documentation of my progress and a greater repertoire of knowledge related to my work under my belt, I became more and more confident in my ability to code.
And this brings me to my third point:
Ever heard of the phrase “growth mindset” versus “fixed mindset”?
If not, I wrote about it here:
As I became more confident, I found myself leaving the fixed mindset I grew up with and adopting a growth mindset.
We should all aim to approach life with a growth mindset. This is especially true in tech, an ever-changing industry where new tools pop up frequently.
Over time, having a growth mindset enabled me to take more risks because I’m less afraid of failing. The more risks I take, the more I try things, the more opportunities for success I create for myself.
So why not start writing? We all have something we can share with the world!
Create your free account to unlock your custom reading experience.