The details don’t matter until they do
Dualities rarely exist in reality. There is no yes and no, on and off, true and false. Almost everything in the world exists in part of a continuum; a sliding scale between two extremes. There is absolute zero and possibly an absolute hot (absolute hot is still up for debate) but there is also an entire range in between. If you can’t see the shades of gray in the topic you are working on then you haven’t looked close enough. But let’s suspend all that continuum talk and focus on a simple duality: abstract and concrete.
Rising levels of abstraction
The most concrete part of computers are the circuitry and the 1s and 0s that make it all work. At the end of the day everything is a 1 or a 0 and the rules of physics and electrical current apply. The further away from that you get the more abstract things can be. When you get high in the ether that is enterprise systems everything has a tendency to become very abstract. The concepts are more about thoughts and ideas made to represent a made up reality. You are building a fantasy land with made up rules (although people take those rules very seriously). And for a while the concrete doesn’t matter. How is data written to disk? Doesn’t matter. We have an abstract idea of a datastore with a save method. Done. And it works. Until it doesn’t. Then the concrete details matter and you damn well better be able to chase the problem down the stack until you can reason about the problem.
It’s an implementation detail
In many cases the implementation details, the concrete implementation, doesn’t matter. Certainly in most business applications they don’t care how it is implemented only that it is and it works (I would say reliably but that is up for debate). When you are designing a large system you start to get an idea what the main pieces are and you can comfortably delay choosing an implementation until you absolutely have to make a choice. You can delay the implementation and the details if you don’t need to be concerned with high performance and mission critical reliability. I’m not talking the “we need the report now” type of mission critical. I’m thinking more along the lines of “rocket two isn’t responding. prepare for crash landing” kind of critical. When you start trying to eek out the most performance possible or uptime and reliability has to be greater than six nines then the concrete matters. Your abstractions break down and how the 1s and 0s move across the physical circuit makes a difference.
It’s a numbers game/Know your abstraction
I personally like programming at a high level of abstraction. The further from the concrete the better. Even when painting I prefer abstract and surrealism to realism. But that’s not for everyone. There is absolutely a place for concrete programming just as there is a demand for realist paintings. The problem I have is that most programmers are too focused on the concrete and too focused on the implementation. Maybe it’s technology infatuation or just a desire to work in a certain level of abstraction. Either way I would argue that 80% of modern business application development is in highly abstracted areas.
In the end you will be happier when you know what level of abstraction is appropriate for the current problem. If you insist on always talking about MRUs and LRUs then don’t be surprised when a business user rolls their eyes and doesn’t trust you. On the other end of the spectrum if are talking in the language the business understands but you system doesn’t perform well then you had better be able to step away from Visio long enough to determine where in your amazing architecture you introduced a bottleneck.
In most cases it’s amazing how little the details of the concrete matter in programming. Unfortunately they won’t matter until it’s critical so ignore them at your own risk.