When do we consider to "hack" some code in?

I am ashamed that I have to ask this. but the codebase is such a mess that simply adding another function to pass some information to 5 different classes that should not know about this. just to make it work. feels awful to me

wait why do I have feelings I get paid to maintain this shit.

The truth of the matter is that you are more likely paid to maintain this s***?

> wait why do I have feelings I get paid to maintain this shit

No pay is worth fighting uphill all the time. In your situation, the principle "first make the intended change easy, then make the easy change" might apply.

Well, my take on when technical debt is acceptable is this:
Generally I do the clean solution, it almost always saves you time, money and nerves. In my experience you *don't* go back and fix a hacky solution, and later it bites you.

However, taking tech debt is a compromise I'm willing to make under certain circumstances. 1. it's actually ("objectively") time critical, not just "manager xy wants it". 2. it's guaranteed I can do it properly right afterwards. 3. the hacky solution actually saves significant time now. 4. I don't need to redo everything for the clean solution.

... which are rarely met, and rightly so. Most bad code out there didn't happen because it was necessary.