The ability to write reusable code is considered a hallmark of excellent programming, and with reason. Having reusable code means that a team won’t have to write separate entries for every piece of software that performs a similar function; this greatly reduces the collective workload and frees up time for more meaningful work.
At the same time, the importance of reusable code can be overemphasized. It is not unheard of (particularly with the contemporary glut of motivational speakers in tech) for junior developers to be advised that all their code should be reusable, otherwise they are not doing a good job.
Reality is, of course, not quite as straightforward. While writing reusable code is important, there are actually cases when code should not be reusable – or, at the very least, when such a quality should not be in the forefront of your mind.
Don’t believe me? Here are 4 cases in which you should not be thinking about reusability!
#1 When it trades off with simplicity
Reusability is an essential principle of development, but that doesn’t make it the only essential principle. Simplicity is arguably even more important, and should be paramount in any project you embark on.
Sometimes, on a good day, you will come up with code that is not reusable, but that is beautifully simple and elegant, making it easy to read and understand. If the only way to make it reusable is to render it perceptibly more complex, then it’s usually best not to touch it.
The trade-off will typically not be as obvious (you can’t ‘measure’ how simple a line of code is), but as a general rule of thumb, reusability should not be pursued when it comes at the expense of simplicity.
#2 When it will have to be changed
Code is not a static thing, and the parts of it performing the most complex functions in a project will probably have to be tweaked with a certain frequency. If you expect your code to be amended, but you aren’t certain when or how often that is going to happen, then you should probably write something that stands alone, as future changes to what you wrote might reverberate elsewhere in unpredictable ways. The last thing you want is to have to mop up everywhere in your code each time you change a variable.
Bear in mind, the sort of thing for which reusable code is most useful is also the stuff that typically doesn’t need to be changed too much – aleatory functions, like for example connecting to a database – so ‘one-off’ solutions, in this case, are unlikely to waste time on the long run. This leads me neatly into the next point, that code should not be reusable…
#3 When it’s not time-efficient
The whole point of reusability is to save time. If trying to make all your code reusable is slowing you down as a developer, then maybe it’s best to forget reusability, at least for a while, and just focus on getting your projects done on time. Remember that if you stay within schedule, you can always use the extra time to refactor the code later and make it reusable then.
As a developer, you will spend much if not most of your project time working under a tight deadline. Making all of your code reusable may sound like the best option on paper, but in practice, you’ll have to learn how to make compromises in the name of time-management. Sometimes that does mean ditching reusability.
#4 When you’re looking for early results
This is related to #3, inasmuch as it’s another thing that can be changed later in time, but this one is more about the conceptual approach at the beginning of a project than the time-squeeze at the end of it.
Basically, the idea is that your first priority when beginning to prototype code should be that it works, with reusability a secondary consideration. I wouldn’t go so far as to say that code should never be reusable in the early stages of a project – if you can make it reusable on your first go, then great – only that it’s not the priority.
Code has to be useful before it can be reused. Get the true essentials done first.
Final thoughts
As we stated at the outset, reusability is important to programming. Indeed, one of the reasons React is so central to our course is its reusable component ecosystem, which is both powerful and widespread.
However, it won’t surprise you to learn that nobody would pay a developer for work the entirety of which could have simply been reproduced from somewhere else. Any product you’ll be working on should have a unique selling point the uniqueness of which will be reflected in your code.
Knowing how to write inherently unique, proprietary code is therefore every bit as essential as knowing how to write reusable code. And while it may be characteristic of developers to have a wealth of different and even contradictory approaches to how they code, ultimately it is their principles that must serve their work, and not the other way round. This is as true of reusability as it is of anything else.
