Should I take the time to clean my code once it's working if it isn't clean? Cleaning can take a lot of time. My boss just need it working but I feel unhappy if my code isn't clean.
closed as primarily opinion-based by Jon Raynor, Robert Harvey♦, gnat, Thomas Owens♦ Dec 22 '16 at 16:53
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
This is the core idea behind code reviews: to make code cleaner after it works, to keep it maintainable. But I guess in your company you don't even do code reviews, otherwise you would not have asked. So start with that.
However, I recommend heavily to avoid getting code too dirty in the first place. Next time you add something to an existing code base, try to follow the "boy scout principle": leave the place (code) behind in a better shape than you found it. Then this question becomes obsolete.
The wisdom of investing time into code that is "beyond functional" - more than you strictly need to get something to do what you need it to do - depends on your particular environment.
If you never intend to use code again, often in the form of throw-away prototypes, proof of concepts, etc, it might not make sense to go beyond the minimum it takes to get the job done. Dirty hacks can be a valuable time-saving method.
It's a Race!
In some businesses, especially startups, sometimes coming in second in "time to market" is just being the first loser. Blowing a funding round because you weren't willing to do absolutely everything to get the key milestone in the minimum time can sometimes mean you are just out of a job entirely. That code has become a "one-off", because it probably won't ever be used again.
Again, dirty hacks abound and you might very well need to throw out what you come up to hit the most immediate goal, if your company survives long enough to care about the 1-2 mark. You can either plan to refactor heavily, rebuild if what your new goal is just isn't compatible with what you have (which is rarely ever a good idea, but it can make sense if you really chose wrong on technology/platform, or you are making a big strategic pivot), or suffer through the mess and risk having technical debt overwhelm your ability to respond to market/customer need.
You Write It Once, Everyone Else Reads It 100 Times
Especially when you are in a stable organization or with large teams, code that is hard to understand, hard to read, and ultimately hard to maintain can be a highly costly liability. When the average application lives 5-10 years and will be worked on by dozens of people, saving 1-2 hours of your time instead of cleaning things up, improving naming, and documenting appropriately, can easily cost an order of magnitude of time waste across the codes lifetime.
Learning What Is Good Enough Is an Art, Skill, and Wild Ass Guess
You can always improve code. I don't know that I've ever seen code that is perfectly eloquent, and the time taken to produce it regularly would likely be so prohibitive that it would not make sense in any environment. For all the value of craft, most programmers are not hired as fine artists - more like commercial artists, where deadlines and costs matter. Every program you write is not a magnum opus, so you need to find a balance between "I could make this better" and "it's horrible, but it works".
The right trade off will vary by project, person, team, and possibly even by time of day/week/month/year. The more you practice clean coding, the easier it will be to produce it, too, so you just have to adjust your "cleaner/faster" dial to suite your situation.
In my experience, if your code is not clean, you have no idea if it "works well" or not. Cleaning code as you go is part of making sure it works well, not merely cosmetic. It is very difficult to see mistakes in boundary conditions, duplicated code, rarely-exercised code, etc. in messy code. Messy code is more difficult to test. It's more difficult to debug. It's more difficult to change without causing regressions.
My only quibble is that you shouldn't wait until you're "done" to clean your code. Do it along the way, a function at a time, a class at a time.
You can spend the time now to pay down the technical debt, or you can wait and spend a lot more time later fixing the inevitable bugs.
Unless your company is invoicing for the work, don't do it.
Advanced user answer:
You should have done it the first time around.