Many people suggest pursuing personal projects in their free time 1. Some of these projects can be turned into businesses (but then you need to work on other parts, not only developing the project).
Among these projects, you can also find worthless (in the economic term) ones. These are useful, among other reasons, 1) for having fun 2) for getting away from a work-related mindset 3) for deliberate practice.
Practicing with these projects gives you the opportunity:
- To practice another language, framework, setup, methodology. You are bound only by your rules.
- To get away from business, work, or client pressures. You are the one and only stakeholder, you set the pace, the boundaries, and the completion.
- To put into practice what you have read. No concept or idea is far-fetched enough for your own projects.
- To advance projects that are not economically / time-wise feasible. When you remove the concept of efficiency and efficacy from the system, other projects are suddenly available.
On a personal note
Lately I’ve been learning another programming language, to use as my main driver. This makes my previous main driver a bit rusty. So, a personal project can be to get familiar again to my old main language.
You can also try new methodologies or challenges: maybe Test&Commit Or Revert (TCR), by Beck is not appropriate for work. Here, it could be. It’s up to me. A (fun) challenge that I’ve been trying lately is to get the maximum done in a small period of time (1 pomodoro of 25 minutes). After this, you can throw away the code (I personally start a new branch from the beginning), à la Global Day of Code Retreat, or repeat the experiment (same or different conditions.) What I’ve tried is to get as far as possible using one language, then changing. Using two pomodoros to repeat the experiment in the same language, etc.
Regarding the non-time-wise feasible projects, sometimes the rational decision is to keep doing manually the same process, rather than to automate it. In this particular case, the monthly cost in time is about 10 minutes. The estimate for automating it is ~6 hours. It would take 3 years to amortize the cost of development (in time, not counting comfort, satisfaction, etc.) In that time, it’s quite possible that the API changes, and you need to invest more time in maintenance. In this case, as mentioned earlier, the rational decision is to keep doing the process manually (for efficiency reasons.) Once we remove this efficiency constraint, I have been able to build a small tool to automate it. Again, we are tool makers, process automators (for work), and also tool users (on a personal level). After having designed and implemented the tool, I have used it for a while. Unfeasible from an efficiency point of view, but possible in practice. This tool allows me to keep building new tools on top of it, and enable 1% improvement steps (kaizen).
These projects are another tool in my toolbox. I prefer to optimize for other criteria, but sometimes I use these worthless projects for the above reasons.