# Writing Has Been My Best Teacher > **Source:** [https://lorbic.com/writing-has-been-my-best-teacher/](https://lorbic.com/writing-has-been-my-best-teacher/) > **Author:** [Vikash Patel](https://vikashpatel.net) > **Published:** September 17, 2026 > **Reading Time:** 6 min > > *This is the raw Markdown source of the article from the [Lorbic Technical Journal](https://lorbic.com/).* --- When I write code, it is remarkably easy to fool myself into thinking I understand something when I really do not. I can tweak a function until the compiler stops complaining, paste a workaround, and watch the test suite turn green. As long as the service boots cleanly and passes CI, I can tell myself that I know what is happening under the hood. Writing completely strips that safety net away. When I sit down with a blank text file and try to explain why an unbuffered channel locks up or how an index scan escalates locks under high traffic, there is nowhere to hide. I cannot patch over a missing link in my logic with a quick rerun. If a concept is foggy in my head, the sentence falls apart right on the screen. That is why writing has been the best teacher I have ever had. --- ## The University Scrapbook I started blogging back in university, and back then it had nothing to do with building an audience or getting noticed. It was essentially a personal scratchpad: - Quick Bash scripts to automate local setup. - Notes on C++ pointers and memory management. - Little fixes for tools that broke after a fresh OS install. Whenever I spent hours wrestling with a broken library link or an obscure terminal error, I wrote down what happened. My reasoning was simple: if I forgot how I resolved it, future-me would have to suffer through the exact same problem all over again. Those early posts were mostly recipes. They answered *what* commands to run, not how the system was actually behaving underneath. But the habit planted something lasting: the realization that translating what I was doing into sentences forced me to pay attention to my work. Then life picked up speed, and the habit slipped away. --- ## The Three-Year Silence After university, full-time engineering took over. My days filled up with sprint deadlines, production incidents, pull request reviews, and infrastructure migrations. When you spend eight to ten hours a day reading code and debugging logs, opening another text editor in the evening is usually the last thing you want to do. So I stopped. For nearly three years, I barely wrote a word. During that hiatus, I consumed a massive amount of technical material: RFCs, architecture posts, internal documentation, release notes, and books. I shipped systems, tuned database queries, and kept services running. Yet something subtle was happening to my thinking. Without the discipline of writing, consumption became passive. It is easy to skim an architecture breakdown or a runtime source file and nod along. You recognize the terms, diagrams look sensible, and you feel like you get it. ```mermaid flowchart LR subgraph Passive ["Passive Reading"] A["Read Docs or Code"] --> B["Familiarity"] B --> C["Assumed Understanding"] C -.->|"Production Issue"| D["Gaps Revealed"] end ``` Familiarity is not real understanding. Recognizing a concept when someone else explains it is completely different from being able to explain how the pieces fit together on your own. Without realizing it, I was confusing the comfort of reading about systems with actually knowing how they run. --- ## The Blank Page as a Check on My Thinking When I finally returned to writing, I didn't want to publish generic setup tutorials anymore. The web already has thousands of guides on how to install Docker or declare a struct. I wanted to explore the questions I ran into during real work: - How memory buffers wrap around in ring queues. - Why the Go scheduler parks a goroutine on a wait list instead of spinning. - What happens when struct fields are misaligned in memory. The moment I try to write down how something works, the blank page acts as a strict reality check. ```mermaid flowchart TD W["Write Down How the System Works"] --> C{"Is the explanation clear?"} C -- No --> F["Reveals Fuzzy Logic or Missing Steps"] F --> R["Inspect Source Code or Run Benchmarks"] R --> W C -- Yes --> S["Solid Understanding"] ``` Almost every post I write now goes something like this. I start by writing out how I think a component operates. Halfway through the third paragraph, the explanation stalls. Why does one goroutine copy directly into another's stack frame? Can it bypass the heap entirely? I realize I do not actually know. That friction forces me to open the runtime source code, read the comments in `chan.go`, or run a small benchmark. I am no longer casually skimming; I am looking for a specific answer to a question I could not explain to myself. Once the code confirms what is happening, I rewrite the explanation in direct, plain words. Writing does not just document what I already know. The process of writing is where the learning actually happens. --- ## From "How-To" to Engineering Stories Coming back to writing after that long break changed what I wanted to capture. In university, my notes were all about steps: - *Step 1: Install this package.* - *Step 2: Copy this configuration.* - *Step 3: Run this script.* Today, the things worth writing down are the trade-offs, constraints, and failures: - What does this design cost in memory and CPU cycles? - Where does this pattern break down when traffic spikes? - Why did the designers choose this limitation instead of the alternative? Day-to-day engineering is rarely about syntax. Syntax is easy to look up. What matters is knowing where the edge cases hide, what failure modes are waiting under heavy load, and how systems behave when pushed past their defaults. Writing forces me to face those trade-offs directly. I cannot claim an approach is good without being clear about what was given up to make it work. --- ## Why I Keep Writing I don't write to build an audience, chase algorithms, or gain fame. This blog is simply my own personal diary, just published on the web. It is a place where I work through problems, preserve what I have learned, and untangle things that felt complicated when I first encountered them. Writing keeps me honest. It prevents me from coasting on vague intuitions and surface familiarity. Every time I write through a problem, I walk away with a clearer, more durable picture of the system than I had when I opened the file. If someone else happens to stumble across these notes and finds something helpful, that is a great bonus. But the real work happens in the quiet hours when an awkward sentence stops me in my tracks and forces me to open the source code to see what is really going on.