I'm a big fan of making small (sometimes silly) programs. As a software developer, you have a superpower: you can identify problems in your life and fix them by creating some specific software that solves for exactly what you need. When scoped small enough, creating these tiny programs takes minimal time investment.
When you develop the practice of recognizing when a bit of software would be helpful, you see opportunities all the time. But you don't control when you get inspiration for these programs. So you come up with strategies for handling these bursts of inspiration.
One strategy: Write yourself a note (paper, email to yourself, some app on your phone) and maybe get around to it later. (You occasionally manage to get around to it later.) Another strategy: Think about the inspiration and trick yourself into thinking you'll remember it later when you're at a computer. You justify this by claiming if you forget it, it must not have been important.
These workflows are fine but they leave a lot of room for never following up. With modern AI tools, we can do better.
My new strategy:
I started using this technique in early summer 2025. Since then, I've been able to develop and iterate on a handful of single-page web applications this way. As models improve, it is getting even easier to knock them out. It works well for either making a new application or tweaking an existing one.
Here is my setup:
With this setup, I'm able to follow the above strategy with minimal friction. If I have an idea for a new little application, I open Codex and provide a description of what I want and what it should be called, and it usually manages to start work on it. When I have an idea for tweaking an application, I open Codex, tell it what subdirectory the app is in and what tweak I want made. All of this can be done from a smartphone.
When Codex is done, I do a quick scan through the diff, click the buttons to open a PR, merge it, wait for the deploy, and then check on the deployed artifacts. The apps end up published at jake.in/experiments.
It isn't all smooth; sometimes a problem is introduced. Depending on the problem, I'll either revert the code and try again or give Codex more instructions and try to have it fix it. If really needed, I'll fire up my laptop and fix it myself or iterate with AI on fixing the problem there.
The bar has been seriously lowered for creating specific software. Go do it. It is fun, but in a different way than traditional programming.
I don't know if this limitation still exists, but when I was initially setting this up my experiments repo had zero commits. This caused problems in Codex that were fixed by adding a single commit.↩
Over the summer, I developed a couple of small, sort of silly programs. One, Photo Fit, is a little tool that runs in a web browser and resizes photos to fit as your phone's background. The other, Default Equipment, runs on Heroku and automates changing the "bike" of my Strava-tracked e-bike rides to be my onewheel.
These weren't created to solve large problems in the world. There is no plan to make any money with them. As of October 2020, Default Equipment doesn't even work for other people (though it could, send me a message if you'd like to use it and I'll get around to it).
Each was created to fix a minor annoyance in my life and, because these tools can live on the Internet, they can fix the same minor annoyance in other lives.
With an increasing amount of software in the world, being able to write software is nearly sorcery1. As a developer, you can identify a problem in the world and then change the world to remove that problem. And, depending on the problem, you can remove it for everyone else.
Software developers aren't alone in being able to identify problems and remove them through creation. Carpenters can build shelves for their books. Cooks can prepare food to remove hunger. You can come up with nearly an infinite number of other examples.
The difference is that a solo developer can solve problems for an unknown number of other folks. This is enabled by the Internet enabled ease of distribution. This is very powerful.
Developers can expose their solution to others through a web application. Desktop or mobile applications can be distributed through various app stores or made available as a download. Source code can be made available for others to run. Being able to distribute easily and cheaply is a game changer.
A developer's change to the world might be a minor improvement. Photo Fit might never be used by anyone besides me. But it is still out there, making the world slightly better. It is available for someone to stumble upon when they are also annoyed by the same problem.
It felt good to write these tiny, useful programs. If you scope them small enough, there is a definitive ending point2. This lets you feel that finishing-a-project satisfaction quickly. The small size also allows you experiment with new techniques and tools without committing to a large and ongoing commitment.
I wrote both Photo Fit and Default Equipment in TypeScript. Before the beginning of summer, I didn't know TypeScript and had little exposure to Node.js. Now I have some experience with both and gained that while making small improvements to my life and potentially the lives of others.
If you haven't developed software to solve a small problem recently, I'd recommend doing it. Don't hesitate to remove a problem that feels silly. Removing those problems can still make your life slightly better and gives you an opportunity to learn. It feels good to remove an annoyance from your life. If you can, make that software available to others so their lives are improved as well. Take advantage of the power of easy distribution to improve the world and not just your tiny slice of it.
This is taken to an extreme in the fantasy series Magic 2.0.↩
Excluding any ongoing maintenance. But if you're making something small enough you can approach near zero ongoing maintenance. One of my longest running solve-my-own-problems application, Book Robot, has been operating for nearly 7 years with minimal effort.↩