Most of us in tech read for a living. Documentation, changelogs, RFCs, pull request descriptions, Stack Overflow answers, incident reports. We are professional readers, and yet when someone asks "what are you reading?", the honest answer is often "another blog post about Kubernetes."
That's fine. But reading for information trains exactly one muscle: precision. There's another muscle that most engineering careers quietly starve, and it's the one that decides whether you're a good teammate, a good lead, a good interviewer, and a good communicator. It's empathy for a point of view that isn't yours.
Fiction is the cheapest, most portable gym for that muscle. In this post I want to make the case for it, using one very specific example: the "gifted outsider" story, and why it hits so close to home for people who build software.
Table of contents
The gifted outsider problem
Impostor syndrome has a twin nobody mentions
What stories do that style guides can't
Humor as an engineering coping mechanism
Narrative is a technical skill
A 30-day reading experiment
A note on where this idea came from
Your turn
- The gifted outsider problem
Take the classic Superman origin. In the standard telling, extraordinary ability is simply good news. He's strong, fast, and the world needs him. End of story.
Now ask a different question: what if extraordinary ability made a kid feel more alone, not less? What if being "special" meant being constantly watched, constantly needed, and rarely understood?
If you've worked in engineering for more than a couple of years, you probably recognize some version of this:
You're the one person who understands the legacy billing module, so every ticket that touches it lands on you.
You get praised for output but nobody asks whether the pace is sustainable.
You're quick at certain things, and that speed gets mistaken for ease, so people stop noticing the effort.
You feel like the only person in the room who sees the problem, and, an hour later, like a fraud who got lucky.
None of this shows up in a sprint retro. It lives in the gaps between standups. Stories are one of the few tools we have for naming those gaps.
- Impostor syndrome has a twin nobody mentions
We talk a lot about impostor syndrome: the fear that you're less capable than people think. It's well discussed, and for good reason.
But there's a flip side that gets far less attention, which you could call the "burden of competence". It's the quiet exhaustion of being the person everyone relies on. It looks like this:
Impostor syndrome Burden of competence
"They'll find out I'm not good enough." "They'll never let me stop being the one who fixes it."
Fear of being exposed Fear of being used up
Pushes you to over-prepare Pushes you to over-deliver
Hides in silence Hides behind reliability
Both are lonely. Both can lead to burnout. And the same person can feel both on the same day. A good novel about a gifted misfit gives you language for the second one, which most workplaces don't have vocabulary for.
If you manage people, this is worth sitting with. Your most dependable engineer may be the one closest to the edge, precisely because they never complain.
- What stories do that style guides can't
I'm a big fan of style guides and coding standards. But here are three things fiction teaches that they never will.
Talent without context is isolating
A reputation like "10x" sounds flattering, but it can turn a person into infrastructure. People route problems through them, stop inviting them into design conversations as an equal, and treat their availability as a given. A story that follows a gifted character through awkward, ordinary, heartbreaking moments reminds you that the person behind the reputation still wants what everyone wants: to be known.
Other people's inner lives are not visible in a diff
Code review gives you the artifact, not the person. You see the change, not the three bad nights that preceded it. Reading fiction is repeated practice at inferring what's going on beneath the surface of someone's behavior. That skill transfers directly into 1:1s, onboarding, and conflict resolution.
Ambiguity is allowed
Software culture rewards clean answers. Stories don't. A good novel lets a character be right and wrong at once, sympathetic and infuriating at once. Getting comfortable with that makes you better at the genuinely ambiguous parts of the job: architecture tradeoffs, prioritization, deciding what not to build.
- Humor as an engineering coping mechanism
Look at any engineering community and you'll find the same thing: dark, absurd humor. Postmortems with ridiculous titles. Memes about production going down on Friday. Commit messages that read like cries for help.
That's not unprofessionalism. Humor is how technical people process stress that doesn't fit into a ticket. And it works as communication, too: a well-timed joke in a tense incident channel can lower everyone's heart rate enough to think clearly.
Fiction that blends comedy with real sadness (the kind where you laugh and then feel a little guilty about laughing) is a great mirror for this. It reminds you that laughter and discomfort often come out of the same cup, and that it's okay to hold both.
- Narrative is a technical skill
Here's the most practical argument in this post.
Every senior engineer eventually discovers that being right isn't enough. You have to persuade. And persuasion, much of the time, is storytelling:
Paying down tech debt: A chart of cyclomatic complexity rarely moves a roadmap. A story about one real customer's bad afternoon, and the three-line root cause behind it, often does.
Writing a design doc: The best ones have a plot. There's a situation, a tension, options, a decision, and consequences.
Giving a talk: People remember the story of the outage, not slide 14.
Interviewing: "Tell me about a time you disagreed with a teammate" is a request for a narrative with stakes and an arc.
You can practice this on purpose. Read stories, notice how tension is built, and then steal the techniques for your next design doc. Nobody has ever been fired for making a technical document readable.
- A 30-day reading experiment
You don't need a book club or a subscription. Try this:
Pick one piece of fiction that isn't a tech book. Novel, short stories, graphic novel, whatever you'll actually finish. Your library card is enough.
Read 15 minutes, three or four nights a week. Replace one scroll session, not your whole evening.
Write one sentence after each session about a decision a character made under pressure and why.
At the end of week two, pick one real work situation (a disagreement, a tough review, a stalled project) and rewrite it in a paragraph from the other person's point of view.
At the end of 30 days, note whether anything changed in how you listen in meetings or write messages.
If nothing changed, you still read some good stories. That's a fine downside.
- A note on where this idea came from
I've been thinking about all of this since writing Waiting for Clark Kent: An Existential Cartoon. It's a comic-philosophical take on a teenage Clark Kent who stumbles through adolescence, heartbreak, and the strange weight of unwanted talent in a very ordinary world. It mixes in baseball history, existential humor, and philosophical confusion. It is not a tech book in any way.
What surprised me is that readers from all sorts of backgrounds, including technical ones, connected with the "gifted misfit" theme. It turns out feeling like an outsider while everyone insists you're special is a pretty universal experience, and engineers have no shortage of it.
If you're curious, you can find the book details, an interview, and a free audio sample of Chapter 1 on my site: bradlaidmanwrites.com.
(Disclosure: I'm the author of that book. The reading suggestions above stand on their own, and you don't need to buy anything for the experiment to work.)
- Your turn
I'd really like to hear from you in the comments:
What's one novel, comic, or story that changed how you think about your work or your team?
Have you felt the "burden of competence" I described, or seen it in a colleague?
Do you write fiction (or anything non-technical) on the side? How does it affect your day job?
I'll read every reply and add the best recommendations to my own list.
Thanks for reading.
