Websites change. Healthy codebases are constantly being updated. Legacy code dies when it eventually goes down with the ship. Recognizing that my code is transient allows me to be more practical about my code and what guides my decision-making as I author it.
Your code is transient.
Table of Contents
I like to think that code changes stem from one of two causes: code decay or website relevance.
Code decay
The code we write follows specifications from authorities like web browsers or frameworks. It can also be based on requirements from a business or organization the website is for. All of these rules change as our websites and their contexts evolve. I think of this as code decay. Maybe an HTML spec is adopted by browsers allowing our markup to become more semantic, or perhaps we’re using a framework and want to upgrade to the latest major version. Maybe a business needs to change payment providers, or perhaps there’s a new security requirement we need to adopt. Our code frequently needs to be maintained in order to keep up and, at times, keep working. Occasionally, we can get by without changing it for long periods of time, but there is always a point at which old code needs either to be changed or disposed of.
Website relevance
Let’s face it, our website is not as cool as it used to be. Maybe this is because the design has grown old, or perhaps what it does is less important to people than it was before. Maybe there’s a new requirement and feature that needs to be added, or perhaps we’re just tired of staring at it. Redesign! Rebrand! Iterate! It is unreasonable to expect most websites to stay relevant without changing their content or code significantly over time. We should expect our code to do the same and change over time—especially on the front end.
Accepting change
The reality of change seems like a fairly obvious thing to acknowledge, however, I find it to be a helpful reminder as someone who has a tendency to go off coding as if I am building The Great Pyramid of Giza. Coding is often much more like setting up camp, not knowing if we will be staying for a few days or a year. I try to start with the assumption that it will be brief, and settle in over time. Consider picking up some overpriced water at the store before we dig an entire well. So often I find myself in a frenzied relocation days after pitching my tent. I do not need to look much further back than a few months to find code I have written that already needs to change. It doesn’t need to change because I didn’t do it good enough the first time—it’s just time to change it! How should this influence the way we code or think about our code? Here are a few thoughts I have adopted recently.
1) Write transient code.
Knowing that my code may change in the near future allows me to focus on its current purpose and ensuring its footprint is isolated. It has freed me to focus on the code in front of me and not be distracted by the possible future timelines of the code I am writing. This is particularly applicable for large portions of small projects. For large projects, you can apply this principle to pieces of your codebase. If you have used a component in a library for an entire year, often its requirements have changed over time. Removing the cruft of the past can help give it purpose for the immediate future. I often find writing a replacement component to be quicker than updating an old one, and the result to be easier to use and understand. Where applicable, I try to replace instead of rehabilitate. When I create something new, I prioritize the present, trusting that I will give myself space to solve future problems later on. Future problems are often best solved in the future because you tend to have more facts and fewer assumptions the closer you are to the problem.
2) When possible, avoid dependencies.
More and more I am drawn towards built-in browser functionality and have a high bar when justifying the use of frameworks. At certain scales dependencies are unavoidable and frequently more efficient in collaborative environments. When I do use them, I try to isolate or wrap their functionality so that it is easier to untangle later on if I need to. If you can justify the effort of writing your own code, you become more familiar with web specifications and learn just how robust they are on their own. You also end up with something that can be easier to maintain long-term because it is closest to the core evolutionary path of the web. There is no dependency upgrade between your code and ever-evolving browser functionality.
3) Let the code die.
While this is only an acceptable outcome for situations that don’t require change for important reasons, like usability, this is my favorite thing to do when it makes sense. Let things get old. Don’t intend on updating them. Creative projects and demos are a great case for this. By letting old projects die, I am acknowledging that their value was very much tied to the moment of time they existed within. Not everything needs to be around forever (spoiler, nothing we make will be around forever). If something is important and you want to preserve it, capture its meaningfulness through screen recordings and documentation, and then move on. This has allowed me to proceed to the next the thing more freely.
Moving forward
For me, the most meditative and rejuvenating thing I can do as someone who writes code is to reflect on the fact that the code I write is transient. So often this space can be highly combative when we talk about tooling, best practices, and the new hot thing. A spirit of urgency to adopt the “best” approach applies immense amounts of pressure as we plan out projects. We speak in absolutes with an air of permanence and often overlook just how dated our opinions are going to sound in the near future. The stakes are ultimately never as high as they feel when you are making decisions about tooling.
I prefer to be in a place where I am continually recognizing that the code I write is temporary, that technology is growing faster than I can individually match pace, and that I will never need to have expertise in all things. It is here that I find comfort in knowing the best code I write is in front of me and that the best website I can make right now is the next one.
