My First Writing: What I want this Blog to Become

01/11/2026

In this writing piece, I discuss my reasoning and goals for this blog, including not limiting it to only computer science topics, but rather a vast array of topics I find interesting enough to write about.

Why a Blog?

Back in high school, English and writing were always my least favorite subjects. I enjoyed solving problems where there was a concrete answer, and a submission attempt was always binary: either right or wrong. Therefore, it should not be surprising that I did best in math and computer science courses. English, on the other hand, was anything but objective to me. It seemed that there were no right answers, but there were definitely wrong answers to every question. There was no derived formula I could use to write perfect prose, and that always bugged me, especially when I failed to earn a satisfactory grade on an exam or essay covering a classic novel.

When I entered my first semester of college, my opinions on these subjects remained static. Every additional English or writing course I enrolled in seemed like a waste of my time, another responsibility I dreaded having to commit my time to.

However, my whole mindset changed in the second semester when I enrolled in a technical writing course. At first, it seemed like another generic writing class, aiming to help improve my “written communication skills”, whatever that really meant, I thought. But, when the first major assignment in the course was to research twenty companies that I could see myself working for one day, I became excited because this work would be both directly applicable and interesting. I remember spending extra time one night to dive deep into my dream company, Grammaly (which I am using to help edit this blog; shocker!), learning about the types of engineering roles they hire, qualifications, and even company culture. I became so invested in the assignment that at times, I forgot it was an assignment.

Another assignment for the course was to write a step-by-step guide for a process that interested me. Being passionate about web development and finding it an appropriate topic to explain to a beginner, I wrote a paper about creating a simple HTML portfolio page with basic CSS and JavaScript integrations. Again, it did not feel like I was working on just a “paper.” Instead, I was writing about something that was intriguing.

At the conclusion of the semester, for the first time, I was sad that a writing course was over. Around the same time, however, I was entering into my first software engineering internship at a local medtech company called Medical Informatics Engineering (MIE). The CEO, Doug Horner, who was also my direct ‘tech’ supervisor, stressed to all of us interns the importance of documentation. He argued that writing code using unfamiliar libraries and frameworks was worthless unless you understood what you were learning and writing along the way (this was before the widespread use of agentic coding agents integrated directly into IDEs was rampant, which may serve as a future writing topic). Each intern created a charter document, which served as their activity log with screenshots, code snippets, and bullet points about what they learned and did each day.

It was tedious, sure. But, by the end of the internship, both in 2024 and 2025, it was very rewarding to look back at all my notes, screenshots, and videos to see all that I learned and accomplished in a few months (for reference: 2024 charter doc, 2025 charter doc). I thought that this was a unique requirement for an internship, especially for students my age, and that real documentation and ideas are written only by senior-level developers and above, since they are the ones who architect systems and make important design decisions.

However, I realised how naive I was when looking at fellow students' portfolio sites (such as the collection at UWaterloo). I would estimate 80-90% of them have a blog, where topics range from opinions about the state of coding interviews to writing about a neat type feature native to Rust, to everything in between. Even when looking at the footer of almost any technology or Fortune 100 company, there is a tech blog where developers at all levels write about interesting technical problems they faced and what they learned from them. I read one from Grammarly yesterday (It’s true, it really is my dream company!) about a 2025 Kubernetes cluster ‘nightmare’ where a high rate of protocol denial errors caused outages over a few-month period, until the engineers found the real culprit was coreDNS not being cached and horizontally scaled across nodes properly.

It was topics like these that really piqued my desire to start my own blog. For the first time, I learned that subjectivity is not inherently a bad thing, even in technical fields like computer science and software engineering. There is no correct ‘system design’ that is fault-tolerant, no correct algorithm for every DSA problem, no correct language for a project, no correct UI for a SaaS site, no correct Kubernetes cluster, etc. Each of these topics is subjective, where opinions from thousands of engineers are taken into account over years to come up wth ‘best practices.’ Still, best practices do not account for every use case. If they did, why would we still need engineers? Why would there be a need to document unique problems and solutions if there was only ‘one’ correct way to do everything?

There is always something new to study, a mistake to learn from, and a problem to solve. This is what makes great software engineers great and is what I aspire to be.

What Will I Write about?

Enough of me explaining the backstory: let me discuss what I actually want to write about. I constantly strive to learn new topics, both related and unrelated to DevSecOps, CI/CD, clustering, cloud infrastructure, and distributed systems. Some topics may be about lower-level topics, such as memory-mapped I/O (MMIO) vs port-based I/O (isolated I/O), PCIe, or BIOS/UEFI. Others may be about my preferences for full-stack frameworks, libraries, IDE plugins, etc.

Most importantly, some topics may have nothing to do with the realm of computer science. They may be about art and art history, from the likes of Da Vinci to Banksy, to investing, politics, or any other topics that I find interesting. My goal is to be well-rounded.

When Will I Write?

I will not force myself to a strict schedule for writing about new topics. I prefer quality over quantity: where I would rather not blog for a month or two if that means I can focus in-depth on a certain topic rather than being extremely surface-level and not leaving much impact for myself, or, arguably more importantly, for readers. When I want to write about a topic, I want to go all in, which might mean inconsistent schedules. That is fine with me. The beauty of a blog on your own site is that you get to make the rules, haha!

That is all for my first post. See you in the next one! :)