Why [I] Create[d] a Technical Blog

Why I decided to blog

I’ve had a website for almost two years, but I always envisioned this site being more than simply a persistent resume. I dabbled in this more twice before, but I allowed myself to get in my own way. I convinced myself that my website design was not polished enough, my framework was not secure enough, my writing was not professional enough, and, most paralyzingly, my contributions were not big enough to be released in a public platform. Unfortunately, this inaction had a cost. I have repeated tasks I failed to document, forgot ideas I was afraid to share, and contributed little back to this amazing community from which I have learned (consumed) so much. Ultimately, this journal is for me. It will force me to better understanding these topics by creating the appropriate documentation, help me become more comfortable with casual public writing (and not worry if it is perfect), and provide me with record of all my technical endeavors. I hope some of this work is also useful to the community, but I am positive I will be the biggest beneficiary of all simply by going through this process.

I wrote a technical blog journal to:

In my attempt to convince myself to start, I spent some time researching the purpose of technical blogs and ran across a wide variety posts (like from rackspace and technicalblogging) that articulated several of my own reasons for developing a blog. In execution, I believe this site is more accurately a technical journal than a blog because its purpose is primarily self-improvement and not gaining an audience or monetary compensation.¹ I wanted to highlight the primary reasons I created this site and why I think every technical person should create one too.

Better understand the technical topics

I will force myself to understand the problem more fully simply by trying to write (explain) my solutions. I was previously a coach of the USMA Cyber team, and we continually encouraged our students to do write-ups of solved CTF problems (examples here) and even dedicated the Monday practice after a competition solely to this purpose. Our students rarely wrote to the level publicly publishing (the next point partially explains why), but they had to do enough to give the rest of the team a short presentation on their assigned problem. The presentation helped level-set the team regarding the problem, but the students generally only benefited from the presentation if they had some initial context (i.e. tried the problem during the competition). The writers were really the ones that benefited because, to explain the answer to someone else, they had to fully understand the underlying principles of your solution.² Doing write-ups, tutorials, or explaining my work to through this site will force me to better understand the material.

Become more comfortable with public writing

I will become more comfortable with and accepting of imperfection. This issue was one of the hardest for me to conquer. I am naturally an introvert and shy away from using any social media so how am I going to write a blog where I need to publish my thoughts consistently and publicly? I am familiar with writing for my students or official publications, but these are either to a limited audience where I am established as the technical expert or after days (not hours) of review by multiple people. I cannot invest that much time into this journal, and the internet is full of people with way more expertise than me. The Rackspace article does a good job of addressing these fears (like I’m not an expert, What if I say something that isn’t correct?, and even I am a terrible writer) so I will not rehash his rebuttals. Instead, just think about how many times you have found the answer to some ridiculously specific problem on Stack Overflow or even Quora. Someone had to have the guts to ask that question, and you didn’t care about the expertise of the person making the solution - just simply that it worked. Everyone has something to contribute. Ultimately, I remind myself the purpose of this endeavor is self-improvement, and I have accepted that my posts will not be perfect. I just hope someone points out all the mistakes I will inevitably make - that will only help me get better.

Have a record of your work

I will benefit long-term from documenting my endeavors. How many times have you had to resolve the same issue? Setting up my shell the way I want, getting VMware tools to work on properly on fill-in-the-blank Linux distribution, and running 32-bit binaries in a 64-bit environment are just a couple examples of things I have resolved numerous times because I did not properly document the solution, and I forgot the answer when I needed to do it again two months later. This blog will also be an amazing resource to look back on to see how far I have grown over the years.

Give back to the community

Someone, somewhere, will eventually benefit from my work. Finally, documenting my solutions is a chance to give something back to the community. I always tried to instill this ideal of contributing to the greater good with my students by discussing things like working on open-source projects and reporting bugs, but I was not “walking-the-walk”. I have not contributed to any open source project and have very few public repos primarily because of the fears addressed above. This blog is a baby step towards giving back more to the community. It will not change the world, but it might someday help another nerd struggling to set up a Hugo site on Gitlab solve his or her problem.