Computers *must* be understood.
Most of the time, it's a better idea to just put in the patch at the higher level, avoiding the bad path. I mean, to fix the thing, you are going to have to dig down the stack - going into a library that you don't own, through to a service that you didn't even know about, and through to the serialization layer that you don't understand. You can just avoid making the call multiple times. You can patch the bug, and move on. You have other things to do!
But a few days later, you're still trying to understand it. You've figured out how to attach a debugger remotely; you've figured out how to launch the dep service, and you are reading through the underlying library. You consult an LLM, trying to make sense of the complexity.
It's irrational. Your actions are suboptimal. Most people would have been reasonable - most people would have patched it and moved on. Most of people would have shortest path to the fix.
But the unexplained behavior. It can be understood. It must be understood. I won't be able to sleep otherwise. I need to know. I will unravel the stack; I'll pick up new tools. I will rewrite the entire thing if I have to. I need to understand it.
I'll honestly risk my performance, my project's delivery for it. I'll rabbit hole all the way down.
you can fix it
There's a maturation transition that some software engineers go through. One, of being able to fix anything. Being able to understand anything. Most software engineers are not like this - they'll come across artificial walls, like some dependency that is bugging out, or "ownership". But all of that is a meme. If you wanted to figure it out, you could. It's a state machine, it's a computer. It does exactly what you tell it to do. If you write down, on a piece of paper, exactly what you are telling it to do - you will be able to figure out where - and what is wrong.
It's a computer. It's just bits on disks. How hard could it possibly be?
you should understand it
I have a very strong instinct, encouraging me to understand things. I will sacrifice quite a lot to understand things. I'll avoid taking the easy path; opting for simplicity. I eschew dependencies, I pay attention. I understand what I'm doing, what is actually happening.
this takes me down odd paths. and, honestly, it makes me pretty slow (in comparison to my maximum speed). but it accrues, and accrues. and eventually, I know how everything works. It helps me fix things. even things I've never touched
I can't ignore it
This, incessant itch to know, is unignorable. So, I've leaned in. I need to know, so I always try to know. Because I always try to know, I've got better at knowing, figuring out. I run my own custom tools. A regex trigram index for instant code search. I generate graphviz state machines with LLMs. I try to build new tools every week.
it's worth it
The more painful it is to know, the less people that end up knowing. The more people that give up digging, the more treasure is to be found. Software engineering is literally this meme
The amount of times I've dug, and dug and dug and come across an incredibly bad bug, or fix, is enough to make this behavior terminal.
Digging through tech is a skinners box. I'm gambling. With my time.
And for some reason, my bets keep on paying off
