The Question That Matters
Some things are useful because they solve a problem.
Others are worth understanding even when you are not going to use them tomorrow.
That sounds obvious, but it is easy to forget when learning software development. We tend to measure everything by usefulness. Will this help me write better code? Will I use it at work? Is this worth remembering?
Sometimes the answer is simply: it is interesting.
And I think that is a perfectly good reason.
Not everything needs an immediate use case
Take something like CSS margin collapsing.
You can go years without deliberately using it. You might even work around it without knowing exactly what is happening.
But once you understand it, a strange behavior stops being strange.
That matters.
Understanding something gives you a better model of how the thing works. You do not need to use that knowledge every day for it to be valuable.
The same applies to things like how JavaScript evaluates expressions, how a browser calculates layout, or why a particular TypeScript type behaves the way it does.
You might not need the answer today.
But the next time you encounter the problem, you already have a place to start.
More importantly, you start recognizing similar problems.
A weird layout issue might not look exactly like the one you saw before. A TypeScript error might happen in a completely different part of the application. A JavaScript behavior might appear in an API you have never used.
The details change.
The mental model stays.
Useful is not the same as valuable
There is a difference between learning something because you need it and learning something because it makes the system make more sense.
The first gets you moving.
The second changes how you see things.
That distinction is important because software is full of behavior that is technically easy to ignore.
You can memorize that something happens.
You can also understand why it happens.
The second one tends to stick.
Think about debugging.
You can memorize a fix for a particular problem. Add this property. Move this code. Await this promise. Add this check. Restart the development server.
Sometimes that is all you need.
But if you understand the reason behind the fix, the next problem becomes easier.
You are no longer searching for the same solution. You are looking for the same kind of problem.
That is a much more useful thing to carry around.
Understanding gives you better questions
There is another benefit that is easy to miss.
Once you understand how something works, you start asking better questions.
Before you understand CSS layout, the question might be:
Why is this element doing this? Why is this property doing that?
After you understand the layout model, the question becomes:
Which constraint is causing this result?
That is a completely different debugging process.
The same thing happens with asynchronous JavaScript.
Instead of asking:
Why did this happen after that?
You start asking:
When was this callback scheduled, and what state did it capture?
Or with TypeScript:
Why does TypeScript hate this?
becomes:
Where did the type information disappear?
Those questions are more specific.
They give you somewhere to look.
Understanding does not just give you answers. It changes the questions you ask when you do not have an answer.
You do not have to remember everything
This is also why I do not think learning something requires memorizing every detail.
There is a difference between knowing something by heart and understanding it well enough to find your way back to it.
You will forget syntax.
You will forget exact APIs.
You will forget edge cases.
That is normal.
What tends to survive is the model.
You remember that CSS has different ways of calculating sizes. You remember that promises have their own scheduling behavior. You remember that TypeScript is tracking information that may disappear at certain boundaries.
The next time you need the details, you can look them up.
But you know what you are looking for.
That is often enough.
The rabbit hole is sometimes the point
This is one of the reasons I like digging into seemingly small technical details.
A question starts simple.
Why did this element move?
Why did this promise resolve to that value?
Why does this type behave differently here?
Why did this request still change the UI even though it failed?
The answer is often not immediately useful.
But following the answer usually reveals something about the system that was hidden before.
And sometimes that is enough.
A small question can lead somewhere much bigger.
You start with one strange behavior and end up understanding part of the larger algorithm.
You start with one confusing error and end up understanding how information is lost or preserved.
You start with one bug and end up understanding why the order of events in your application is not always the order the code appears in.
The original problem might never happen again.
The understanding still stays with you.
Curiosity is a useful engineering skill
There is a temptation to treat curiosity as something separate from practical engineering.
It is not.
Curiosity is often what makes you stop when something feels slightly wrong.
You could accept that the code works.
Instead, you ask why.
You could copy the fix from a search result.
Instead, you try to understand what the fix is actually changing.
You could move on after finding the answer.
Instead, you follow the next question.
That does not mean every rabbit hole is worth following.
Some are not.
You can spend an afternoon learning something that will never matter to your work. That is fine too, sometimes. But there is a difference between curiosity and collecting trivia.
The useful kind of curiosity changes your mental model.
You come out of the rabbit hole seeing something differently than you did before.
So, is it worth understanding?
I think a good question is not only:
"Will I use this?"
It is also:
"Will understanding this change how I think about the thing?"
If the answer is yes, it probably belongs in the rabbit hole.
Maybe it will help you debug something six months from now.
Maybe it will make a confusing API suddenly make sense.
Maybe it will help you recognize a bug before you write it.
Or maybe you will never use the knowledge directly.
You will just understand a little more about how the thing works.
That is enough of a reason.
Not everything you learn has to pay for itself immediately.
Sometimes understanding is the useful part.
Top comments (0)