Why Some Abstractions Fascinate Me While Others Bore Me Instantly

This article continues the line of thought I began in my two previous pieces about my relationship with software development and artificial intelligence.

For some time now, I have been trying to understand why I have always found it so difficult to develop a deep interest in technical subjects.

Not to use them. Not to learn enough to make something work. But to genuinely want to understand what is happening underneath.

I became aware of it again recently while preparing for a project defense. For example, I had to be ready to potentially explain that a multi-stage Docker build makes it possible to separate the compilation stage using Maven from the final image, which only uses the JRE, notably in order to reduce the image size and limit potential vulnerabilities.

I can learn that sentence. I can even broadly understand what it means. But very quickly, something starts to bother me.

Why is Maven necessary during compilation but not afterwards? What exactly does the JRE contain? What actually disappears from the final image? Why does that make the image smaller, and more importantly, why does it reduce vulnerabilities?

Every answer seems to open three new doors. And at that point, my reaction is almost always the same: alright, I believe you, it works, we can move on. I have neither the time nor the desire to dig any deeper. And this is only one example among hundreds.

It is not that I dislike understanding things in general.

I can spend an enormous amount of time trying to understand something when the subject interests me: philosophies, religions, sociology, psychology. I can read several points of view, compare systems of thought, try to understand why individuals or societies function in a certain way, and keep digging simply because every answer creates a new and interesting question.

In those fields, abstraction does not bother me. Quite the opposite. I can find an idea fascinating even when it has no immediate practical application.

And this relationship with abstraction did not begin with computer science. I remember feeling exactly the same way in high school with mathematics and physics. When someone explained to me why white light could be split into different colors, my reaction was not: this is fascinating, I want to understand this phenomenon all the way down. It was more like: alright, so what?

I could perfectly well accept that a phenomenon existed without feeling the need to explore all the physics behind it. On the other hand, I could spend hours discussing why two societies develop different moral norms, or why two people interpret the same event in completely opposite ways, or imagining alternative scenarios in which a particular warlord had made one choice rather than another at a certain point in history.

So it is not really complexity itself that puts me off. It is the nature of the complexity.

For a long time, I framed the problem badly by telling myself that I was simply not good with abstract things. But a religion is abstract. So is an ideology. And yet I can spend hours trying to understand them.

The difference lies elsewhere. When I dig into an idea in psychology, sociology, philosophy, or religion, the abstraction almost always leads me back to human beings: why does someone believe this, why do they behave that way, why does one society consider a behavior normal while another does not? However abstract the concept may be, it eventually leads somewhere. It helps me understand behaviors, intentions, values, conflicts, or real societies.

With most technical concepts, I experience something very different. Why should the most stable Docker layers come before the more volatile ones? Because it makes better use of the cache. Why? Because Docker can reuse certain layers as long as they have not been invalidated. And so on. Each answer takes me a little deeper into the way the system works, but at the bottom of that descent, there is still just the system. I do not learn anything about human beings, their behavior, or their beliefs. I simply understand a little better how Docker, or a particular language, or a particular framework works. For some people, that is clearly fascinating, but it has never been fascinating to me.

And that probably explains a lot of things: why I have always known how to build software without ever falling in love with code; why I can learn just enough about a tool to build what I need without feeling any urge to explore the layers underneath; why best practices remain, for me, rules that I apply rather than deeply internalized intuitions. And why, after several years of experience, I still have not become the kind of developer driven by the desire to dissect every system down to the atom.

Ultimately, this is not about deciding whether this approach is good or bad, even if purists would probably find it questionable.

In the end, artificial intelligence did not invent anything about my relationship with technology: it merely accelerated a pattern that was already deeply rooted. Long before LLMs, I was building functional applications by piecing together documentation, tutorials, and software components to reach the result I wanted, without trying to uncover the mysteries under the hood. Frameworks had already prepared me for this by providing their own layers of abstraction and ready-made conventions.

With AI, that distance has simply expanded dramatically. Today, I can formalize a need, let an agent propose and implement a solution, validate the result, and move forward without mastering every internal mechanism. The approach obviously comes with risks. That is why I cross-check agents and models, particularly during code reviews, in order to identify blind spots in the first draft, which happens regularly. But for now, the reality is simple: this method works. I do not need to dissect everything in order to ship.

And if my role ultimately consists more in designing, orchestrating, and delivering than in dissecting the invisible infrastructure of systems, is that really a problem?