When a thing looks like reuse or abstraction because it implicitly pulls in something else in a coupling way, it's really about exploiting shared context in a way that allows the new definition to be much briefer than it otherwise would have been. However, it still relies on full knowledge of the context, so in terms of conceptual load, there's no difference.

Just as with other types of compression, the shared context becomes the global coupling across definitions.

Take relational databases.

The relational model is a fantastic abstraction that revolutionized data storage and allowed databases to become vastly more powerful than they were prior to the introduction of the model. But it also couples the data representation to a model that's based on sets of tuples, which is a bit of a mixed blessing. It's necessary for the algebra that makes relational databases so flexible, but it also means that the RDBMS's native data format is fundamentally incompatible with how most application programming languages like to organize things, thus creating the need for a translation layer (read: API) to bridge the gap. That is, strictly speaking, a lot of extra work compared to using something like Gemstone, but I tend to think that it's a fair trade in large systems.

On the other hand, object/relational mapping often drives me nuts, because it introduces the wrong kinds of abstractions. It encourages tight coupling of the database's schema to the data model of the portion of the application that the person who created the table was working on at the time. This reduces the flexibility of the database, and may make it more difficult to predict or control the scope of impact of a schema change. Other methods like sprocs certainly have their problems, but at least they were trying to place the abstraction in a sensible place that doesn't create the kinds of couplings that make an application resistant to change.

Also, Brooks paper is still true, the only real, significant productivity boost is reusing existing code. Even if you rewrite everything from scratch, you will still have to carry the exact same amount of essential complexity. Managing complexity is pretty much the most important part of CS.

Like microservices, I feel code abstractions should be thought in a similar way, mostly a thing we use in our team, not company wide

In my own team I have to fight very hard to keep dependencies to external code down, the amount of entangling people are willing to put their code through is just crazy. An argument I often put is: "Why should we use lib X from team Y from my company if they don't even feel it is good enough to open source?". Any external code that my team imports into our project should be good enough it could be open sourced (given IP-rights allowing)

Somewhat tangential, but I sense tacitly related... I sometimes sense that many people who program adhere to a kind of computational atomism, that there is some kind of underlying "real" and that everything else is "just" some kind of arrangement of elements of the real. But that's just an implementation detail. Yes, when we implement a language that compiles to instructions or bits on a specific machine, we are indeed working to simulate that language. But computation and formal languages don't really have anything to do with physical computers. Their connection is entirely incidental. It is a matter of practicality, like the choice of using a hammer versus a rock to drive spikes of metal through wood. A computer language is the "base" language. From the formal perspective, there is no "low-level" or "high-level" language, just different languages that compilers can translate between. What is "low-level" (typically the target language) is merely low-level by convention, usually because we are targeting a given machine instruction set of some physical machine.

But even here, the notion of an "instruction" or a "bit" are abstractions. There are no "bits" in the world as ontological entities. Computation and data are abstract, full stop. All physical implementations are simply instruments for simulating that abstract model. There is no difference, in principle, between using checker pieces, differences in voltage, magnetic polarity, or thumbs up/thumbs down to represent bits.

The language should, ideally, be suited to the domain of discourse.

Perhaps someone should write a book for managers that explains these two things.

Or, perhaps this is a better way of putting it: if there's business logic mixed into it, it's not an abstraction, it's a concretion.

    IHelloWorldString helloWorldString = helloWorld.getHelloWorld();
    IPrintStrategy printStrategy = helloWorld.getPrintStrategy();
    IStatusCode code = helloWorld.print(printStrategy, helloWorldString);

I also think it depends on the type of ORM. Active Record? Really problematic except for simple use cases but because they make those simple cases easy they get popular on that basis. Data Mapper? Actually fine and very useful, but harder to write well and a bit harder to use.

How else would you update this record, plus 10 other record pointing to it? That’s the point of ORMs, “writing” the boilerplate SQL for you, and also the other direction, mapping records to objects.

It’s not the tools problem that people refuse to learn new things and misuse it.

I don't think there is any truth at all to this personal belief. In some domains it's unthinkable to use anything other than the standard ORM. In C# you'd need to be nuts to roll SQL by hand instead of using Entity Framework, and Django speaks for itself.

The only drawback of ORMs is that their promise is that developers don't need to learn the intricacies of SQL and SQL-related design patterns, but in practice developers need to learn the intricacies of SQL, the ORM framework, and the SQL generated by the ORM. Naive developers might believe they are better off reinventing the wheel with ad-hoc SQL stuff, but that's another problem.

Probably because this isn't an advanced book on Software Engineering, but an introductory book to programming.