It’s a peaceful night, my dog is snoring loudly in his bed next to me. I open up my Github account and start leafing through page after page of side projects. The further back I go, the more nostalgia I feel. I see names of people I collaborated with during University. Some I barely remember, others I remember vividly. One taught me to never over whisk pancake batter. Lumpy goop equals fluffy pancakes. However, most of the repositories are merely shadows of a project. Many of them are auto-generated using Rails new. They contain a Model sometimes two, or a problem statement and an app name. All of them, never became what they promised to be. It’s time for them to go. Delete this repository. Yes, I understand the consequences. Rinse and repeat. As I’m lamenting the fact that Github doesn’t have a bulk delete option. I’m starting to wonder.
Do I ever finish what I start?
I’m very good at coming up with projects. I’m very bad at executing them. There’s a pressure both internally and externally that you should finish projects. Make them usable, polish them and display them on your website. A portfolio that you can use to wow recruiters. During this mundane task, insecurities started bubbling to the surface. Is my experience a lie? How can I be a “senior” developer if I don’t finish anything?
But a graveyard of side projects is not a bad thing. Each failed side project, every half assed idea, shaped how I develop today. Old, neglected side projects shouldn’t be scorned. They should be revered. They’re a part of my history as a developer. The more I think about it, side projects are built for two things. Learning and exploring.
As a new developer, I spent most of my time memorizing the mechanics of a particular language or framework. Without this understanding, I wasn’t able to take a nebulous idea and break it down into concrete steps. Viewing my past in this light, every side project was a way to build the foundations. It was a way to practice muscle memory. Unknowingly, I was learning through repeated retrieval.
In Make It Stick: the Science of Successful Learning, Brown et al. examined the most effective methods of learning. “Repeated retrieval not only makes memories more durable but produces knowledge that can be retrieved more readily, in more varied settings, and applied to a wider variety of problems”. In the beginning, I needed to remember and understand the commands needed to create a new Rails project, to generate a model, to open up the console. I was seeing how models interacted with controllers and with views. The working parts of an MVC architecture. Without the foundations, I couldn’t achieve a higher-order level of thinking. With Brown et al. words in mind, these repeated side projects were a way of learning.
As the purge continued, I realized that even though the general problem stayed the same. The way I tackled the problem changed. I was exploring different ways of taking data, saving it to the database, and displaying new information. I would try different models, I would scaffold one project, hand roll the code in another, sometimes I would add authentication. Each project had a different constraint.
Corey Haines introduced a similar idea in his Code Retreats. With Haines’ Coding Retreats, developers would pair on a problem - Conway’s game of life. Each pair was tasked with building this game from scratch. Every 45 minutes pairs would come together, reflect on what they learnt, and then repeat the process. Starting from zero lines of code. Every. Single. Time. To make things more interesting, constraints were also given to the pairs. In one session, you couldn’t use if statements. In another you couldn’t pass primitives like integers or strings in function calls. You would have to wrap it in an object or a type that you created. The code that was written in these sessions were always thrown away. It was a form of practice. “The act of writing it and the act of using these constraints is what you want to carry with you, not the code”, Haines explains in a Relicans podcast. He goes on, “The world is a better place because it’s deleted, believe me. One of the reasons is because the constraints that we put in place are not constraints that you necessarily should use when writing production software”.
While I can’t say that I consciously explored different constraints, or intentionally picked the same issue to tackle over and over again. These throwaway side projects were a way for me to explore new ideas. And to practice existing ones. They were a place to struggle and to figure out what not to do. As Brown et al. expands on this idea of struggle “When you’re asked to struggle with solving a problem before being shown how to solve it, the subsequent solution is better learnt and more durably remembered”. The unfinished projects were a way for me to cement my knowledge when I did get to production.
Finally, can a side project ever be finished? A state of finish is whatever you want it to be. In most real world programs, nothing is ever finished. It’s built to serve a purpose and then continually improved. If we view side projects as a way to learn, a finished state is exactly this. A state where you’ve explored a problem space and you’ve learnt enough to move on. A side project isn’t something that needs to be a usable product every time. Each “failed” project builds on the other. I’m not starting from scratch in every side project. It might seem that way on the outside. But I’m building on my knowledge.
Ultimately, the derisive, do I ever finish what I start? Becomes the indecisive, should I ever finish what I start?
The answer is an unequivocal, no.