Things you can do with codebases

It's easy to forget that we're surrounded by millions and millions of lines of code that we can access and build and run and modify and tweak — whenever and however we want.

Maybe we forget because open source has become the new normal? Or maybe because we all have some public repositories and don’t think much about it? Or maybe — and this is the one I’m putting my money on — it’s because we never stop to think about how amazing that really is?

So let’s let that sink in together: there are over 200 million public repositories on GitHub, ready to be cloned, just there for the taking and tweaking.

And yet what most of us think of to do with all that code is reasonable, sane, grown-up, mature: fixing bugs, adding features, cleaning up documentation, helping out in the issue tracker.

But — isn’t a But a beautiful thing sometimes? — here’s a thought: there are millions, billions of lines of code available to play with and you can do whatever the hell you want with them.

Here are some suggestions:

• Check out the first commit. See what the project was like as a baby. Here is Redis at its first commit. Nine C files in the root directory. A very clean, nicely commented Hash Table implementation in slightly more than 500 lines. It’s grown to 2000 lines now.

• Put log statements in, run it and see what it actually does. I mean, why not quadtruple the amount of log statements in TigerBeetle’s state machine and see what it does? That sounds like a nice morning.

• Break it. Again: why not? How hard could it be to modify PostgreSQL to never write to disk again? What would you learn in the attempt?

• Cut it apart. One of my favorite things to do when debugging: taking a codebase and deleting everything that I don’t think is relevant to the bug. You learn quite a lot about a project’s structure when deleting folder after foldering and trying to get it to run again. Can you, for example, take Go and delete the code for all of the architectures on which you don’t want to run it?

• Copy out parts and see how they tie in with the rest of the system. Take Redis again: can you simply copy out the Hash Table implementation and run it in your own main.c file?

• Change constants. Hardcode values in it. That’s how I started programming in school when I was 12 years old: we played around with JavaScript and DHTML and this code that generated some floating balls following the mouse cursor, as if they were elastic. I had a big lightbulb-moment when I changed some constants in the code and realised how they affect distance, width, height, and elasticity. (I think it might actually have been this code, but 25 years ago. I should try to get it to run again.)

• Remove all the features you aren’t interested in. Can you delete all the graphs you aren’t interested in from stats and still have it run okay? How much faster can you make something start up if you remove all the things you never use?

• Print it out.

The Meta-Circular Evaluator from Structure and Interpretation of Computer Programs, printed out, sitting on a shelf here in this room.

Joy & Curiosity

This is a new section of Register Spill that I want to experiment with, true to the original idea of this newsletter containing “what I’d send you if you were to ask me what’s on my mind this week.“ In this section I want to share things from the previous week I find interesting.

• Came across the vim-sneak README this week, thought “why not use / in Vim to navigate?”, and had to laugh out loud when this was addressed in the README with: “/ab<cr> requires 33% more keystrokes than sab” — That’s fair.

• I keep thinking of this HackerNews comment in a thread about advice and why advice doesn’t work. I’ve also thought a lot about the general idea of “advice” in the past few years and how hard it is to give advice and how many lessons are tied to the context from which they come. I thought this comment about storytelling being a replacement for advice and how “stories are essentially beneficial viruses” was very interesting.

• Patrick forward this to me: The Five Year Rule of Software Transitions. The part about VS Code and text editors stuck out. “Atom was known as being slow, and VS Code has a reputation of being snappy in comparison.”

• After seeing GitHub announcing Github Models I’m now idly wondering whether we're entering the phase of AI in which it's becoming clear that models are a commodity.

• I’m a big fan of Dan John and his thoughtfulness. I tried to find a quote of his about the best workout being the one you can repeat every day, not the all-out workout that leaves you hurt for days. Couldn’t find it. Instead found this interview with him that contains this precious line: “There was always someone else who was far better than me, but they didn’t show up".”

• I love using HandBrake and especially this little detail.

• Everbody had something to say about the Friend.com announcement this week and, as often, I don’t think I have a fully-formed opinion yet. It does look dystopian. And yet I started to wonder: what could you do with an “assistant” that can interrupt your thoughts? I’ve read Don't feed the monkey mind earlier this year and one big idea in it is to try to break bad patterns your mind falls into. When you catch yourself going back to the same thoughts, you need to stop the cycle. Now I’m wondering: could something like the Friend.com thing help you stop your thoughts? Could it message you after listening in to a conversation with your boss, saying, “hey, don’t overthink this, I know you assume that what he said about X, Y, Z and is about you, but it’s not.” Again: not sure what my opinion will be (if I will have any), but I sure wish I could re-program my thought patterns sometimes.

• This horror story in the form of a HackerNews comment. Pow: “The solution was obvious: installing Visual Studio for each customer on site and teaching the users to run the app in debug mode from Visual Studio” And bang: “What happened next was even worse.”