+1 for 'A Philosophy of Software Design.' I read that book a while ago and really liked his views on a lot of things. Off the top of my head some of them are: complexity being the greatest enemy of software engineers, the importance of strategic programming (as opposed to tacit 'somehow-get-the-job-done' programming), general-purpose abstractions, and having deep modules exposed through simple interfaces.

+1 One of the only books on design which actually is backed up by data.

I had been misled by the Ruby ecosystem earlier in my career to do clean code + refactoring + tdd and this book + actually looking at complex systems such as games made me realize that coding is not about abstractions but it is about data and what the computer needs to do.

In your view, what word(s) would you use to describe the following?

"a carefully designed API for interacting with piece of data which provides both a consistent technical interface and conceptual understanding of the meaning of said thing"

The reason I ask is because the word I've always used for that is "abstraction", but I'm getting the sense that over-abstracted and over-architected frameworks has soured many people to the word. I want to communicate the idea without conjuring up images of java classes with 90 character names. What would you recommend?

You are absolutely right. In that sense the right abstraction is what one should go after.

But what I mean is the more popular Java / OOP style abstractions like a repository which returns a builder which returns class which you new up and pass to some sort of super interface and its just such a mess.

As a technology I really like the JVM and hotspot but good Lord if I have to wade through 10 different things to get there.

Finally to answer your question I have started using the actual name of the thing in the language I'm using. Such as a "struct" in c and rust which I mostly use these days.

Also, a co-author of the Raft consensus algorithm.