[michaelwww]

"Make it work, then make it beautiful, then if you really, really have to, make it fast. 90 percent of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!" – Joe Armstrong

As hard as it is to resist, I would argue that if you other modules to make work, move on and leave making the current module beautiful for later.

That said it's really hard to leave working but ugly code alone

I find a lot of freedom in coding for myself. In other words code that no one else is ever going to see. This goes a long way to silencing my inner critic. If I ever want to open source it, I can make it perfect at that time. This is why I don't keep my code on github. When I write code for myself I can express myself the way I want to, which is not necessarily the "standard way" that someone later might a "code smell"

[MrLeap]

Code that serves as a highway I try to make as clean as possible. Code that serves as a cul-de-sac just has to work.

[jebraat]

Thanks for the comment Michael!

I 100% understand the "it's really hard to leave working but ugly code alone" sentiment", as I get the same feeling a lot of the time. That is one of the reasons I wrote this article.

I often have to fight myself to move on to do work on other things.

[michaelwww]

Other programmers can be harsh critics and it's important not to internalize these critics. This isn't a knock on other programmers, but the criticism is often based on their own perfectionism!

[slindsey]

Those "other programmers" that are "harsh critics" are often ourselves. How many times have you (any programmer) looked at your own old code and thought, "what they hell was I thinking?"

I can't count the times I've looked at ugly code, fired off `git blame`, and found out it was me.

[jstimpfle]

My experience has often been feeling that something wasn't right and trying to fix it at a low level - variable or function names, length of lines and expressions, organizations in files, things like that. Often I would clean up things superficially but the feeling that something is wrong remains.

Sometimes I come up back after years, having learnt how to organize certain kinds of programs better, and can instantly see that the problem was much deeper than that. I now think that as a rule of thumb, if it is hard to make a piece of code tidy at a superficial level, there is a deeper underlying issue. If I manage to find a good architecture, I try to keep the bad code as minimal as possible instead of investing more time in a dead end.