I’ve always been fascinated with details.
They’re subtle, easy to ignore but every once in a while they turn out to be important.

I have gotten in very interesting (and often heated) discussions about this fascination (mainly at work).
Taking the time to go over the details, learn, understand and digest takes time.
And startups are always on a countdown clock and push to get things faster.
People too. If something seems like it can be ignored, we tend to ignore it.
I suppose most of our minds are already at capacity, way before someone starts a long-winded argument about things that seem trivial and inconsequential.

So, if almost nobody cares, why bother? Peace of mind.

Not in the soothe one’s OCD sense.
In the understanding and managing risk sense.

There’s this thing in software engineering called Agile Methodology that we mistake to mean I’ll think ahead as little as humanly possible

It makes sense if you’re managing a project that is short-term, one-off or will need constant supervision.
There, details are not that important.
Assuming you’ve got capable and/or invested people at the helm, they’ll react to any change caused by factors not identified in advance and course-correct.

But if you’re on a long-term, important project that you’re hoping to see through with minimal manpower, you need to streamline/automate/set-it-and-forget-it.
And you can’t hope to automate something you do not understand in detail.

You don’t need to delve into each and every little detail.
You don’t need to be able to write a paper on the subject.
But you need as few unknown unknowns as you can possibly have.
Having a deep enough to be meaningful, shallow enough to be time conscious and wide as possible understanding of the subject allows one to know where risk lies.

You can’t eliminate risk, it costs too much to do so.
But you can identify it, classify it and plan to mitigate if/when the need arises.
To do that, you need the details.