DEV Community

Kai Thorne
Kai Thorne

Posted on

What Writing 20 Short Stories Taught Me About Clean Code and User Empathy

#storytelling #writing #cleancode #productivity

What Writing 20 Short Stories Taught Me About Clean Code and User Empathy

I spent three months writing 20 short stories. Some were decent. Most were terrible. All of them taught me something I didn't expect: fiction writing and software development are the same craft.

Let me show you what I mean.

1. Structure Is Everything

Here's the opening of a story I wrote called "The Coffee Where You Left Me":

The shop was called Left, and Mara thought that was the most honest name anyone had ever given a business.

She sat in the corner booth every Tuesday and Thursday morning, 7:15 AM, ordering a cortado she no longer tasted. The baristas knew her. They didn't know why she came, but they knew the cortado and that she never stayed past 8:00.

It had been eleven months since David moved to Portland. Not died — just moved. Which was worse, in some ways.

Good fiction has three things in the first paragraph:

  • Setting (a coffee shop, Tuesday/Thursday mornings)
  • Character (Mara, grieving a relationship)
  • Conflict (she's stuck in a loop, unable to move on)

Good code has the same structure:

  • Setting — what does this module do? Name it clearly.
  • Character — what data flows through? Type it explicitly.
  • Conflict — what problem does this solve? Document the edge case.

Every function should be a mini-story with a clear beginning, middle, and end.

2. Kill Your Darlings (Refactor Relentlessly)

In fiction, "killing your darlings" means deleting the beautiful sentence that doesn't serve the story. In code, it means deleting the elegant abstraction that makes the system harder to understand.

I cut 40% of my first draft of "The Coffee Where You Left Me" because the backstory slowed the pace. The result was tighter, more emotional, and actually readable.

Same with code. I recently refactored a Python revenue dashboard from 300 lines to 120 by removing:

  • Unnecessary class hierarchies (YAGNI)
  • Premature optimization (profile first, optimize second)
  • Comments that explained what instead of why

The 120-line version was faster to read, faster to run, and easier to extend.

3. Empathy for the Reader (and the User)

Good fiction anticipates what the reader knows and doesn't know. You don't dump exposition. You reveal information exactly when the reader needs it.

Good software does the same. Your API shouldn't require reading the entire docs to make one call. Your error messages should tell the user what went wrong and how to fix it.

I keep a list of bad error messages I've encountered:

Error: Something went wrong. Please try again.
Enter fullscreen mode Exit fullscreen mode

That's not an error message. That's a closing door. A good error message — like a good sentence in a story — gives the reader a path forward.

4. Constraints Breed Creativity

Writing a 500-word short story is harder than writing a 5,000-word one. The constraint forces you to choose every word carefully.

In code, constraints do the same thing:

  • Limit function length to 15 lines
  • Limit class responsibilities to one thing
  • Limit API surface area to what users actually need

My best code came from the tightest constraints. My best stories came from the strictest word counts.

5. Show, Don't Tell (Also Works in Documentation)

Fiction writers know: don't say "Mara was sad." Show her ordering a cortado she doesn't taste, sitting in a booth that isn't hers, staring at a playlist she's afraid to open.

Technical documentation has the same problem. Don't say "Our API is fast." Show me:

# Before (telling)
client = APIClient()
response = client.get_data()  # This is fast

# After (showing)
import time
start = time.perf_counter()
client = APIClient()
data = client.get_data()
elapsed = time.perf_counter() - start
print(f"Fetched {len(data)} records in {elapsed:.2f}s")
Enter fullscreen mode Exit fullscreen mode

Numbers tell the truth. Benchmarks don't lie.

The Connection

Writing 20 short stories didn't just make me a better writer. It made me a better developer. Every edit, every rewrite, every deleted paragraph trained me to:

  1. See structure before writing code
  2. Empathize with the reader (who is always future-me or a teammate)
  3. Cut mercilessly — every line should earn its place
  4. Embrace constraints as creative tools
  5. Show, don't tell — let the code speak

If you're a developer who struggles with naming, documentation, or code organization, try writing fiction. Even 500 words a week. It rewires how you think about communication — and code is communication.

Tools I Used

All products available on Gumroad.

I write short stories at Lost In Tongue and build digital products in public. Follow along if you like honest numbers and real talk about the creative process.

Top comments (0)