This is something I’ve thought about for a while now, I’ve just never got around to doing it, however now that I have time, I think it’s important to share my thoughts.
Throughout the past year of studying IT, a topic that comes up over and over again is documentation. We claim that we value high-quality documentation. However, how far are we willing to take this mentality?
Those in the field know the feeling – After working on a long ticket, suddenly something causes a click, whether it be an article, video, or verbal communication from a senior technician, the problem now has a solution. You’re then left wondering how much quicker you could have completed the task if someone had documented something.
Hence why we create extensive ticket notes and KB (Knowledge Base) articles in our documentation system of choice so we may refer back to those documents to save time and headache in the future. This record of exactly what happened is incredibly useful, but it’s not the only useful thing you get from quality documentation.
Do you truly understand?
If you can’t explain it simply, you don’t understand it well enough.
Albert Einstein
Now, think about what the technician goes through as they write out their notes, KB articles, and resumes. They have to process everything they have experienced, from minutes to years after the fact, and they have to understand it well enough to write about it. They may also have to train others, which can also be aided with a high quality document.
The understanding that comes from producing high quality documents is more valuable than people realize, and I believe the process of documentation fleshes out your own understanding as well.
Documentation as an act of learning; Why you should start a blog
Too many people go through the trouble of studying certifications, learning on the job, completing labs, only to forget this information after a few months. Even worse, I’ve heard of people who finally get an interview, but falter when it comes to describing the very thing they studied so hard to be in the position they are in.
It’s easy to enter an interview and point at some certification or project or degree, but to be able to describe it, and with clarity, is key.
That’s why I propose that if you are interested in IT, you start your journey by learning how to create a website and document your learning journey to the best of your ability through regular blog posts. These posts can serve as evidence that you have gone through the process of learning something to the point where you can share it well enough to be considered competent on that topic.
Why I created this blog
I wanted to prevent myself from falling behind, not on any one topic, but on the stuff I already know, or aught to know. By writing a blog, it not only benefits me in that I’m presented with a clear understanding of where I’ve been and what I’ve done, but it also opens the opportunity to help others grow in their knowledge and motivation.
I intend on keeping this blog professional and helpful to all readers who visit. I want any projects I add to this site to be documented to the best of my ability, like I could follow it with no other help and complete the task from scratch. Even better, to not require extra help with the guides I create, but to link many supplemental resources I used to create the documents.
If you are interested in copying this approach, feel free to! I feel that everyone has something to bring to the table, and you can benefit yourself at the same time through this process. For those who are curious, I have documented everything I did to get started with this blog here: Create a Website using Hugo and PaperMod
A brief story
I remember years ago, trying to learn how to code felt more like trying to learn how to learn how to code. I had this vague goal of what I wanted to do, but no idea how to start. Following tutorials felt fruitless because knowing how to go off on my own was not something I was familiar with. My process was:
- Follow the tutorial by the book, taking a bottom up approach, learning all the fundamentals and building blocks of coding
- Become lost not knowing how to apply the things I’ve learned into meaningful projects and contributions
This is not a skill we are given right off the bat. We have to experiment enough to learn how to grow by ourselves, or we need someone who guides us, like a tutor, not a robot. It’s so easy to fall into the trap of just following directions, whether it be from a straightforward YouTube video or the latest AI model. However, knowing when to step back and ask meaningful questions, then iterate on those questions, experimenting with them, is the difference between being stuck in so called tutorial hell and escaping to a self-directed freedom where you understand what you did and why it works.
This is why in communities like OSSU/The Borr Project, the topic of AI is so shunned. While hallucinations are a big part of the problem with AI, the main error many people face is copying what it does without understanding the why behind each step.
The solution here can be seen as a mentality: From now on, strive to not just follow tutorials, but to understand the underlying process behind each step and the reasoning that goes into each step. When you do this, you will be able to effectively explain to others technical topics which can build their skills or serve to prove your own skills.
As for this blog: While I intend on documenting many things throughout the coming years in this blog, I do not desire readers to just “follow directions”. I want them to feel like I pointed them in the right direction to kickstart their own learning and understanding on the subject.
I hope this has been a meaningful article to read. If you have any comments, I value constructive criticism and invite you to submit an issue on this website’s GitHub repository.