What journalism taught me about writing code

I spent six years as a journalist before I became a software engineer. For most of that time, I thought of those as two separate chapters of my life — the writing chapter and the coding chapter. I was wrong. The longer I've worked as a developer, the more I've come to understand that everything I learned in a newsroom applies directly to what I do now. Just in a different language.

These are the journalism principles that changed how I write code.

Lead with what matters

The first rule of newspaper writing is the inverted pyramid: put the most important information first. The story should be structured so that if an editor cuts it from the bottom — which they will — nothing essential is lost. The reader gets the point immediately, and every subsequent paragraph earns its place by adding something the reader still needs.

I think about this constantly when I'm writing a component or a function. What does the person reading this code need to know first? What's the most important thing this does? If someone reads only the first ten lines, do they understand the contract?

A well-structured function leads with its purpose. Its parameters make the inputs obvious. Its return value or side effects are clear. The details — the edge cases, the implementation — come after. You should be able to read the signature and the first few lines and know what you're working with, without having to read to the bottom to discover a crucial piece of behavior buried in an else clause.

Every word has to earn its place

Good editors are ruthless. The question they ask about every sentence — every word — is: does this earn its place? If you remove it, does something important disappear? If the answer is no, it goes.

I apply the same standard to code. A line that doesn't do anything — a variable that's set but never read, a comment that describes what the code obviously does rather than why it does it, an abstraction layer that exists because it seemed like a good idea at the time — is noise. It makes the signal harder to find. It forces the next person to read more to understand less.

This isn't an argument for code golf or for stripping out clarity in pursuit of brevity. It's an argument for intention. Write what needs to be there. Remove what doesn't. The discipline is the same whether you're cutting a 2,000-word draft to 800 or refactoring a service that's grown three times larger than its actual responsibilities require.

Your reader won't wait

Journalism operates under a fundamental assumption: the reader owes you nothing. They didn't sign a contract. They're not obligated to stay. If you lose them in the second paragraph, they're gone. Every sentence has to keep them reading the next one.

Users of software have the same relationship to what you've built. They'll leave. They'll click away. They'll give up on a form that loads slowly or a UI that requires them to think too hard about what to do next. The burden is entirely on you — the person who built it — to make the experience clear enough and fast enough and considerate enough that they stay.

This reframe changed how I think about performance and UX. It's not a technical problem — it's an editorial one. Every millisecond of load time, every confusing label, every interaction that requires the user to pause and figure out what's happening is a sentence that made the reader put down the paper. The question isn't "does this work?" It's "does this keep people reading?"

Structure is not a constraint — it's a gift

New journalists often chafe against structure. The inverted pyramid feels like a cage. The nut graf feels formulaic. The word count feels arbitrary. The argument against all of it is usually some version of: great writing breaks the rules.

Which is true. But what those writers mean is that great writing internalizes the rules so deeply that it can bend them intentionally and usefully — not that the rules don't exist. The structure is what makes the bending meaningful. Without it, there's nothing to push against.

I think about component architecture the same way. A well-designed system has structure: clear separation of concerns, predictable patterns, consistent naming. Developers who are new to working in systems sometimes experience this as constraint. Why does this have to go here? Why is this named that way? Why can't I just do it directly?

Because the structure is what makes the system legible to everyone who comes after you. It's the thing that lets the next developer move quickly — because they know where to look, they know what to expect, they know what a change in one place will and won't affect. Structure is a gift to your future colleagues. And to your future self, six months from now, when you've forgotten what you were thinking.

Know who you're writing for

Every piece of journalism is written for a specific audience. Not "everyone" — a specific person, with a specific level of familiarity with the subject, a specific set of things they already know, and a specific reason for reading. Good journalists hold that person in mind throughout. They don't over-explain to an expert. They don't under-explain to a newcomer. They pitch the language, the context, the assumed knowledge exactly right for who's reading.

Code has the same audience problem. Are you writing for a future you, working alone on a personal project? For a team of senior engineers who know the codebase inside out? For someone who will inherit this in two years and has never seen it before? The answer changes everything about how much you comment, how much you abstract, how explicitly you name things, how much context you build into the structure itself.

The failure mode I see most often in codebases is code written for no one in particular — where the author assumed a reader who had the same context they had at the moment of writing, and didn't account for the fact that context evaporates. The best code I've read was written by someone who knew exactly who would read it next, and wrote for them.

The craft is the same

I don't think it's a coincidence that the developers whose work I most admire tend to also be good writers — people who communicate clearly, who think carefully about structure, who care about the experience of reading their code the way a journalist cares about the experience of reading their prose.

The medium is different. The vocabulary is different. The tools are completely different. But the underlying discipline — the commitment to clarity, to structure, to respecting the reader's time, to earning every word — is the same craft. I just had to spend six years in a newsroom to realize it.