Introduction
I did not start writing to become a better writer. I started writing because I was asked to explain something to a junior developer on my team, and I realised halfway through the explanation that I could not fully explain it.
I knew how to do the thing. I had been doing it for years. But the moment I tried to translate it into language that someone else could follow — to decompose the intuition into steps, to name the decisions I had been making without naming them, to anticipate the questions a person without my context would reasonably ask — I discovered that my understanding was thinner in places than I had believed.
That was an uncomfortable discovery. And it was also one of the most useful ones I have made in my career.
This is about what writing and teaching have done to me over the years I have been doing it. Not what I set out to get from them — I didn’t set out to get anything in particular — but what they produced anyway, almost against my will. The humility. The patience. The clarity about what I actually know and what I have been performing. The small, quiet sense that the knowledge I accumulated over a decade of building things has somewhere to go besides dying with a project.
The First Time I Tried to Explain Something
There is a specific memory I keep returning to when I think about why I started taking explanation seriously.
A junior developer on one of my teams asked me to explain how Angular’s change detection worked. Specifically, why a particular component was not updating when they expected it to. I had debugged this kind of issue dozens of times. I knew the fix — use ChangeDetectionStrategy.OnPush, check the reference equality, make sure you’re not mutating directly. I had applied these fixes in production codebases across multiple projects.
But when I sat down to explain why the fix worked — why OnPush behaves differently, what Angular is actually checking, what the relationship is between reference equality and the change detection tree — I found myself saying things like “it just works that way” and “Angular needs to know the object changed.” Which is not an explanation. It is a description of the symptom in slightly different words.
The junior developer nodded politely. I could see they were not much clearer than before. And I went back to my desk and spent two hours actually understanding Angular’s change detection properly — not enough to apply it, which I could already do, but enough to explain it. Enough to know why, not just what.
That gap — between doing and explaining — is where I have spent a significant amount of my learning energy ever since.
The Gap Between Doing and Knowing
This is the thing that writing surfaces, consistently and without mercy.
When you do something repeatedly, you develop competence. You build an intuition for what works, what doesn’t, what the common failure modes are. That intuition is genuinely valuable — it makes you faster, it helps you debug, it gives you the pattern recognition to see familiar problems in unfamiliar disguises. I am not diminishing it.
But intuition is not the same as understanding. And the difference becomes visible the moment you try to write about something clearly.
Writing requires specificity. You cannot gesture vaguely at the answer the way you sometimes can in conversation. You cannot rely on the other person’s existing context to fill in the gaps. You have to say what you mean, precisely, in a sequence that someone who does not share your mental model can follow. And when you try to do that, the places where your own mental model is fuzzy — where you have been relying on pattern matching rather than genuine comprehension — become impossible to hide.
I have started explaining things in articles and stopped halfway through because I realised I did not actually understand the mechanism I was describing. I understood the output, not the process. I knew what happened, not why.
Those are the most valuable moments in my writing practice. Not the articles that went smoothly because I understood the material, but the ones that stalled in the middle because they forced me to discover that I didn’t.
Humility as a Side Effect
I did not set out to become more humble. If anything, the early years of my career involved a gradual accumulation of confidence — learning more, building more, developing the kind of authority that comes from having been in the room when things went wrong and knowing how to fix them.
That confidence is appropriate and healthy. But it has a shadow side that writing kept illuminating for me.
The shadow side is the tendency to conflate familiarity with mastery. I was familiar with a lot of things. I had touched them in real projects, applied them under real constraints, shipped them to real users. That familiarity felt like mastery from the inside. It produces the same sensation. You move quickly, you have opinions, you know what to do in the situations you have encountered before.
And then you sit down to write an article explaining the concept to someone who doesn’t know it, and you discover, somewhere around the third paragraph, that you have been familiar with the behaviour without understanding the model. That you could use the tool without being able to draw the map.
I have had this experience with JavaScript’s prototype chain. With RxJS’s scheduler model. With the specifics of how CSS grid and flexbox interact in edge cases. With the precise semantics of TypeScript’s structural typing versus nominal typing. I thought I knew these things. I had been using them. Writing about them told me otherwise.
The humility this produces is not the performance of humility — the social signal that says “I’m just a humble developer, still learning.” It is something quieter and more functional. It is the genuine recognition that the territory is larger than your map, and that the map is wrong in places you have not visited yet. That recognition changes how you approach new problems. You hold your first explanation less tightly. You ask more questions before committing to an answer. You leave more room for the possibility that you are, again, more familiar than you are expert.
That shift — in how loosely I hold my initial understanding — is one of the most practically useful changes that writing has made to me as a developer.
What Teaching Does to Patience
I am not a naturally patient person in technical contexts. I have opinions about how things should be done. I have strong preferences formed over years of experience. When I see code that violates a principle I hold with conviction — when someone mutates state directly, or writes a function that does four different things, or ignores an error instead of handling it — my instinct is to say so quickly and move on.
Teaching — genuinely teaching, not just telling — broke that instinct in a way that nothing else did.
When you teach someone something they do not yet understand, you cannot outrun them. You have to wait at the point of confusion, understand why the confusion exists, and find a path through it that makes sense from where they are standing — not from where you are standing. That requires you to remember, or reconstruct, what it was like not to know the thing. To rebuild the mental model from scratch rather than describing it from the top.
The junior developer who cannot understand why const doesn’t make an object immutable is not slow. They are applying a reasonable mental model — “constant means fixed” — and running into its limits. The fix is not to say “no, it works like this” and expect them to overwrite their model instantly. The fix is to understand why their model made sense, acknowledge that it makes sense, and then explain the specific way in which the language departs from it and why.
That process requires patience with the confusion, not impatience with the person. And practising it enough times changed something in how I experience the gap between where I am and where someone else is. I stopped experiencing it as a distance to be covered as quickly as possible and started experiencing it as a space to be navigated thoughtfully.
The patience I developed in teaching juniors quietly migrated into other parts of my engineering practice. I am more patient with ambiguous requirements now, because I have practice sitting in the space of not-yet-understanding without panicking. I am more patient with codebases I am encountering for the first time, because I have practised the discipline of building a mental model before forming an opinion. I am more patient in debugging, because I have learned that the first explanation is often not the right one and that the right one requires time.
Teaching gave me patience as a technology for learning, not just a virtue for management.
Empathy as a Technical Skill
This sounds like it belongs in a management book. It is actually one of the most practically useful things I have learned as an engineer.
When I write for an audience, I have to model that audience’s state of knowledge, their likely confusions, the assumptions they will make that I need to address. When I teach a junior developer, I have to understand not just what they don’t know, but what they think they know — because the wrong mental model is harder to correct than the absence of any model. When I do code review, I have to understand why the author made the choices they made before I can give feedback that they will actually hear and use.
All of these activities require a specific kind of empathy — not emotional empathy, necessarily, but cognitive empathy. The ability to simulate another person’s mental state and reason from it rather than from my own. That ability is a skill. It can be practised and it can improve.
Writing and teaching are the practice.
Every article I write that lands well — that gets responses from developers saying “I had this confusion and you addressed it exactly” — is evidence that my model of the reader’s state was accurate. Every explanation that produces a moment of genuine clarity in a junior developer is evidence that my model of their confusion was accurate. Every code review comment that the author acts on enthusiastically, rather than reluctantly, is evidence that my model of their intent was accurate.
And every time these things fail — every article that confused rather than clarified, every explanation that produced a polite nod rather than understanding, every code review comment that generated defensiveness rather than engagement — is information about where my model of someone else’s state was wrong.
Over time, the practice of writing and teaching has made me better at knowing where other people are. That skill is useful everywhere. In requirements discussions, in system design conversations, in 1:1s with junior developers, in code reviews, in technical interviews. The engineering work is almost always collaborative, and collaboration is almost always limited by the participants’ ability to model each other’s understanding accurately.
Empathy — the cognitive kind — is infrastructure for good engineering work. Writing and teaching are how I maintain it.
What It Revealed About What I Actually Know
One of the more confronting gifts of writing and teaching is the clarity it produces about the actual shape of my knowledge — not the shape I had assumed it had.
I had a mental map of my own competence that I had built informally over a decade of project work. “Strong in Angular, comfortable with React, decent at state management, good at component architecture, weak on backend, shaky on DevOps, solid on accessibility.” That map was real, but it was rough — the contours were approximate, the gaps were larger in some places than I had estimated, and some areas I had marked as “solid” turned out, on close examination, to have holes I had never needed to fall through because the projects I had worked on hadn’t taken me near them.
Writing articles that required me to explain specific mechanisms exposed those holes in a way that years of project work had not.
When I wrote about CSS logical properties, I discovered that my understanding of the writing mode specification was shallower than I thought. When I wrote about TypeScript’s structural typing, I discovered I had been using certain patterns correctly without being able to articulate why they were correct. When I wrote about WebSocket connection management, I discovered gaps in my understanding of the TCP handshake underneath that I had never needed to confront because the library I was using abstracted it.
None of these gaps were catastrophic. They had not prevented me from doing my job or from producing good work. But they were real, and I had not known they were there.
The map is always smaller than the territory. Writing and teaching showed me where my map ended — and in doing so, showed me where I could go next if I wanted to. Not as a list of deficiencies but as a genuine landscape of things that were still interesting, still worth understanding, still capable of producing the particular satisfaction that comes from finally getting something you had only been performing understanding of before.
What Is Real and What Is Illusion
This is the part I find hardest to write, because it requires the most honesty.
There is a version of technical confidence that is real. It is grounded in genuine understanding, tested by production failures, refined by years of feedback from codebases and colleagues and the relentless impartiality of bugs. When this kind of confidence says “I understand this”, it is usually right, and when it is wrong, it updates gracefully.
And there is a version of technical confidence that is performance. It is the confidence of familiarity mistaken for mastery, of having been in the room when things happened without having fully understood why they happened, of having strong opinions that were formed by pattern matching rather than comprehension. This kind of confidence is also common. I have had it. I probably still have it in some places I haven’t found yet.
Writing and teaching are the most reliable tools I have found for distinguishing between the two.
The real understanding survives the attempt to explain it. It becomes clearer in the explanation, more precise, more connected to adjacent ideas. The illusion collapses under the attempt to explain it. It becomes vague, circular, dependent on gestures toward the general direction of the answer rather than the answer itself. “It’s complicated” and “you just have to know it” and “I’ve always done it this way” are the tells. They are what I say when I am performing understanding rather than having it.
Over the years, I have learned to hear those phrases in my own explanations as a signal — not of failure, but of opportunity. The explanation stalled because there is something real to understand here that I have been routing around. Stop. Go back. Find out what it actually is.
That practice — of treating the stall as information rather than embarrassment — is one of the things I am most grateful that writing and teaching gave me.
Giving Something Back
I want to talk about this carefully, because it can tip quickly into self-congratulation, and I don’t want it to be that.
I have benefited enormously from other people’s writing. The blog post that explained a concept better than the documentation did. The article that described a debugging approach I had never considered. The Stack Overflow answer from a developer who had hit the exact same wall I was facing and had the generosity to write down what they discovered on the other side. The open source contributor who wrote clear commit messages that explained not just what changed but why. The senior developer who took the time to write a thoughtful code review comment rather than just marking the line.
All of this was given freely by people who received nothing directly in return for giving it. It made me better at my job. It saved me hours and sometimes days of work. It shaped the way I understand things that I now understand well.
I am under no illusion that my writing reaches many people or changes many careers. The scale is small. The contribution is modest. But the act of trying to write clearly about something I know is an act of reciprocity toward the ecosystem that taught me, in no small part, how to do what I do.
There is something important in that act that has nothing to do with its scale. The person who writes up a solution to an obscure bug at eleven o’clock on a Tuesday night, after finally fixing it, and posts it publicly — knowing it may help exactly one person who encounters the same bug in six months — is doing something that the industry quietly runs on. The aggregate of those small acts is a significant portion of how knowledge moves in this field.
I want to be part of that aggregate. Not for recognition — most of it is anonymous or nearly so. But because being on the receiving end of it taught me its value, and because giving it back is the only appropriate response I can think of to having received it.
What It Made Me Eager For
One unexpected thing about writing and teaching is what it does to curiosity.
Learning in isolation — reading, building, experimenting — can become self-contained. You learn what your projects require. You fill gaps as they are exposed by the work. The shape of your knowledge is largely determined by the shape of the problems you have been paid to solve.
Writing and teaching pull against this. When you write publicly about something, you enter a conversation with everyone who has also thought about it — through their responses, their disagreements, their extensions of the ideas you introduced. When you teach a junior developer, their questions reveal aspects of the topic that you had not thought to examine because they were not in the problems you had been solving.
Both activities have consistently made me curious about things I had not thought to be curious about. A junior developer’s question about why CSS specificity works the way it does sent me into the cascade specification in a way that years of writing CSS had not. A reader’s challenge to something I had written about WebSocket architecture sent me into research about HTTP/2 server push that I had been vaguely aware of but never properly understood. A code review comment that disagreed with my approach to error handling opened a six-month interest in how different languages think about error semantics that has genuinely changed how I write TypeScript.
The appetite for this kind of directed curiosity is something I associate strongly with writing and teaching. They have kept me eager in a way that I think I might have lost if I had only been building — if the learning had only been in service of the immediate problem rather than in service of the explanation.
Conclusion
I write because it makes me honest about what I know. Because it makes me patient in a way that benefits every interaction I have with another developer. Because it produces a cognitive empathy that is genuinely useful in collaborative engineering work. Because it shows me where my map ends and the territory continues. Because it distinguishes the real understanding from the performance of it, and because I have found that distinction to be one of the most valuable things I can pay attention to.
I teach because the gap between doing and explaining is where learning lives. Because a junior developer’s confusion is almost always pointing at something real that I have been routing around in my own understanding. Because the obligation to be clear forces a precision that I would not develop if I only ever explained things to myself.
And I do both because a decade of other people’s writing made me what I am as an engineer, and the only way I know to respond to a gift is to pass it forward.
The contributions are small. The audience is modest. The knowledge involved is not revolutionary. But there is something real in the attempt to take what you have learned through years of hard-won experience and put it into a form that someone else can use. Something that has nothing to do with scale or recognition, and everything to do with the simple, particular satisfaction of having understood something and given that understanding somewhere to go.
That is enough. It has always been enough.