The five principles outlined in Serenity are very useful technical guidelines for designing complex systems. However, they are not personal principles and have nothing to say about our motivation as human beings for wanting to build out and participate in the Eth2 economic elder game.
We'll turn to Bret Victor to help us think about how we might meaningfully merge our technical practice with a personal principle so as to live response-ably: cultivating both an awareness of that which we must uphold, protect or respond to and the ability to do so with care.
How does this fit into Kernel?¶
This is the kernel of Kernel. Bret won't teach you about decentralized systems; or money, finance and speech; or about what the web means in the context of a networked species.
"This is about a way of living your life which most people don't talk about. As you approach your career, you'll hear about 'following your passion', or 'doing something you love'. This is about something different: finding and following a principle. Something you believe is important and necessary and right and using that to guide what you do."
This is a talk in three parts: Bret describes his own principle, then describes some other people who have lived principled lives, and then uses both previous sections to illustrate how you can find and follow your own principle.
"Bringing ideas into the world is one of the most important things that people do and great ideas - art, stories, inventions and scientific theories - take on lives of their own which give meaning to our lives as people."
Bret is primarily concerned with what sorts of tools provide healthy environments for ideas to grow. Thus, his principle is:
What this means is that, when you're making something and you make a change or a decision, you need to see its effect directly and instantaneously. Nothing should be hidden: creators need to see what they're doing. The first place where this principle is violated is coding.
Specifically, we edit code in a text editor, see what it looks like; then make some changes, compile and run it again and see the effect of that new change. Most of the time is spent working in a text editor blindly, without an immediate connection to the output.
The first step is to link the two together seamlessly in one environment. Then, we can start thinking of ways to change our work other than typing new code. Bret demonstrates this by "dialing" numbers up an down with a simple ctrl + click mechanism, allowing you to explore the space and pick the magnitude which feels best to you artistically, without needing to go through each possible number manually. He demonstrates how this simple change allowed him to discover a means for animating the blossoms he would never have otherwise known about.
So much of creation is discovery. And you can't discover anything if you can't see what you're doing [...] Having an immediate connection allows ideas to surface, and develop, in ways which were not before possible.
There's still a problem though: I have the picture, and I have the code, but I have to maintain the mapping between the two in my head to make sense of things. This time, option + click allows us both to see which line draws what piece of the picture, but also what each pixel in the picture corresponds to in the code. It turns out this is also useful for navigation, allowing us to make changes as quickly as we think of them, which is critical to the creative process.
If you have a process in time, and you want to see changes immediately; you have to map time to space [...] Creators need to be able to see what they're doing. If you're designing something embedded in time, you need to be able to see across time, otherwise you're designing blind.
In the tree example, there is no state: no sense of time or interactivity. Bret shows a platform game which has all the features of the tree example above, but also can be paused at any point and rewound - in this case to adjust the future trajectory of a character's jump so they end up in exactly the right place without unnecessary fuss for the creator.
As I was designing this, I noticed that it's fun to play with gravity. I bet you could make an entire game from that one mechanic. In fact, you could probably make a game from fiddling with any single line of code here as a way of exploring possibly rich mechanics.
Bret talks about binary search and demonstrates how the code for such an algorithm gives no immediate sense of what it does.
You have to 'play computer' and simulate in your head what each line of code will do. To a large extent, the people who we consider to be good software developers are just those people who are good at playing computer. But if we're writing our code on a computer, why are we simulating what a computer would do rather than just having it do it and show us!?
In particular, he uses this example to show how easy and intuitive it is to find different kinds of bugs - both simple ones like having an invalid array index, and non-trivial ones where the range within which we're searching becomes distorted and never returns anything usable. That is, this is "what it looks like to write an algorithm without a blindfold on."
Our current conception of what a program is - a list of textual definitions that you hand to a compiler - is derived from languages made in the 1950's when we were still using punch-cards. None of these languages, or the machines they ran on, were interactive - and this assumption is still with us today, even though the media has changed drastically. People still thinks REPLs are "interactive programming" because that was the best you could do on a teletype!
We can demonstrate with programming and software, but the principle itself has to do with any kind of creation. Bret shows an electric circuit to illustrate the breadth of what he has in mind.
In electric circuit design, we are mostly interested in the data associated with the variables, and yet traditional tools and environments confine us to static representations we must then simulate in our heads. He uses this to present the two golden rules of information design:
- Show the data.
- Show comparisons.
Here's the really mind-blowing piece: instead of the representation of a circuit being made out of "little squiggly symbols", it is made out of data. The symbols exist because they were appropriate for the medium of pencil and paper, but when you have a new medium, you have to rethink your representations to give creators more immediate connections to what they are creating.
The last example he provides is entirely outside the field of engineering, in order to demonstrate the generality of this principle. Bret shows how animation can be handled in a far more elegant way than Flash. It's really worth just watching yourself. Go to 30:50 to see it unfold.
💡 Immediate connection is the fertilizer we need to grow gardens of great ideas.
When I see a violation of this principle, when I see creators constrained by their tools, their ideas compromised, I don't see that as an opportunity. I'm not excited by finding a problem to solve. I am not in this for the 'joy of making things'. Ideas are very precious to me, and when I see ideas dying, it hurts. I see a tragedy. To me, it feels like a moral wrong. It feels like an injustice, and I feel it is my responsibility to do something.
Not opportunity: responsibility.
Bret is not trying to convince you to take up his principle, but rather to highlight that the words he is using - "responsibility", "injustice", "moral wrong" - aren't the words you generally hear in a technical field. Things in social fields like censorship, gender discrimination, environmental degradation are all recognized as moral wrongs, yet we lack this tenor in our technical creations.
The purpose of this talk is to tell you that activists are not limited to social causes. As a technologist, you can recognize a wrong in the world, you can have a vision for what a better world could be, and you can dedicate yourself to fighting for a principle.
Social activists generally dedicate themselves to a principle by organizing, but you can fight for a principle by inventing.
In the late 70's at Xerox Parc, Larry Tesler and his colleagues thought that personal computing - which was not considered feasible by anyone else - had huge potential to change how people thought and lived. At the time, software interfaces were designed around modes. Vim still famously does this. By pioneering the concept of software user studies, he observed that the complexity of modes was a barrier that many people, even with training, couldn't cross. This was therefore a threat to his dream of personal computers.
He made it his personal mission to get rid of modes and he formed a principle: no person should be trapped in a mode. His slogan was "Don't mode me in!" This principle informed everything he did and he eventually came up with a text editor called Gypsy which was the beginning of text editors as we know them today.
This was a transformative change in allowing people to connect with computers. His ideas about modelessness spread to the rest of the desktop interface and today, are so ingrained in our computers, that we do not notice them [...] So, how can we describe what Larry did? Yes, he 'invented' cut-copy-paste, but this invention is very different to Thomas Edison inventing the phonograph. Edison stumbled over the technology for audio recording and built it out as a novelty, but he didn't have any cultural intent, whereas what Larry did was entirely a reaction to a particular cultural context.
Can you begin to see why we have placed such emphasis on breaking down our culturally conditioned modes of thinking? It's also not entirely accurate to say that Larry "solved the problem" of modeless text manipulation, because nobody else saw it as a problem! For everyone else, modes were just how computers worked - they were a fact of life.
The first thing Larry did was recognize a wrong that was unacknowledged in the culture, which is how many great social changes began too. What Elizabeth Cady Stanton did in championing women's right to vote is a much closer model for what Larry actually did than the Emerson model of invention for the sake of patents. This is not a point of relative impacts, just one of motivation and approach. Both Stanton and Tesler recognized an invisible wrong. envisioned a world without that wrong, and dedicated themselves to fighting for a principle.
This applies to many other seminal figures in the history of computer science. Doug Engelbart (who championed the idea of interactive computing) is best known for inventing the mouse, but he really came up with an entirely new way to work with knowledge. His explicit goal was to enable humankind to to solve the world's urgent problems. He had a vision of knowledge workers using complex, powerful information tools to harness their collective intelligence.
Or Alan Kay, whose goal was "to amplify human reach and bring new ways of thinking to a faltering civilization that desperately needed it." His approach was through children: if programming is a form of basic literacy, then kids will grow up to be adults who have developed new means for critical thought, and we'll have more enlightened societies.
Finally: Richard Stallman, whose work on GNU now makes up a large chunk of any Linux system, and who started the Free Software Foundation, wrote GCC, GCL and many other things, and whose principle is "software must be free, as in freedom".
I'm not saying that you have to live this way, or even that you should. What I am saying is that you can. That this is an option which is available to you, though it is not one which you'll hear about often [...] Instead the world will try and make you define yourself by a skill.
We are conditioned to have a major in college, or a job title in our career. This can be worthwhile, and if you want to spend your life pursuing excellence by practicing a skill, you can do that. That is the path of the craftsmen: the most common path. There's also the path of the problem solver, typified by entrepreneurship or academic research, which is about choosing a problem in a given field, working on it, and making a contribution there.
Or, you can define yourself not by the problem you're solving, nor by your craft, but rather by your cause; by the principle you choose to uphold. This means having a vision and bringing the world to that vision. Be patient: it can take time to find a principle, because it is really a form of self-discovery. You're trying to figure out what your life is supposed to be about.
It took Bret ten years to find his principle. His advice based on those years of wondering is:
Do a lot of things. Make many things. Make many types of things. Study many things. Experience many things. Use all of these experiences as a way of analyzing yourself by asking, 'Does this resonate with me?', "Does this repel me?', 'Do I not care?' Build up this corpus of experiences you care about and then try to make sense of it, try to figure out why you care. What is the secret ingredient in all of these experiences that I am reacting to so strongly?
Confining yourself to practicing just one skill can make it difficult to get the broad range of experience which seems so valuable to doing principled work. Finally, a principle can't just be any old thing you believe in, like "make software simpler". These are nice thoughts, but are too vague to be directly actionable. Larry Tesler liked simplicity, but he had this specific nugget of insight that no person should be trapped in a mode.
If you principle provides you with a specific insight, it will guide you, and you will always know if what you're doing is right.
There are many ways to live your life: that's maybe the most important thing you can realise in life. Every aspect is a choice. But there are default choices. You can choose to sleepwalk through your life and walk the path that's been laid out for you. You can choose to accept the world as it is. But you don't have to. If there is something in the world you feel is wrong, and you a vision for what a better world could be, you can find your guiding principle.