Empathy over Ego
Code is read more than written. Be human.
Five years ago, I wrote a data parser that still runs today.
It handled edge cases nobody warned us about. Took flat files from a vendor who’d never heard of schemas. Normalized everything into tidy rows for the warehouse. At the time, I was proud of how concise it was. It had no third-party dependencies. It used clever recursion, tight loops, and a few expressions I knew would confuse anyone who hadn’t been knee-deep in it for months.
Which, of course, I had been.
That was the point. I was deep in the weeds and proud of the thorns I’d fought through.
Then, last year, Jess joined the team.
Fresh hire. First job. She asked good questions, the kind that made me pause—not because they were bad, but because I didn’t have an answer I was still proud of.
I was asked to onboard her. I told the manager it’d take a day. The doc was short. The code was clean. I’d even added a few comments—though admittedly, some were more clever than helpful.
It took a week.
By day two, Jess had that look I recognized from my own first job: part confusion, part frustration, part is it me or is this just weird?
She’d call me over and ask things like:
“What does
xFormCnv()stand for?”
“Why is the same function calling itself here, but not there?”
“This comment says
// because we have to, but… why do we have to?”
Every time, I’d start to explain and then realize—I didn’t remember. Or I remembered feeling clever about it, but not why I’d written it that way. I’d dig through old commits, re-read my own code like it was a stranger’s, and sometimes come away thinking: What the hell was I doing here?
Jess never criticized it. She just kept asking.
On Friday, she thanked me:
“You’ve been super patient. I know this stuff is probably obvious to you, but I really appreciate you walking me through it.”
It should have felt good.
Instead, I felt ashamed.
I wasn’t trying to be confusing.
But I wasn’t trying not to be, either.
The thing is, the code worked. It worked well. It hadn’t broken in five years. And yet, something was clearly broken—just not technically.
What Jess needed wasn’t documentation. It was a breadcrumb trail. She needed a path through the forest, not a map I sketched from memory five years ago and forgot to label.
I realized the cleverness I was so proud of was a tax someone else had to pay. A toll booth I set up, without signs or a receipt.
And it wasn’t just Jess.
A few months earlier, I’d demoed a new analytics dashboard for our care team. It had filters, hover states, predictive scoring, even a snappy UX. But after five minutes, one of the nurse leads looked up and said:
“What am I supposed to do with this?”
That stung more than any bug report.
To me, everything was there—obvious. To them, it was noise.
What’s clear to engineers is often noise to caregivers.
What’s clever to us can be hostile to someone else’s workflow.
That month, I rewrote the parser.
Not because it was broken.
Because it worked—but at a cost I hadn’t seen.
I renamed functions to what they actually did. Turned xFormCnv() into transform_currency_units(). Replaced inline logic with small, readable helpers. Wrote comments like I was teaching—not hiding a trick.
It wasn’t thrilling work. It didn’t feel smart. But when Jess opened the new version, she smiled:
“This feels like it was written for someone.”
It was.
It was written for her.
For whoever comes after her.
For the next person who has to trace the thing in a pinch.
For the nurse trying to understand the why behind a number.
For me, five years from now, at 11PM, trying to debug something I barely remember.