The Habit of Writing as a Developer

In day-to-day work, we're constantly communicating, solving problems, making decisions, and learning along the way. Behind every solution we build, there's a trail of thought - assumptions, trade-offs, constraints, and agreements.

The problem is that this context doesn't age well. When we look back weeks, months, or years later, we often see _what_was done, but not why. The supporting reasoning quietly disappears from memory.

Some experienced developers recognize this early. They start making notes - not because they love documentation, but because they understand how fragile context is. This is where comments, commit messages, and documentation begin to matter. You return to a piece of code after a long time, stare at it, and wonder what it even does - or worse, why it exists at all. A few well-placed explanations can save hours of rediscovery.

For many of us, documentation feels like a chore. Something we promise ourselves we'll do "after the feature is done." But when writing is integrated into the workflow - rather than treated as an extra responsibility - it stops feeling like overhead. You start to notice that writing doesn't just preserve how something was built, but also sharpens your understanding while building it.

And that's where writing becomes more than just record-keeping.

When you try to write down your thought process, vague intuitions don't survive. You're forced to give them structure and clarity. In that process, gaps in understanding surface naturally. Things that felt obvious in your head suddenly demand explanation - and sometimes you realize you don't actually know them as well as you thought.

Regular writing also improves communication. Over the years, while mentoring junior developers and working with peers, I've noticed that struggles with communication are often rooted in unclear thinking. My advice has almost always been the same: write more - or at least start writing. Even if no one else reads it.

A few habits developers can adopt:

• When given a task, write down what you're trying to solve. Describe the problem clearly, along with its dependencies and constraints.

• List what you need to complete the task. Do you actually have everything required, or are there unknowns hiding beneath the surface?

• Write your approach before you start coding. Be honest here. Often this is where you realize you're impatient - or that you don't yet know how you'll reach the end.

Some seasoned developers take this even further by building a "second brain" - an external system to store learnings, ideas, and reflections. Tools like Obsidian or Notion are popular not because they're fancy, but because they make writing frictionless. Over time, patterns start to emerge across notes. Ideas connect. Knowledge becomes easier to navigate.

That's when the real power of writing shows up.

You begin to see how your understanding is structured. Learning new things becomes faster. Confidence grows - not because you know everything, but because you can reason your way through what you don't.

So write.
Not for an audience.
Not for perfection.
But to think more clearly.