For a couple weeks now I've been commuting to a coworking space instead of just working from home, which has given me a chance to finally give podcasts a try. I'm late to the boat I know, but I remain a podcast skeptic 1.
Thus far I've just been binging Jonathon Blow interviews. If you don't know Jonathon Blow, he's the designer of The Witness, my favorite game, and he has opinions. I'd say pretty well earned ones, which is why I'm more than happy to sit through almost three hours of him on the On the Metal podcast 2.
Jonathon talks about different computer's he'd built games for over his careers, and the ways the architecture impacted the software. If you're at all interested in this sort of thing, give it a listen. One of Blow's long running points is that most software is bad, and our software "stacks" are especially rotten.
"On the metal" is a side of computing I rarely get to experience, working on blockchain and web things as I do. I talked about it this in the first edition of this newsletter. I work at a "high" level, separate from the implementation details of the metal my code is running on. The podcast episode has a lot of flak for developers like me3, and honestly it's somewhat deserved. But at the same time (and this is a point they acknowledge) there are things I can do working at a high level that I just can't if I try to make things simpler. It cuts both ways.
But regardless of what level you're working on, it's hard to make good software. So I read "Why Software is Slow and Shitty" from Pirijian, the creator of an absolutely delightful piece of software, Kinopio (and also the co-creator of glitch) with great interest. Kinopio is a a delight to use, seriously, try it out if you're in need of a simple flexible mind-mapping tool.
Anyways the core point of the essay is that the main impediment to fast and not shitty software is the way software companies are organized. I think I disagree. That's certainly a major impediment, but
Interestingly, Pirjan uses Super Mario 64 as an example of somewhere where different organization leads to better outcomes.
You might think that Mario 64 was built with tickets and sprints, but, according to interviews, there was no master plan, only the principles that the game should feel good and be fun. They started with just Mario in a small room, and tuned his animations and physics until he felt nice and responsive. After that, the levels were also created as they went, with the designers, developers, and director going back and forth using sketches and prototypes.
It seems kind of crazy to me that games are the ones pushing the vanguard of computing so much (look at the GPU's evolution from gaming hardware to the driver of Deep Learning ). Part of this, I think, is that the basic building blocks of games (things like images, sounds, decision trees) have always been incredibly resource intensive, so developers just needed to care more. But in the "productivity software" space, things are still relatively simple at their core. We're still figuring out how to realllly make the full power of computers work for our minds. It's like we've been riding fixies for the mind.
When I was a kid the only reason I wanted to code was to make games, and then I turned my attention to more "serious" problems. Now I'm looking at all the things game devs do and seriously reconsidering who's doing "serious" work.
P.S: My friend Matthew is just started writing a newsletter as well, covering a weeks worth of media, theatre, film, music, and even those new-fangled sites like YouTube. You should check it out!
subscribe for updates