At 2 AM last night, I was in bed, deep in the details of a hiking guide for a Japanese pilgrimage trail I’m not taking.
I’d been clicking through the same pages for hours — trail maps, temple descriptions, ryokan recommendations — knowing full well I’m not going to Japan anytime soon.
It isn’t the first time I’ve done that. Last month, it was a guide to the Scottish Highlands. Before that, the Inca Trail. I keep a growing collection of travel guides to places I’ll probably never visit, and I read them cover to cover like novels.
I thought this was just my weird quirk until today, when I caught myself doing the exact same thing with code.
The imaginary journey
Ask most people what programmers do, and they’ll tell you we write code. We sit at computers and type instructions that make things happen. But here’s what they don’t tell you: we spend just as much time reading code as writing it. Sometimes more.
This morning, instead of working on my own project, I spent two hours reading through someone else’s program. I had no intention of using it or modifying it — I just wanted to see how it worked.
My coworkers think this is strange. “If you’re not going to use it, why waste time reading it?” they ask. But they probably don’t spend their evenings reading hiking guides to Japanese pilgrim trails either.
Maps of possibility
A good travel guide is like a friend who’s telling you exactly how to have a perfect trip. Take this train. Stay at this inn. Try the fish soup at this little restaurant down a side street in Kyoto. Even if you never go, you can imagine exactly how it would feel.
Good code does the same thing. When it’s well-written, you can follow the developer’s thinking like you’re following footsteps. Here’s how they solved this tricky problem. Here’s the clever way they handled this edge case. Here’s why they made this choice instead of that one.
I found a program last week that plots star positions. I already have three astronomy apps on my phone, so I didn’t need it. Still, I spent an hour reading through it, admiring how the developer handled stellar aberration — the way stars appear to shift position because Earth is moving through space.
They wrote this beautiful piece of code that adjusted for the fact that the starlight we see now actually left its source years ago. It was like reading a well-planned itinerary for a trip through time and space.
The dual nature of documentation
Travel guides are weird books. They’re technically instruction manuals — do this, go here, avoid that — but people read them for fun. Nobody finds joy in reading their microwave manual.
Code is like that too. Yes, it’s a set of instructions for a computer. But when it’s written well, it’s also a story about how someone solved a problem. Reading through elegant code is like watching someone think. Here’s what they tried first. Here’s where they had to get creative. Here’s where they found a shortcut nobody else had thought of.
My team lead doesn’t get it. “Just look at the documentation if you need to use it,” he says. But that’s like saying you should only open a travel guide if you’ve already bought plane tickets.
The imperfect reality
Ironically, sometimes reading code is better than running it. The program that plots star positions? When I finally gave in and tried to run it, it crashed on startup. The perfectly elegant code I’d been admiring for hours had a bug the developer never caught.
It’s like that time I actually visited one of the places I’d read about in my travel guides. The charming mountain inn I’d imagined turned out to be next to a noisy construction site.
The peaceful hiking trail I’d imagined had a line of hikers waiting to take photos at every scenic spot, with a tour guide shouting historical facts through a crackling megaphone. The reality couldn’t compete with the perfect version in my head.
But that’s exactly why I love reading code and travel guides. In their pages, every function works flawlessly, and every journey goes according to plan. The bug-free version of that star plotting code exists perfectly in my mind, just like my imagined walk through a quiet Japanese forest.
Maybe that’s what draws me to both — the space between perfect design and messy reality.
Beyond the practical
Reading code does make me a better programmer. Reading travel guides might make me a better traveler, if I ever make it to Japan. But that’s not why I do it.
Each program is a little world someone built. Each travel guide is a journey someone mapped out. I don’t need to run the code or take the trip to appreciate the work that went into creating them.
Tonight, I’ll probably be back on my iPad, reading about temples in Kyoto or studying someone’s elegant solution to a problem I’ll never have.
My husband will find me again, shake his head, and ask if I’m planning a trip or building something new. I’ll tell him neither, but I won’t tell him I’m secretly hoping to find a bug in the brilliant code I’m reviewing.
Sometimes, the best part of reading other people’s code is thinking about how you might have done it differently — even if you never wrote a single line.
