What interests you when you read an article or a book about an architecture of some big system, or about new frameworks, or design patterns, or some new fancy tools?
To me, the most interesting thing is why they did it like they describe.
I usually read quite briefly the part where they tell you what exactly they did. I scroll down the part with a description of particular settings in the new tool. I skip the list of specific technologies. I briefly look through the description of the setup.
But I always pay the closest attention to the reasoning. Why did the authors use “this” framework, library, tool, or approach, and not “that” one? What problems did they try to solve?
Sometimes you just want to say: “that” is the best right now, it’s the newest thing in the world, it’s immensely popular. Do they not pay attention to the latest trends? Why they don’t follow the fashion? Everyone knows “that” is superior!
But there’s always a reason for using “this“. There are requirements, limits, and problems behind the final solution. The path the authors followed, the way they thought when solving the problem – this is the most important and interesting thing to me.
Sometimes, the authors have tried “that” and found a problem. Sometimes, “that” is perfect for its job, but just not suitable enough for a different task. And sometimes, “that” just didn’t exist at the time when the authors were creating their system.
Now, “this” might not be perfect. But it fits better, if you take into account their situation: business needs, requirements, available resources, finances, time, risks.
This reasoning part always has the most condensed experience in the whole article or book, and it is what I am most willing to learn about.
Technology changes, new tools and frameworks come and go, hypes rise and fall. But the general ideas stay.