index.md 5.5KB
title: Notes from “An approach to computing and sustainability inspired from permaculture” by Devine LuLinvega
url: https://blog.jim-nielsen.com/2024/notes-from-computing-sustainably/
hash_url: 1f40a33f9c
archive_date: 2024-01-15
og_image: https://blog.jim-nielsen.com/assets/img/twitter-card.png
description: Writing about the big beautiful mess that is making things for the world wide web.
favicon: https://blog.jim-nielsen.com/favicon.ico
language: en_US
I am interested in computers as a way to do more than consume.
That’s how Devine starts their talk from Strangeloop. I’ve linked to them before, as they have an interesting perspective on computing in the 21st century (given, in part, their environment of living on a boat).
I liked Devine’s warning about equating newer with better:
If the new software no longer runs on old hardware, it is worse than the old software.
Or this reminder about the flip-side of computers:
We should be careful of who makes the bicycle for your mind.
But there were two things in particular I wanted to write about that stood out to me.
The Value of Absence
The best phrasing I've seen for [defining] elegance is: articulating the value of absence.
It’s easy to fall into the trap of only seeing what is lacking — “This can’t do X” or “If only we added Y” — which, perhaps unknowingly, makes us perceive everything around us as never being enough.
But this idea of being able to “articulate the value of absence” cuts against this natural inclination to always be adding more.
Steve Jobs once said that at Apple they are as proud of the things they haven’t done as the things they have done. They’re proud of their ability to give a million “No”s to the one “Yes”.
And I think this runs in a similar vein. Can you say “no” and articulate why?
Instead of a knee-jerk acceptance of addition, “This would be so much better if we added X!” A good exercise might be to try articulating the value of subtraction, “The absence of X would be beneficial because…”.
As Devine has said elsewhere, “I don't think we've even begun to scratch the surface with what can be done with little.”
Systems That Foster Solutions vs. Knowledge
To give people power over the technology that rules their lives and take them apart is extremely important if you want to have a system that goes beyond solutions and includes knowledge.
I think that statement becomes more profound the longer you ponder on it.
So many software and hardware services encourage dependency through their solutions — they give you a fish, but don’t teach you how to fish. Devine’s illustration of this idea through the analogy of tap water is interesting.
When you’re getting water out of a tap and cannot see the source (for example in your home) it produces a sense that there is an unlimited amount that can come out.
Contrast that with a tap hooked up to water tanks that are visible each time you get water (for example, on boat). Every time you get more water, you see the tanks drop and you are reminded how much is left. Behavior changes when usage produces immediate, noticeable consequences.
So many companies have made a business out of deliberating hiding limitations, which alters behavior and usage.
This insight seems to come from Devine’s experience of living on a sailboat, which is an environment that is constantly imposing limitations.
For example, Devine notes that on a boat you have a limited supply of power. When you can’t do something on a boat because you don’t have the power, people’s natural inclination is to respond, “Well then just add more power”. Devine notes that is a possibility, but there’s a tradeoff: it produces more weight on the boat which means (for example) that it will be harder to outrun storms and they’ll therefore need more power to move the boat at the same speed as before. There’s a balance to it all.
Going back to the original quote, the insight here (I think) is: systems that preserve transparency into the mechanisms of their inner workings encourage more mindful, deliberate use based in reality because people develop knowledge through use. (This stands in contrast to a system whose inner workings are opaque and therefore antithetical to developing knowledge because they reveal no seams to their true nature.)
I think there’s a parallel here to the abstractions we use in software (like web frameworks) and how they choose to reveal their own inner workings (or not). But I will leave that as an exercise for the reader — and myself, perhaps in another post.