An exception comes in. Red text, forty lines of it.
The top line tells you what broke. The “Why” is further down, in the frame that belongs to your code. So you read past the top line, find the frame. You follow the path back to where the problem actually started, which is usually not where it surfaced.
That’s the whole habit. I’ve been doing it for twenty-five years.
What the trace looks like has changed more times than I can count. A PHP white screen with the fatal error buried in a log. A browser console full of minified line numbers. A .NET exception wrapping an inner exception wrapping another one, the real cause three layers deep. Every stack I’ve worked in changed the shape of the text on the screen.
None of them changed what you do with it. Read past the top line. Find your frame. Follow it back.
And every one of them offered a way around it.
For a long time, the way around was pasting the error message into a search engine and trying whatever came back. Then it was jumping to the top answer on Stack Overflow and applying the fix without reading the question. Restart the service and see if it happens again. Let the monitoring dashboard group it with forty others and tell you it’s the usual one. Now you can paste the whole trace into a chat window and get a confident paragraph back.
The shortcut isn’t new. It’s one of the oldest things in the job. It just gets a new interface every few years.
Last week I wrote about spending a whole career adjusting to ground that keeps moving, and I said that wasn’t a virtue. It was survival. Nobody deserves credit for adapting when the alternative is being left behind. The industry forced that on all of us.
It never forced this. No job I’ve had required me to read the whole trace. No code review checks whether you did. No sprint metric knows. Most of the time the ticket closes the same either way. The habit stayed strong through every change. I chose it again and again, even when each era gave me reasons to stop.
Which means it isn’t something I have; it’s something I keep doing. Those are not the same thing.
Epictetus has a short discourse called “On Attention.” It starts with a warning that feels like it’s for someone deep into a Friday afternoon debugging session. When you let your attention slip for a little while, he says, don’t imagine you can pick it back up whenever you choose. The slip does damage, and the damage isn’t the one mistake. It’s what the mistake trains into you. First, “a habit of not attending is formed in you.” Then a habit of putting attention off.
Then he asks the question I can’t get past. Does a woodworker do better work by not paying attention to the wood? Does a ship’s captain steer better that way? Is there any part of life, any small act, that gets done better with less attention?
He wasn’t talking about stack traces. He meant the whole of a life, the Stoic practice called prosoche: constant watchfulness over your own judgments and choices. He used craftsmen to make his point. In a craft, the cost of neglect shows in the work. You can’t argue with it.
Here’s where I have to be honest. I skim.
Not always. But after twenty-five years I still feel the pull, and I’ve given in to it. I read the top line and recognized the exception. I thought I knew what it was about, but I was wrong. I overlooked the detail that really mattered. It was right there in the trace. I just never read far enough to reach it.
The skim was never really a reading problem. It was a moment where I decided I already knew, and didn’t notice I’d decided.
Experience doesn’t retire that pull. If anything it makes it stronger. The more traces you’ve read, the more often the top line really is the usual thing, and the more reasonable it feels to assume. Pattern recognition is the payoff of experience. It’s also exactly what makes skimming feel safe.
Every one of those skims was a small version of what Epictetus describes. I’ll read it properly next time. This one’s obviously the same null reference. It’s late.
The danger was never any single wrong assumption. I caught those, eventually. The danger was what each one made easier: the next skim.
Epictetus doesn’t pretend you can get this perfect. He says outright that being free of faults isn’t possible. What is possible is to keep directing your effort toward it without letting up, and to be satisfied if that saves you from a few errors. He also has no patience for the person who says he’ll start paying attention tomorrow. Saying that, he argues, is just deciding to be careless today.
Your C# knowledge, your SQL, your mental map of a legacy system: those accumulate, and they depreciate, and when the stack changes you feel the loss. Attention doesn’t work that way. It doesn’t depreciate when the stack changes, and it doesn’t accumulate either. What it builds accumulates. The attention itself doesn’t. You can’t store up twenty-five years of it and draw it down on a bad day. There’s only the trace in front of you, and whether you read it.
Every era of this industry will keep offering a reason to read only the top line. The reasons will get better. The interfaces will get friendlier. The confident paragraph will get more confident.
None of it will ever make you read the rest. Nobody ever made you read it in the first place.
👉 If you enjoy reading this post, feel free to share it with friends!
Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏
You can find me on X and Instagram.