TinkerWare

A few years ago, I started to dabble with Scratch with my oldest son. Scratch is a visual programming environment that has a nice and low barrier to entry. You visit a web site and start dragging and dropping blocks around, hit a Run button to instantly see your changes come to live. Nice.

However, there are limitations, and ultimately my son was eager to progress to “real” programming. Game programming in fact, so a year ago or so I bought him a book “Coding games in Python.”

This was a bit of a bumpy ride. Python is a relatively accessible language, but there’s a lot of accidental complexity that comes along with it.

First of all, programs are now written in plain text, not visual blocks you can drag around with your fingers or mouse. A lot of things, like indentation, type of brackets, and commas, now all of a sudden start to matter. Images used in the games need to be drawn in some separate graphics application, or downloaded somewhere and extracted from zip files in some specific location. Of course, I wanted to set up my son for ultimate nerd success, so I decided to immediately get him started using Vim. Just kidding.

That’s a lot of added complexity compared to just opening a browser and start dragging blocks, as he did in Scratch. I saw his enthusiasm wither.

Then, a month ago or so I came across PICO-8. PICO-8 touts itself as a “fantasy console”, essentially a purposefully designed retro game development and runtime that you can run on effectively any modern laptop device. In addition, the games you create can be exported to web apps and play reasonably on mobile phones that way. And if you happen to have a Miyoo Mini+ (our kids’ birthday present this year) — PICO-8 games probably play on this best, in this portable form-factor with physical buttons.

PICO-8 is a fully integrated development environment. There’s a simple code editor where you write code in Lua. There’s a tile editor, a map editor, a sound editor and a music editor. All just a tab away. You make a change in any of the areas of your game, press Ctrl-r and go. Instant results. It’s a delightful experience.

As turns out, there’s quite a large community of PICO-8 enthusiasts out there, and some of them record elaborate courses on how to build quite impressive games step by step.

Lua was a new programming language to me. I had seen bits and pieces, and I knew it was commonly used as an embedded programming language, quite popular particularly in the game industry. This was the first time that I ever had to write any myself. It was shockingly easy to do so. Lua is an simple language to learn (I’d say if you know any other language, you’d learn the basics in an hour), but has a few nice fancy features that make it quite powerful (such as meta tables). There are a few quirks, sure (the most offensive one to me is that arrays start at 1, not 0), but overall it’s just a nice, accessible, simple general purpose programming language.

After spending a few hours writing PICO-8 and Lua code in preparation of doing some things with my son, I felt like I was on fire. I got so much done, instant gratification, pure enjoyment.

What was going on? Something felt off...

I realized my decades long software engineering training had kicked in, triggering me to ask all the standard questions:

Will this system scale? Why are people using global variables left and right, and not seem concerned? How do I write tests? How do I do quality control? How do I modularize my code? Should I extract this into a library? Is there an ecosystem of distributing those libraries? How would I build a CI pipeline for this? Are there documentation tools? How do I check this code into Git?

And then it hit me: it doesn’t matter.

PICO-8 is intentionally limited. It’s artificially limiting many things: it’s limiting how much screen estate you get (128x128 pixels), how much memory you have available and even the total code size. You cannot build massive systems in this. And that’s fine. In fact, that’s part of the fun, and it relieves you from worrying about all the large-scale, long term engineering thinking.

Chill.

PICO-8 is a place where you tinker with stuff. Just enjoy. Learn, and don’t worry too much about the maintenance cost of the stuff you build today. It won’t last that long.

As with anything, there are exceptions. It does happen that a PICO creation has so much potential that it leads to a production grade, commercially successful game. And in those cases you have to rebuild large chunks of it. But those are excesses, not the norm. It’s not what the environment is optimized for.

Then I realized: PICO-8 is not unique in this sense. There’s a whole class of communities and environments catering to this style of development. And unknowingly, I had built one of them myself.

Arduino and Raspberry Pi give you cheap, limited computer boards to play with, to wire up to various accessories and just... tinker.

Want to try and run your own web server? VPN? FTP? Sure! Kubernetes cluster? Go ahead, YOLO!

A few years ago I first came across the “self hosted” community — which takes pride in running their (web) services on their own hardware at home, rather than relying on the public cloud and big tech companies like Google and Facebook.

For some, this comes from a philosophical place: “We are giving too much of our data to Big Tech,” they say, “and we need to learn to become more self sovereign.” One way to do that is to host more of your stuff yourself. I can appreciate this sentiment.

For others, self hosting is primarily a great way to tinker and to better understand how technology really works. If you deploy your code in a docker container or a lambda, on a platform like Vercel or AWS, you quickly lose connection with how things really work under the hood. Self hosting gives you some of that transparency back. How does Linux work? How do containers work? How does networking work? How does load balancing work? How does fail-over work? How do backups (not) work? Setting this all up in your home environment teaches you all of this and is a (relatively) safe way to gain this knowledge and experience.

Should you build production systems this way? Depending on your definition of “production”, I’d say this is questionable (I regret self hosting every time the power goes out at our home, and I’m fearful of the time one of my drives fails).

But that’s OK. There’s valuable in just having a place to tinker.

For the last two and a half year I’ve been working on SilverBullet.

SilverBullet is an open-source, self-hosted, web-based personal knowledge management system (fancy talk for “a notes app”) that has some features that should appeal to a more technical audience. Specifically, as I have recently realized, a tinkerer audience.

In SilverBullet, notes are kept on disk as plain markdown files, but can be annotated with metadata. Content is indexed in various ways, and this indexed content can subsequently be queried and be presented in interesting ways.

While SilverBullet could be extended by its users from day 1, the barrier to entry to do so was always relatively high. It involves creating a repository, writing code, building that code, copying some files around etc.

However, about half a year ago I added one (seemingly) little feature called Space Script that quite dramatically lowered the barrier to tinker even more.

Space Script allows users to extend SilverBullet itself simply by adding a block of JavaScript somewhere in their notes. No need to create a project, no need to build anything. Just write, or copy & paste some code, run a command and you get results instantly.

While I didn’t think much of it at the time (and actually there’s some serious issues to be addressed in its design), this is a feature that seems to have unlocked a lot of creativity. SilverBullet was always a great environment to tinker with your notes/knowledge, yet Space Script brought it to the next level.

To be blunt: many space scripts are a hack. There’s no testing other than “it works on my machine.” There is no style guide, documentation best practices, nor testing framework. It will likely not scale. This still makes my engineering senses nervous.

But it’s fine. Let me retroactively claim that this is by design.

It scratches an itch. It’s educational. It’s empowering. It’s fun.

It’s TinkerWare.