I have been thinking along those lines for a while. I didn't take it quite from the same angle but it boils down to the same idea.<p>For me, each layer of abstraction should roughly correspond to people's roles.<p>In my line of work (finance) it's a little more complicated than what the article states.<p>There are people who specialize in deep computational optimization.<p>There are people who do micro financial models<p>There are people who do macro financial models<p>There are people who do user interfaces<p>There are people who do the piping between all these<p>The ideal to aim for is that each layer of abstraction is cut around those fairly well defined roles. Each person should be able to own their piece of the codebase and hopefully manipulate objects/languages of the right level for them.<p>In the dishwasher example, the middle layer should be cut in the "electronics layer" and the "hydrolics layer", the electronics layer interfaces with both the user and the hydrolics layer, but the hydrolics layer never interfaces with the user. And it's easy to see that the electronics and the hydrolics are not designed by the same person.<p>It's a way of framing things that makes sense for me.
Author here. I know it's a bit idealized (just three!), but that's the purpose, to provide a simple sense of direction as we try to create better abstractions or better exist with existing abstractions.<p>I'll update the essay if I learn anything striking while applying the principle in my life and work.
The author admits this is an ideal - to be a bit more pragmatic - I would argue we can reduce problems to one of three failure categories and thus have a solution based upon one of those three.<p>Failures are either expected, unexpected, or unknown. Wear and Tear is expected. Unexpected failures are physical damage or misuse. The unknown failure won't report a failure nor be predictable.<p>Code readability does not apply to user level. The user is concerned about error messages - these should be written in a way that is understandable to the human.<p>http for example has 3 digits - easy enough as learning 404 is easy.
Microsoft and the 0x000..... is nonsense and useless.<p>Generally problems exist in three possible realms.<p>Let's use a human infant as an example - one of life's most wonderful creations yet lacks a manual, proper logging, and useful errors yet require a Severity 1 response time.<p>The infant is crying because of one of the three: need, want, unknown. If the kid is clean, fed, rested - move onto want. If the child isn't bored or able to be satisfied, move onto addressing the unknown. This of course takes more effort, inspection, etc. That can be split into wait, advice, and emergency response.<p>With this level of abstraction I have helped new parents with addressing their child's needs. The details are not as important.
I like this approach to thinking about abstractions. It's easy to forget /why/ you are abstracting something, and this gives some perspective and structure to it.
> It is tempting to solve every problem we encounter with an abstraction of the layer<p>It is also tempting to make up arbitrary rules that make no sense and only work in one blogger's very specific thought bubble.
I think I like the idea. This is easily stated as having different framings, though? Similarly, I could ask what makes this different from "affordances, features, and constraints?"
I think all programmers should try to be a bit like business analysts where they can. Often the organization will prevent you having the require information to do this. They have already decided what you are going to build. But if you get a chance to talk to end users it can make you more empathetic.<p>I think this was a tenet of "agile" that the suits haven't really pushed hard on (they like the sprints and pseudo-work-tracking aspects, such as how many points did we crush this err.... quarter).
I figure we want a kind of split-level economy:<p>The primary layer would be basically what this article calls the "Nature layer" and it involves using our science and technology to meet a minimum Standard of Living for everybody in an ecologically harmonious way.<p>Then on top of that I imagine we would have a kaleidoscope of creativity and production, a cornucopia of art and fashion and food and all the things that make it so epic and wonderful to be a human being.<p>I think the "Middle layer" will be largely subsumed under automation, to the extent that it's not an art or craft.<p>What we are seeing with the advent of AI etc. is that the ultimate question is "What is good?" or in other words, "What are People For?"<p>(Cf. Wendell Berry: "What are People For?" <a href="https://openlibrary.org/books" rel="nofollow noreferrer">https://openlibrary.org/books</a> )/OL27154477M/What_are_people_for
I think what we desparately need is a way to move between abstraction layers easily.<p>For example, right now, when you pick a framework, you're kinda stuck with it. Even if you could in theory move to a lower abstraction layer (by modifying the framework's source code itself), nobody does this in practice. So you're kinda locked into that layer of abstraction.<p>Imagine how amazing it would be if it didn't matter what level of abstraction you start on. You could seamlessly move between layers and modify wherever seems reasonable.<p>I don't yet see how we could achieve this. But I think this would require abandoning our current notion of abstraction entirely, or at least introducing some major constraints on it.<p>If anyone has any thoughts on this at all, I'd love to hear them.
I try to consider "general concerns" rather than "layers of abstraction" when designing and implementing systems, especially in teams. These concerns vary by project but always include the constraints of physics and humans. All other concerns emerge.