Every lie we tell incurs a debt to the truth. Sooner or later, that debt is paid.
— Valery Legasov, Chernobyl (HBO)
I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past I will turn the inner eye to see its path.
Where the fear has gone there will be nothing. Only I will remain.
— Bene Gesserit (Dune)
A quarrel had arisen between the Horse and the Stag, so the Horse came to a Hunter to ask his help to take revenge on the Stag. The Hunter agreed, but said: “If you desire to conquer the Stag, you must permit me to place this piece of iron between your jaws, so that I may guide you with these reins, and allow this saddle to be placed upon your back so that I may keep steady upon you as we follow after the enemy.” The Horse agreed to the conditions, and the Hunter soon saddled and bridled him. Then with the aid of the Hunter the Horse soon overcame the Stag, and said to the Hunter: “Now, get off, and remove those things from my mouth and back.”
“Not so fast, friend,” said the Hunter. “I have now got you under bit and spur, and prefer to keep you as you are at present.”
The structure of the program should exactly follow the structure of the problem. Each real world concurrent activity should be mapped onto exactly one concurrent process in our programming language. If there is a 1:1 mapping of the problem onto the program we say that the program is isomorphic to the problem.
It is extremely important that the mapping is exactly 1:1. The reason for this is that it minimizes the conceptual gap between the problem and the solution. If this mapping is not 1:1 the program will quickly degenerate, and become difficult to understand. This degeneration is often observed when non-CO [concurrency-oriented] languages are used to solve concurrent problems. Often the only way to get the program to work is to force several independent activities to be controlled by the same language thread or process. This leads to an inevitable loss of clarity, and makes the programs subject to complex and irreproducible interference errors.
Joe Armstrong, Making reliable distributed systems in the presence of software errors
We believe that privacy is a fundamental human right. No matter what country you live in, that right should be protected in keeping with four essential principles:
First, companies should challenge themselves to de-identify customer data or not collect that data in the first place.
Second, users should always know what data is being collected from them and what it’s being collected for. This is the only way to empower users to decide what collection is legitimate and what isn’t. Anything less is a sham.
Third, companies should recognize that data belongs to users and we should make it easy for people to get a copy of their personal data, as well as correct and delete it.
And fourth, everyone has a right to the security of their data. Security is at the heart of all data privacy and privacy rights.
Technology is capable of doing great things. But it doesn’t want to do great things. It doesn’t want anything. That part takes all of us. We are optimistic about technology’s awesome potential for good — but we know that it won’t happen on its own.
– Tim Cook, October 24, 2018
…we respect and honor the pigness of the pig and the chickenness of the chicken.
Joel Salatin is an innovative farmer / agricultural philosopher(!) who has inspired me personally for quite some time. One of his farming tenets is respecting the inherent nature of the animals and the environment under his care. That resonates with me deeply. And I think it applies to programming.
We need to vigilantly avoid forcing logic against the grain of a language or its associated culture. Instead of asking “can I do this in language X?”, we need to be asking “should I do this in language X?” all along the way.
Because it’s never as simple as just writing logic a new way. Before writing that magical brilliant code in language X derived from paradigm Y, we need to ask ourselves questions like:
- Does the logic mesh with the language’s natural expressivity?
- What is the readability cost?
- What are the context switching costs? Relative to rest of the project codebase? Relative to the rest of an organizational codebase?
- What are the dev onboarding costs in deviating from community expectations?
- Is the approach likely to be sustainable over time? Or will the magical library that makes it all possible flame out quickly?
Design is not just what it looks like and feels like. Design is how it works.