Why I Write Tutorials (And Why You Might Want To, Too)

When I write tutorials, I’m not just teaching syntax or showing a clever trick. For me, tutorials are part of a bigger journey: clarifying my own thinking, building a body of work that others can learn from, and practicing how to see the world as systems of data, processes, and opportunities.

Learning Is Slow, Solitary, and Continuous

One of the main things I’ve noticed over the years is that learning takes time and patience. It doesn’t happen overnight, and it doesn’t come from a single source. The best knowledge is often pieced together over time, gathered from experience "in the field". Traditional learning avenues such as classrooms or training seminars are suitable when you can dedicate a fixed amount of time. However, in my career and life, I've had to learn things as they were needed.

In the workplace, real teaching is rare. Unless you’re an intern or a junior developer, most people assume you already know what they’re talking about. At mid to senior levels, the culture is different: there’s a sense of competition, and while ceremonies like code reviews or sprint retrospectives can offer small glimpses of learning, they’re rarely deep dives.

This is not to say that some elite organizations such as Google or Apple, do not offer and even encourage continous learning, but let's face it, most of us are not working there, and most businesses focus on their primary need to grow, rather than their emploees need to grow as professionals.

That means learning often becomes a solo pursuit. You have to make the time, find the patience, and keep adapting.

Writing as Learning

Writing forces me to do what most jobs and institutions don’t: slow down, research, organize, and codify knowledge.

When I write a tutorial, I’m not just showing others how to build something. I’m forcing myself to confront the gaps in my understanding. Do I really know why this design pattern works? Do I understand this Python pattern deeply enough to explain it? Could I justify this architectural decision to a technical team and a business audience?

Writing is a form of testing. It’s like compiling your own knowledge. If it doesn’t "compile" clearly on the page, then it’s not yet solid in your head.

Code Reviews, Design Docs, and Company Knowledge

Some of the best learning I’ve experienced didn’t happen in courses or books — it happened during code reviews.

I remember how senior developers, or sometimes peers, would explain why they solved a problem in a particular way. Those were lightbulb moments for me. At other times I'd suggest implementing the solution in a different way. Those were light bulb moments for them. It wasn’t about syntax. It was about tradeoffs, reasoning, standards and patterns, and most of all, transferring knowledge.

Similarly, I’ve written countless design documents and tutorials inside organizations I’ve worked for. They became part of the company knowledge base — architectural blueprints and requirment documents — valuable resources for the team, but not something I could publicly attribute to myself.

Those experiences were educational, because they forced me to be clear and precise, but they also reminded me that I wanted to build a personal body of work. Something I could carry with me, refine, and share openly with the wider world.

Tutorials as Public Lab Notes

That’s why I think of my tutorials now as lab notes made public.

They’re not monuments or definitive textbooks. They’re living records of what I know at a particular moment. Tomorrow, I’ll know more, and I can refine.

By making my "lab notes" public, I keep myself honest. I also leave behind something others can use — even if it’s just one small example that clicks.

Beyond Code: Seeing the World as Data and Opportunities

But my goal isn’t just to write about code. What I’m really practicing is a mindset: how to see problems as systems, data, and opportunities.

Writing about React testing isn’t just about hooks and async calls — it’s about building reliable systems. Writing about linear algebra in Python isn’t just about matrices — it’s about how hidden patterns shape business and scientific decisions. Writing about Kubernetes isn’t just about YAML — it’s about scalability, resilience, and tradeoffs.

Each tutorial is practice in viewing the world this way: identifying inefficiencies, thinking about what can be automated, and framing technical problems as opportunities. That’s a skill worth practicing, whether you’re a developer, an architect, or a founder. Because technology stacks may change over time, but broader pattern of computing, and problem solving remain the same.

Tutorials as Journey and Legacy

For me, writing tutorials is part of my own learning journey — one I hope others will follow along with.

The structure of my tutorials is deliberately hands-on. They’re not meant to be thousands of pages of theory. They’re step-by-step, project-driven, and designed so that I and others, can build something meaningful gradually. Along the way, I hope readers find insights that help them solve their own problems.

And there’s a legacy element, too. I wouldn’t be here without the countless blog posts, Stack Overflow answers, tutorials, and open-source repos left behind by people I’ll never meet. Writing tutorials is one way to pay that forward.

If someone, years from now, learns how to debug a Python exception, design a system, or deploy an app because of something I wrote, then my time was well spent.

So, Why Should Anybody Write Tutorials?

Because tutorials aren’t just for teaching others — they’re for teaching yourself.

They force you to clarify your thinking, to organize your knowledge, and to practice seeing the world as data and systems. They give you a way to contribute back to the community, and they leave a trail for others to follow.

You don’t need to write a perfect or comprehensive textbook. You just need to write honest lab notes from your own path.

In the end, tutorials aren’t just about documentation. They’re about transformation — your own, and maybe someone else’s too.