the blank page problem

writing and coding are the same discipline wearing different clothes

Feb 22, 2026

You open a new document. The cursor blinks. You have an idea (or something that resembles an idea), and you have to decide what to do with it.

You open a new file. The cursor blinks. You have a problem to solve (or something that resembles a problem), and you have to decide where to start.

Same moment. Different medium.

I’ve been sitting with this observation for a while. I’ve started using Claude Code and enrolled myself in 28 Days of Lovable. As I use these tools to build more and more, I realize how creative and technical work relate to each other.

We’ve spent years building walls between “writing people” and “coding people,” as if the two disciplines live in separate neighborhoods and don’t use the same grocery store.

But lately, especially after spending time in these tools, watching what happens when you describe what you want, and having something functional appear on the other side, I can’t unsee how similar the underlying muscles are.

Both start from an idea or a problem, and how to solve it. Both require you to make decisions before you have all the information. Both will humble you regularly.

Every great piece of writing starts with a question that needs answering

Not a topic. A question. What’s actually broken about the way we think about this? What does everyone believe that isn’t quite true? What tension exists that nobody’s naming out loud?

The code equivalent: What problem are we solving? Not “what feature should we build,” but what is actually broken, for whom, and why does it matter enough to fix?

This is where most people get it wrong in both disciplines. Writers mistake having an opinion for having a point. Developers mistake having a request for having a requirement. The question-first discipline, really sitting with the problem before reaching for the keyboard, separates the work that lands from the work that’s just... volume.

April Dunford talks about this in Obviously Awesome, in the context of positioning: the failure isn’t bad messaging; it’s that you haven’t clearly defined the problem you solve before you start describing the solution. Writing has the same bug. You can be technically excellent (clean sentences, elegant structure) and still produce something that goes nowhere because you skipped the problem-definition step.

Then you write a first draft. Then you write it again.

Anyone who tells you their first draft was good is lying to you or doesn’t know what good is yet, but this is a safe space! (This is my first draft.)

Same with code.

The first version works in the sense that it runs, or makes sense, or gets the idea across, but it’s carrying a lot of debt. Decisions you made under uncertainty. The logic you followed before you understood the constraints. Sentences that got you somewhere you needed to go, but don’t need to stay in the final version.

In software, this is refactoring. In writing, it’s revision. The emotional experience is almost identical: you look at something you built, and you have to be willing to break it. Not because it failed, but because you’ve learned enough now to do it better.

This is the part nobody romanticizes. The messy middle. The part where your original structure stops making sense and you’re staring at something that is technically words, or technically functional, but has the distinct energy of a thing that doesn’t fully know what it is yet. This is where you develop taste and add and discard as you see fit.

Chaos Monkeys mentions the brutal compression of early product decisions. The ones made at 2 am with incomplete information that become load-bearing walls by morning. Writing has the same physics. You make a structural choice early, often without realizing it, and three paragraphs later, you’re living with the consequences.

The unit of both is not words or code. It’s decisions.

Here’s what actually makes writing and coding hard: not the output, but the relentless decision-making underneath it. Every sentence is a choice about what to include and what to leave out, which is really a choice about what you believe. Every function is a choice about how to model reality, which is also a choice about what you believe.

Amanda Montell discusses this in Cultish, arguing that language is never neutral. How the words you pick and the structures you build carry ideological weight, whether you intend them to or not. The same is true of code. Every database schema is an argument. Every API design is a worldview.

This is what makes both disciplines interesting and also deeply exhausting. You can’t coast. There’s no section of writing or engineering that’s purely mechanical, where you can turn your brain off and just execute. If you try, the work becomes generic. It resembles the thing without being the thing.

Where does that leave us with autonomous agents, AI, and what’s on the horizon?

Both require you to write for a reader.

The best developers write code for the next person who has to maintain it. Not just for the machine to execute, but for the human who will encounter it six months from now and need to understand what it was trying to do. Comments aren’t documentation of what the code does. They are documentation of why.

Writing for readers is, obviously, the whole job. But the principle is the same: you are always translating something in your head into something legible to someone else, and the gap between those two things is where skill lives. You’re also documenting why.

You can hear people through their writing, the ecstatic ones and the unimpressed ones and the frantic ones (or busy ones) whose sentences start breaking apart because they’re freewriting in fragments and everything’s practically falling out at once. That’s not a style choice. That’s transmission. Some may call it the language of frantic (or busy) people.

The best code has this quality too, in its way. You can feel the clarity of someone who knew what they were doing versus someone who was figuring it out as they went.

There’s a craft to both that can’t be skipped, only deferred.

This is maybe the most important thing. We’re in a moment where the tools have gotten very good at producing the appearance of both. You can generate a post that looks like writing. You can generate code that looks like engineering. You can ship something that resembles good work without doing the underlying work that makes something good.

The illusion of fluency. Tools produce polish, but not perspective. The ability to generate has outpaced the ability to evaluate. And evaluation, knowing why something works, why it doesn’t, what you’d do differently, is the thing that actually compounds over time.

Neither writing nor coding is a skill you acquire. It’s a practice you maintain. The judgment that lets you know when a sentence is done, when a function is clean, when a problem is actually solved, and not just handled. That only comes from iteration. From the reps. From caring enough to push past the first version that technically works.

Which is why this Substack exists. My GitHub has also been revived (wow).

The real unlock is that they’re training the same instinct.

If you write, you’re learning to think in public. To make your reasoning visible and legible, to anticipate where you’ll lose people and tighten before you do.

If you code, you’re learning to break problems into solvable pieces. To separate concerns, to name things clearly, to make implicit logic explicit.

Both of these are, at their core, communication skills. Both are, at their core, thinking skills. The medium differs. The discipline is the same.

I’ve been thinking about this whenever someone frames content and engineering as separate worlds with distinct sensibilities. As if one is creative and one is technical. As if the instinct to make something that didn’t exist before isn’t the same instinct wearing different clothes.

It is. It absolutely is.

The blank page problem is the same problem. You have an idea. You have to figure out what it’s actually saying. You have to make decisions before you have all the information. You have to revise. You have to ship it before it’s perfect, or it never ships.

And then you start over with the next one.

this is am I… a marketer? — a newsletter about a marketer and marketing in progress. If this resonated, share it with someone who codes or someone who writes, and watch what happens.