Hacker News Reader

Comment by augment_me | Hacker News Reader

Temporary solutions will become permanent solutions unless you explicitly hold yourself to fixing it within a certain time window because it becomes harder the longer time has passed.

This ranges from TODO's in codebases, to unpacked moving boxes, to replacing that sofa you got from your friend, to leaving a toxic relationship.

After a while you acclimatize to the situation and no longer see the issue, and unless something is really broken, it grows harder to motivate yourself to change.

View on HN

This is maybe just me, but I need to remind myself of the opposite: All solutions are temporary and imperfect. So just do something, I can always go back and correct it.

For me this means that I'm allowed to store away 3 things from the moving box, even though I don't know where to put the rest yet. To invite others even though I don't know what to cook yet or to write a bad implementation quickly, instead of spending hours figuring out the best one.

I think a balance of perfectionism and can-do is important. But as people are predisposed differently, either advice might make sense in different circumstances.

> But as people are predisposed differently, either advice might make sense in different circumstances.

This is a very good point. Life is a balancing act. Different people may need the opposite advice. Or you may need the opposite advice at different times. Not just in this case, but in life in general.

I actually did not mean the post as a call to perfection/action but I can see why it could be seen as such. You can have a temporary solution that is good-enough for its purpose at a time. I advocate for the conscious effort to evaluate your intention so that you can feel a sense of agency around whatever happens afterwards because you are more likely to lose context, and the initial intention, as time passes.

Also, even after you learn this, other people will refuse to believe it, and will boldly agree to commit to months of work that is utterly pointless and even a net negative contribution to the world, because they will never do the other few months of work that was needed. And then when you say “no, we shouldn’t do this” to the 45th project plan, they get offended and swear on their own heart that they will force the second part to happen or, or, or nothing. And 6-12 months later they’ll do it again! Like fucking goldfish!

16 years ago when I was starting at my current employer as a contractor, they gave me some test data. I put it in a table called {domain}Temp. That table still exists, and about half of our production data flows through it. And yes, we've been talking about changing it for 15 years. (oof)

To be fair, everything is temporary.

This is a lesson that I've learned the hard way over the course of my life.

I do know a second way to prevent temporary solutions from becoming permanent solutions. You can just try out new things temporarily. Take your sofa example. If you choose to just try a different arrangement of furniture for a short time, that gives you can opportunity to remember to replace the sofa. The hard part is being willing to experiment with changes, but I find that it reframes things from fixing an old problem to trying something new, which can be more exciting and motivate additional improvements.

I'm kind of the opposite. I mark it as an issue or bullet somewhere to do and if it never happens or becomes a brain splinter, it probably never needed to happen.

This is decent. Make tickets for the todos ahead of time and make sure your PM gives them priority.

Oh damn.

I guess I've learned something.

Thanks :)

old codebases are always, plenty of these

All successful code bases have this ”problem”.

You become successful by making priorities. All parts of your product do not need to be perfect.

this is great advice!

Reply on news.ycombinator.com