One thing I’ve noticed the more I work on anything is that reusability is everything. Even if you’re slapping together some simple little script that is intended for 1 specific thing to do some piddly little task, odds are you’re going to need to dig it back out and adapt or convert it for something else. In short, you’re always going to need it. So what does this mean to you as you write any sort of code?
For starters, let’s start with what this doesn’t mean. It doesn’t mean that you need to implement every thought or to-do right now. It doesn’t mean you can’t push things out to a later release. It doesn’t mean that everything is worth the effort it’s going to take to implement it. It doesn’t mean that everything you can think to add is a worthwhile contribution to your product.
What I’m talking about when I say that you’re always going to need it is that there is no such thing as a one-off. That means you should be saving all of the code you write somewhere, even if it’s never part of an “official” project. You’re going to be around for this code again at some point no matter how niche you thought it would be or intended for it to be when you wrote it. That means there’s never an excuse for not making sure that any code you write is written well. That means commenting your code, it means taking the time to organize your code into logical functions and blocks, and in general structuring your code like it’s going to be imported or copied and pasted into another project, because it’s probably going to be.
Because you’re always going to need your code again, you need to be thinking about not just what you’re working on right now, but also what type of problem you’re trying to solve, and how that code can solve other problems of that type. In other words, you should always be on the lookout for instances where the code you’re writing is specific to the particular thing you’re trying to accomplish right now.
Coding from a “you’re always going to need it” perspective forces you to think about how your code may be used later, either by you or the next developer to come along and try to do something with your code. It means trying to find ways to make your code as easy to adapt for future projects as you can think of.
1 of the easiest ways I’ve found to do this is to try to put as many project-specific settings as possible into external configurations, where they can be easily switched around without having to touch the code again. I personally like to make configuration files a command-line parameter for any scripts I write, so I can either specific details for several projects in 1 place, or just quickly make whole new configuration files for each project and swap them in and out as needed.
You’re always going to need it is also a good guiding principle for making your code open to extension. Approaching code from a “you’re always going to need it” perspective means trying to think of reasons to re-visit your code later, and making your code sure your code is ready for the things you’re most likely going to have to do later.
If nothing else, approaching coding from a “you’re always going to need it” perspective is motivation to write your code the correct way every time, not just on “big” or “important” projects. It’s also a good way to keep an eye out for how your code may be changed later so you can design around that the first time. It’s a realization I’ve come to fairly lately in my career, and I’m trying to keep it mind as I work on future “one-off” projects as well as I’m recycling some of my older “throwaway” scripts, trying to make them more flexible and adapatable for the next time I’m going to have to use these things for something that’s just a quick run-once-and-done type project.
Maybe this will be something I write about as a bad idea that sounded a lot more brilliant at the time, but the frequency with which I write quick little scripts that I wind up copying and pasting from (or just copying and pasting entirely before tweaking a few little chunks of logic) have pretty thoroughly convinced me that I have a problem of trying to “cheat” on simple little one-off code, starting with the idea that code being written is ever “one-off” in the first place.