The new year is here and I have some time to experiment. It has been a while since I had the opportunity to explore new technologies and build something. I have a few ideas what to do and what to learn, but I still need to figure out the details.
I have been thinking a lot about the problems that excite me while brainstorming what I want to build. As a software developer, I like building products for other developers. It's a space I know well, and I enjoy designing good developer experiences.
A topic that has interested me for years, but which I haven't pursued in a while, is entrepreneurship. As I am thinking about problems, I want to make sure that any solution has the potential to be monetized. This would allow me to learn some totally new skills, and help me maintain the project for a longer time. Maybe even full-time. 🤞
On a technical level, I am excited about Rust and I want to learn React. I have worked mostly as a backend and DevOps developer, and am interested in practicing frontend development. As a former Rails developer, I am also very curious about the changes that landed in Rails 6 and 7.
The biggest challenge for me is keeping the scope small. The ideas I have tend to grow into very ambitious projects that would need months of not years to fully realize. I often lose interest in the projects before they are finished, because it takes too long to see any value. I have zero doubts that I will make the same mistake again, though.
In the past years, I have been exploring three different ideas with varying degrees of success. But I have been coming back to all of them, because there is something about them that intrigues me.
An idea that I have been working on one-and-off for a while now is automating certain tasks in a Git repository. Specifically, I want an easy way to maintain templates for configuration files, CI workflows, and other developer tooling. Whenever I update one of them, I want the file to be updated in all repositories automatically.
There is some prior art that implements this on GitHub using Actions, but copying files between repositories with Actions feels awkward for various reasons. A GitHub App would provide a much better user experience.
I am doubtful that this feature alone would be enough for a convincing value proposition. But while playing with the idea, I noticed that it is possible to abstract it into a more general concept. What I want to do is catch a trigger (a file has been updated), check one or more conditions (on the default branch?), and then perform an action (copy the file to another repository). This loop of trigger, condition, and action can be used for other workflows as well. For example, auto-merging pull requests or closing issues when certain conditions are met.
Every year I have to file taxes, and every year I am missing some documents that I need to do so. And I have some anxiety that I am not archiving important documents for the future. Who knows what I need to have ready in 60 years to get my pension?
The second idea is thus an app that helps organize files on the local machine. The idea is quite simple: A directory is a library with many indicies. When a document is added to the library, it is copied into an archive and then linked into every index. Each index has rules that organize the documents in it. For example, one index might sort files by year and another by file type. This might look like this:
library ├── .archive │ └── day-1.md ├── by type │ └── md │ └── day-1.md └── by year └── 2022 └── day-1.md
This is a project that is ideally suited for a CLI in Rust, maybe with a React-based desktop app that calls either the CLI or a shared library.
There are also some interesting features that could help users manage their files. For example, identifying documents that are added on a regular cadence such as payslips, and warning the user if any are missing. But even with such features, I am again very doubtful about the value proposition and the ability to monetizate the app.
I have been writing about this idea a bunch last year, but none of my experiments came to fruition yet. Either the scope was too big, the architecture too complex, or probably both.
It is again a simple idea: I like programming, but miss more engaging ways to learn new concepts or programming languages. I don't like doing courses, because they are often aimed at beginners (I don't need yet another introduction to variables and functions). At the same time, I also enjoy videogames and admire the feedback loops they have. Putting both together, I think it could be great fun to have sandbox-style games with which players can practice programming.
What has been challenging in the past is creating a nice API for players that integrates well with the engine running the game. As a novice to game development, there are just too many unknowns to hit the nail on the head on the first try. I would have to build a few small games to learn, but those cannot be monetized. Even worse, the market is very saturated and monetizing games is difficult enough as it is.
There are more ideas that I thought about or for which I registered domains and created repositories. But many of them are related to one of the three projects above, and can only be great if they are extracted from them.
For example, a GitHub Action that can easily be customized to validate configuration files. I want to have this functionality every time that I think about creating either a GitHub Action or a GitHub App. But without having something in production to validate the value proposition, it is way too easy to build something that doesn't solve an actual issue.
I am leaning towards working on the Git automation idea. I know the problem from first-hand experience, and am fairly confident in the proposed solution. And judging by the amount of GitHub Actions in the marketplace that automate workflows, I am confident that this is a valuable problem to solve.
The runner-up is the video game for programmers. It is a passion project of mine, and I would love for it to exist. But I am afraid that my ambition far exceeds my skills, and that is is not possible for me to make meaningful progress in the time that I have.
The task for the rest of the day is to scope the automation project. The goal is to develop a rough plan for both the technical implementation and the project milestones, and look for any red flags or unknowns that could stop the project. I also want to think about the long-term vision for the project, since it will impact some of the technology decisions.
At the end of the day, I want to have an initial draft for the architecture of the app and a rough outline of the milestones for the coming days.
Day 1, let's go! See you again on day 2.