TL;DR: Don’t avoid writing a kludge of code when the situation necessitates it. Sometimes, factors outside of our control dictate how quickly we can turn a solution around. At the minimum, leave a code comment that explains what the code does and optionally why it’s not included in a way that’s as consistent with the rest of the module in which you’re working.
When I first started in my career (as I imagine most people in our industry do), I was bent on writing the best solutions possible to the problems that I was given.
Nevermind that fact that I may not have had the experience of my peers, managers, or so on. I was bent on making sure that given the level of information I had, I was going to write the best code possible and aim to both prove myself but to show what I was capable of doing.
I was young. 🤷🏻♂️
Fast-forward over a decade, and things have changed.
Write a Kludge
This isn’t to say that I don’t aim to write the best code I can, because I do. And it’s not meant to imply I haven’t learned more than I did when I first started, because I have. (And both of these are things I think many of us who care about software development do.)
But the point is that when it comes to writing code that just solves the problem, I’m more comfortable writing something that just works when necessary so long as the requirements necessitate it.
Specifically, I’m more comfortable writing a kludge when I need to do so. One definition is:
A clumsy or inelegant solution to a problem.
definition of kludge at wordnik
Over time, you’re going to gain greater experience in software development. This means you’re going to see when a certain pattern will work as well as identify when anti-patterns are present. But this doesn’t mean that we always have the time, the budget, or the resources to integrate our solution the way we’d lake.
In those situations, it’s best to solve the problem, leave a note using a keyboard like TODO or NOTE which many IDEs will automatically identify as keywords provided by the author, and explain the rationale as to the why and how the code is implemented as such.
It’s not an excuse to write bad code, but it’s a reason to write code that you’d otherwise not given other circumstances.
