For Side Projects, Refactoring Is a Byproduct, Not a Goal
One thing I have to remember is that for side projects, refactoring should be a byproduct, not a goal. I genuinely find a lot of joy in making code as pretty as possible. It’s fun for me, and I get a lot of satisfaction out of it. That’s a good thing for situations like my day job, where I’m programming within a team and the hope is that the code will be used for the foreseeable future: code needs to be presentable, readable, and extensible.
However, for side projects this comes at a cost. There’s an inverse relationship between the length of time spent on a side project and how likely the project will actually be completed. In my experience, long-running side projects run out of steam quite quickly, benefitting from a large spike of motivation in the beginning and then petering out after the initial adrenaline rush. Continuation of the side project really depends on making progress and hitting certain progress checkpoints, which themselves reenergize motivation about the project like Mario Kart boosters. Side projects are in permanent existential crisis. It is of utmost importance that their specific purpose is pursued with economy, before other distractions inevitably get in the way. There is an implicit gravitational force on side projects, constantly tugging on their progress, pulling them back. A project must reach escape velocity by making tangible progress if it has any chance of succeeding in the long-term.
The motives of a side project run counter to the motives of “enterprise”, production services. Side projects usually involve a single contributor (yourself), while for-profit programming usually involves a larger team, and potentially many other teams. It’s true that you can certainly confuse yourself with self-authored code after a sufficient amount of time has passed, but for your own ego’s sake it’s a lot easier to forgive yourself for poorly written code than having teammates or future contributors curse your name when your GitHub avi pops up in git blame. You don’t want to be that programmer. Further, as noted above, the lifespan of the two types of projects are (in theory) at opposite ends of the spectrum. In the best case, enterprise software lasts forever, pumping value out of large upfront cost and low maintenance cost. A side project can be expected to disappear as quickly as it came to be. When software is expected to last, extensibilty and maintainability are the most important factors; otherwise, the most direct path to goal fulfillment is acceptable and likely preferred.
For side projects, maybe refactoring should be viewed as a side effect of success: if the project has lived long enough to warrant a refactor, that in itself is a sign that the project might be successful. But, the point of the project is to not refactor it into code that’s beautiful to look at, but rather to develop it into a thing that does something. Refactoring may be necessary during the course of a project, but (at least for me) should only be the means, not the objective. There is no point in embarking on a beautification project if it’s going to be bulldozed a week later (or, more accurately, left to decay without proper care and supervision). The important thing is to get the side project from point A to B; if it reaches B, only then can refactoring be enjoyed as time well spent.
