You know, there’s a chapter in the Pragmatic Programmer that is called something like, you don’t know the requirements beforehand, you don’t know what the customer wants, but in the process of writing the code, figuring it out, in the process of talking, you figure it out. Just like, you write something down to figure out what you want to write, because you don’t know beforehand. And I think that GitHub supports you to do that, and GitHub issues, more specifically.

When you create repo after repo, and you revisit some of these repos, you look at the code, you look at the readme’s, and then suddenly there’s like, something you notice about the code. Something looks off, or something could be added, or you have to delete something, you open an issue, and you start writing about it, putting it into words. And I think that this act of making something, revisiting it, building on it, fixing it, and just doing it again, and again, and again, helps you to figure out what you want to build. And it also encourages you to actually build something you want to revisit, because you actually use it, you like interacting with it, it’s enjoyable. I have a bunch of repos on GitHub that I created at some point, but I never revisited again, right? So, it’s like, okay, you’re making a house here, you’re making a home, and you want to design, you want to make it feel homey and cozy, because you want to sit in that, you want to live there. And I feel like GitHub repos should feel the same way, like you want to interact with this program again, right? So, yeah, that’s what I’ve done with some of my programs. And also, Git allows you to undo things, so whenever you commit something, and later on you realize “oh, no, that was a mistake, I want to go back to the previous version”, you still can do it. Feel free to make mistakes!

For example, yesterday I wrote a small program to compute the most visited domains. I exported my browser history, and then I asked Claude to code up something to get some stats on it. And today, I stepped over it, and today I looked again at the code, and I realized, oh man, it’s 140 lines of garbage Python code that I don’t want to read because it looks so messy and ugly. And then I remembered, wait a minute, this is a SQLite database. And I remember Simon Willison built, literally built a library called Datasette that is specifically tailored to processing SQLite databases. So, why not use this library? And I did. I asked perplexity whether there is a function that allows me to do that, and there is a query that allows you to do it. And it’s only 18 lines long! I literally could solve the problem in 18 lines of code instead of the 140 lines that were unreadable. And I did that, and it worked flawlessly.

So, what’s the lesson? I think that you as a human still have to put in the work of framing the problem correctly. Okay. And then AI can give you an answer if your problem is properly worded. But I only realized this after I made the bad version, after I poured out the shitty ideas. So, just start many repos, start new directories, work on stuff, and we’ll figure out the desired paths, which repos you’ll actually revisit, which programs you’ll actually mention again. Because you can also cross-reference issues and repos across repos. So, that kind of allows you to track, okay, what do I actually care about? And I can’t lie to myself about it, because the repos that I forget are the ones that I actually don’t care about. I only thought that they were interesting in the moment, but they weren’t interesting enough for me to revisit. Time is a good bullshit detector.