44: Having some fun
I’m having a hard time writing this newsletter because I’ve just been having so much fun hacking on this little prototype. Since one of my goals for this prototype is to make it fun to use, I want to dig a little deeper into what made this hacking enjoyable.
Knowing my tools
I decided to make this prototype with the same stack I use for hyperlink.academy and my personal website: NextJS, Typescript, and Prisma.
It’s a really productive set of tools, and I’ve had enough experience them that I can get right into thinking about the problem I actually want to solve. But, the it still is a new use-case ( a local, data heavy, app ), so it’s exciting to see the same tools in a new context.
Knowing my problem
I set out the problem I wanted to solve last week: Implement links (and also make it pretty, but we’ll leave that one aside for now).
I knew I could start just by copying some code I’d implemented a couple weeks
ago when I was
experimenting with Cloudflare Workers KV, to allow me to hit open links with CTRL-o.
Once that was slotted in, it became just a matter of adding more functionality around links until it matched the end-state I had in my head: both links and backlinks stored in a table in the database, and visible in the app.
Micro-interactions
Starting with the opening link interaction, even in the simplest form, was a lot of fun. It’s something that’s useful, but also concrete and exciting to do. It’s not an abstract benefit, but an explicit action that, if/when I use this prototype in the future, I’ll take thousands of times.
Solutions opening doors
Once I had the basics down there were a bunch of different ways I could extend them.
The first step was just building out an interface for interacting with the links, which made me want to play with the prototype even more. From there I could explore more complex interactions around links, like copying the link to a page easily, or more robust handling of the names of pages changing. Or, I could build out a visualization of links. At every incremental step there were new paths opening up.
Failure opening doors
It works on the flipside too. Because the code-base is so small all the problems in it feel like opportunities for solutions. If I was getting frustrated interacting with some part of the program, I could just stop and improve it. And because of my familiarity with the stack, this kind of refactoring was a breeze. For example, There was a mismatch between the data being returned by different API endpoints. Boring kinda problem, but when I can just quickly branch of and fix it, it’s quite satisfying.
This is to me one of the biggest strengths of test-driven-development (which, to be clear, I’m not actually practicing here yet). It turns every bug into a concrete positive product, that you can actually see and engage with.
Zooming out to the game
All of these things combine into some high-level properties that define the “game” I’m playing:
- I always have multiple options for how to make progress that range from simple-complex, and are relatively non-correlated
- I receive rich feedback when I try to do something
- I have a clear short term goal, but a broad long-term goal
So where do things get not fun? One key area is where experience and expectations get in the way. I’ve spent a lot of time getting good at using “tools for thought” (namely, emacs) and have built up a set of expectations for how they should behave.
When I’m building my own prototype and starting from scratch, I’m constantly aware of those things missing. One of the things that prevented my from actually starting to code today was trying to decide between implementing Vim movements in the text-editor, or implementing what I was actually supposed to be working on, links.
This is perhaps the long-term goal getting in the way of my short term actions. Because this project’s both vague and ambitious, the future holds a ton of different possibilites, all of which seem exciting and important. It’s easy for me to get lost in dreaming about those when I’d actually have a ton more fun working on something concrete today. This is always the case, but I haven’t yet learned to just jump right into making something.
How can this extend?
Part of my intention in listing out where the fun came from today, is in figuring out how to make using the tool I’m making fun. It’s a little disheartning perhaps, because it seems that as much of an impact as the tools I use did have, it was outshadowed by the fun that emerged from the specifics of the code, the project, and my understanding of it.
If I want to generate that with a general purpose tool for thought I have to make it easy to create those conditions for oneself. And I have no clue how to do that.
For now, I can just keep letting what’s fun lead the way! Next, I want to flesh out the interactive aspects of documents, and give them a richer API.
P.S: I’m running another cohort of Internet Homesteading, a course on building a home for yourself on the internet, a website created and maintained with tools you understand. It’s starting tommorow, which may be a bit short notice, but I’d love to have you join! Here’s a code for $50 for being a reader of this newsletter! Writing it really helped me think through a lot of things that worked its way into the course.