Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Put "Good Enough" next to your first name and be proud.

If you find yourself perfectionist at work, maybe it is just a matter of caring less about work, just enough [1]. It will probably help you meet the deadlines, push less time pressure on everything and everybody and overall get you better outcomes. If something needs to be improved it will. Or it won't, but maybe it's not your problem anymore then. Worse is sometimes better. Sure, keep a high enough standard, but I don't need to tell you that if you are perfectionist, right? Maybe ask people around about that in case of doubt.

In your hobbies, if you find yourself wanting to achieve results you don't reach often enough: first, they are hobbies. You already win if you enjoyed doing something. Then, lower the bar. Take all the time you want on part that interest you. Over-engineer as hell those things if you take pleasure in doing it. But otherwise make it work even if it's worse.

If you program in your hobbies, just write this ugly thing that works. Copy paste that spaghetti code and make it work. It's misaligned but usable? Don't care. Put FIXMEs and move on. You'll have all the time to refine later if it's important to you, when you won't have the burden to make it work anymore and you'll have achieved something, reached a motivating and gratifying step where something works even partly.

Save yourself from cognitive load caused by the need to solve everything at the same time, perfectly and that will stand in your way.

It's less efficient, but it's more efficient.

[1] I wrote about this two days ago in another context: https://news.ycombinator.com/item?id=28365945



> push less time pressure on everything and everybody and overall get you better outcomes. If something needs to be improved it will. Or it won't, but then maybe it's not your problem anymore.

Most of what I do I'm either solely or primarily responsible for, and when something breaks, it comes back to me. I've rarely been in situations where something wasn't my problem. By the time it was a 'problem', if someone was contacting me, it was almost definitionally my problem. Not sure how to square that with the advice above, as tempting as it sounds.


The bar is then probably: "can be ugly if it's too much work to do it by the state of the art, but robust enough not to (unexpectedly) break on you at the worst time"

Maybe it's a matter of handling nominal cases, shipping/releasing and only then handling the cases more at the edge (just) after, but with nominal cases out of the way with someone waiting for results and putting pressure while you are working on your stuff. You win the occasion on working on your stuff will less stress, which might as well end up in a more robust result.

For some problems, maybe it's acceptable to handle them when they occur. It could have allowed someone who rely on a feature to use it earlier and be more productive despite this problem, instead of waiting for the perfect solution. It may allow more communication, and therefore more insight, which may help producing better results too.


Thank you for the response. It's a constant effort to find that balance, and it changes as projects and people change.


To be accurate, when I wrote this:

> If something needs to be improved it will. Or it won't, but then maybe it's not your problem anymore.

I had my situation in mind, where I would often find myself wanting something to be improved but unfortunately I'm not the one deciding what gets done. And if I were, I still would not make the decision of doing so because of priorities.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: