It’s no secret that developers who create toy apps, side projects, or tutorials, benefit from the process. Initially, I thought this could be boiled down to just being good forms of learning. Building something new, and even more so teaching something new, are both great ways to learn.
There is another benefit, however: Developers who do this are building their own code library. Sure, maybe the code isn’t production-ready, but it’s at least a (hopefully) working example that can act as a combination of reference implementation, quickstart guide, and memory-jogger.
Consultancies can also reap this benefit. In a lot of cases a developer will remember “hey, we did something like this on ” which allows them to get up-to-speed quickly without having to re-learn the same information.
I suspect framing personal projects in this light might change the way we think about toy apps and the ’exploratory’ side of development. Need to interact with a new API? Perhaps it’s worth hashing out the details in a simple script or app, both as a proof-of-concept but also, potentially, to add to your ‘personal library’ of code snippets.
This also frees you up to write the code without worrying about making it production-ready polished. Add comments pointing to helpful documentation or Stack Overflow answers.
I admit I have not tried this approach myself yet, but have noticed the number of times when I dig back into old projects to remember how to call an API, use a particular library, or set up a build pipeline. Rather than have to sift through the ‘business logic’ of my old project, I could have created a simple, standalone repository to encapsulate my knowledge. Thereby making it more searchable, readable, and re-usable.