Principles matter. I’ve believed for a long time that the most important contributions to the world come from being passionate about fixing it, and from having values that guide you. That’s what motivated me to teach swing dancing: I felt that the way I had been taught–even by some really great teachers–was broken, and I wanted to fix it. Some of the ideas that inspired me to change how swing dancing was taught are actually outlined in, of all things, a presentation about software design.
Bret Victor is on a mission to change how people make things with computers. But this talk is about more than that mission: it’s about the importance of discovering the things you care about and the principles or values behind them. It’s about how to find your own mission.
The first part of his talk is about the specifics of his work, where he’s identified a problem that pains him deeply: the gap between thinking about ideas, and seeing them happen in software. His view is that anything that gets between a creator’s idea and seeing that idea happen, is a bad thing.
He demonstrates some really great tools for fixing the delay or disconnect and making the creation of software, animated movies, and even electronics. The funny thing is that I suspect people who aren’t used to programming will look at this video and say, “but wait, isn’t that exactly how you do that?” In a sense his methods are just so much more natural than what programmers usually do that it’s almost strange that we don’t work that way.
I agree with the general principle; in fact the main reason I really got into programming as a kid was that although I really just wanted to create things in hardware with electronics, the idea-implement loop was much tighter in software, especially with interpreted languages. A lot of my early programming was spent taking a tiny part of what I wanted to create–such as the movement of the player in a game–and playing with variables, watching how each change in code affected the result. You can see this in a very clear way in his presentation using tools he’s created.
On the other hand, I disagree with a few of the details. For one thing, the visualization of data should fit the situation: not everything we do in software is about making pretty pictures. In fact today the principle of separating visual design from behaviour means that we already tend to build the visual ideas using similar tools to what he recommends. And to be nitpicky, there’s a reason why some of us still use mode-based editors, and prefer the command line: because telling the computer what to do in quick little commands is a kind of magic, Harry Potter style. Listus folderi! Removo recursiforci! Curligrep!
He loves to talk about how programming languages are based on the limitations of old teletype machines and punch card systems, but it’s not really true: programming languages are based on the human idea of instructions: things like to-do lists, and stage directions, and “how to get to my place from yours.” There’s a reason why, in a world of free videoconferencing available on phones that fit in pockets, we actually use text chatting in about 12 different forms more than we use video chat or even the phone. It’s not that everything should be pictures; it’s that picture things should be pictured.
His talk also neglects a point: that another major key to great creation is that being able to see data in different ways. For example, while working on the same game, you might sometimes benefit from seeing the visual effects, but other times you might benefit more from seeing a readout of values the way he demonstrates for the
Still, there are a few examples that really drive home his point. One is the way that instant feedback actually allows certain kinds of accidental discoveries that wouldn’t be possible otherwise, such as the leaves on the tree. And it seems that his ideas for animation are just the way it ought to be. He makes the point that programmers shouldn’t have to use their brains to simulate a computer when they’re working with a computer right there, and that makes sense; however that doesn’t change the fact that it’s not really about simulating a computer. Actually, computers are based on how we think, or at least how their designers thought about problems. So the people who can “simulate computers in their heads” are actually people who just really get the ideas they’re working on–such as data structures, math, logic, etc. For people who are truly amazing at those things, there’s nothing hard about looking at an array and visualizing what happens with it in a loop.
Where these ideas are really powerful is in the way they enable people with other skills, or more general skills, to be effective at creating without being great programmers. As I watched the video, I thought of the many artistic people I know who would never become traditional programmers, but who I could easily see doing that — doing programming-like creation using purely intuitive tools designed for non-programmers.
- Thanks to Dave for sharing the video (https://vimeo.com/36579366)
- He has other talks posted online but I think this one illustrates his ideas most effectively.
- I use the definitive mode-based editor Vim all the time; writing in Vim has been compared to playing a video game in terms of how enjoyable it makes the experience; but you first have to get over the steep learning curve. Vim isn’t a good first editor, it’s a good last editor.
- Except these are much faster to type in real life:
- ls # List files in this directory/folder
- rm -rf X # Remove X and everything in it
- curl X | grep Y # Show lines from web site X with Y in them