Programming With Little Free Time via Theorycrafting

The most important part of writing software is ideation. When you have an idea for software, you start with a blank slate of knowledge: you have no idea how you’re going to implement your idea, let alone if it’s even possible. So, you spend a lot of time thinking about the idea, doing research on existing software and libraries you can use, seeing if someone’s done what you need already, et cetera, et cetera. This takes a lot of time, but the great thing about computer science is that you don’t need your PC right in front of you to do this part. Almost all of the resources you need to solve a problem can be found on the internet, a book, or in your internal library of knowledge. In my opinion, this part of software writing is the most important, as it is when your project goes from "hmm, this seems interesting" to "OK, let’s do this!" So, let’s get it out of the way as soon as possible.

When I have an idea for something, I write down the gist of it immediately. Doesn’t matter where, whether it’s in a text file, draft email I plan to send to myself later, or on a piece of paper. The worst thing that can happen to an idea is letting it die in your head before you can write it down.

Now, I begin to sketch out the high-level overview of the software. What does it do, how does it connect to other services, if at all, what protocols or standards are necessary, what language am I writing it in, stuff like that. Just like when I’m brainstorming an essay, I’m not concerned with the nitty gritty or if it’s a good idea yet; after all, I’m still in the process of thinking it through.

Now, comes the most fun part for me: looking stuff up. This is usually most necessary when my idea revolves around stuff that cannot be done with my language’s standard library or I need to interact with external services; this is the case for most of my ideas. I will begin furiously searching for stdlib functions I’ll need, looking for promising third-party libraries on package indexes, and pulling up documentation. I’ll then filter through the links and add the ones that live to my note.

Now, when I actually begin programming the idea, I can quickly get back to where I left off and begin scaffolding the app.

A great public example of me theorycrafting is the issue "Add search engines for torrents". In it, I describe how I should go about implementing a new feature for my app, including the shape of my data structures, what the user experience will be like, what libraries and classes I’ll use, the services I’ll interact with, and even some snippets of code I can copy-paste when I’m implementing the feature.

This issue effectively acts as a one-use template for implementing the feature and now an hour or two I would have spent researching instead of coding has basically been moved somewhere else!

I encourage you to clickthrough to the issue and give it a read, even without the full context of what webtorrent-server does; what one should take away is the structure, not the content. After all, I wrote it in a way which is primarily scrutable to me, and you’ll obviously have your own way of explaining stuff to yourself and likely will differing priorities when feeling out an idea.

I think theorycrafting is a useful framework for being productive even when you can’t immediately act on something. I think the idea has usefulness beyond not just other types of engineering beyond software, but with other areas of study like writing. If there’s one thing you take away from this, it should be that there is a lot more to doing a thing than "just doing the thing;" thinking about doing stuff and researching it allows you you to better refine your idea instead of immediately jumping in, and spend more fully actionable time actually doing the thing.

I did this a lot at school; I had Windows administrator privelges on my Windows laptop so I installed WSL2, Git Bash, Python, and Node.js without pushback and frolicked whenever I had free time and was bored out of my mind doing homework.

The most annoying part of coding like this was getting code off my machine. For the most part, I just emailed myself ZIP files instead of, say, pushing to private GitHub repos. Now that I own the machine completely, I plan to just to set up some sort of sync between my laptop and desktop so I can code away from home.

Sadly, there are places where a laptop is not super appropriate or even available, so this isn’t foolproof. Having a nice 13-inch screen does make theorycrafting a lot easier, though.

In short: the experience sucks. There are a myriad of different issues with programming on one’s telephone, whether it be with a SaaS like Replit or with a shell environment like Termux.

The only editor that has gotten remotely close to solving most of these problems is MobileCode, but it still only supports one language, is not open source, and still runs into screen real estate issues.

What would be best is if we could have a structured text editor where the user manipulated source through an AST built with wizards which then integrated with Termux for shell and language server support, but I know that would be a tall order to build.

I will say that I do occasionally grin and bear it, though. A phone is quite a useful tool for editing a spelling error on a blog post, poking a web app on Replit back to life, or doing a quick cURL.