One of the most durable and difficult problems in software development is choosing carefully between building something in a general, modular way, vs building for just the specific problem at hand. This can sometimes be described as “future proofing”, or sometimes just “hacky” or not.
The challenge is that neither pure approach works completely. If you just hack everything, eventually the code gets big and messy enough that it’s not manageable - it’s a “hairball” in technical terms, or the dreaded “mudball”. If you imagine a graph of coding speed over time, you did great at first but then dropped off a bunch - so the area under the curve isn’t that big.
But! If you are overly focused on modularity and understanding every possible future use, you can often go much more slowly than you think. It’s possible to get good leverage from *some* generalizations, but often the effort of building the generalization doesn’t pay back in the lifetime of the code, or you build the general case too soon before you understand the problem well, and some of the effort is just wasted. If it takes 3x the energy to do something generally but you only need 2 instances of it, you didn’t come out ahead. It’s even worse if you needed 0 instances of it! In this case, the area under the graph is small at the start but, hopefully, gets bigger over time.
And that’s really the right way to think about the problem - what’s most likely to maximize the area under the “code produced over time” graph. Sometimes it’s worth delaying at the start to have a payoff at the end, sometimes it’s not. The two questions to ask are: how hard is this to change later (if it’s too hard then you’re likely too hacky) and how long until the modularity pays off in reduced total effort (if it’s too long, or if you don’t understand the problem well enough to even have a guess at ROI, you’re probably being too careful).
It’s a tough balance and there are legitimately times when the answer is unknowable and is just a judgement call. One specific thing you can do as an engineer is keep track of your predictions as honestly as you can - try to pay attention to how you make these calls and look for where you can be better at them. It’s a lifelong process.