There's no shame in code that is simply "good enough"

For me, the understanding happened in similar order:

- First, as a beginner, I solve all problems with minimum effort possible. The goal is the product.

(It's not real programming, but working with CMS that involves writing code sometimes.)

- Then I see the way to make much cooler and more “custom” products—with a web framework. In order to be able to do that, however, I need to start doing real programming.

- Learning programming, I find that what I was writing before was pure crap. I also forget that the product is the end goal, and care instead about writing code.

- Lots of LOC but few finished projects after I discover that code actually doesn't matter much. Instead, other stuff does—like speed, communication, measurement.

- Learning to make and deliver products with minimum possible effort—that's where I am now.

Then if its 'good enough', leave it at that.

If it needs work later, anybody can do it - you didn't make it too dense or compact or concise to easily reinterpret or diagnose.

Its not just a good idea, its pretty much an obligation if you are paid to create it. Keep personality out of it, complete it on time and under budget, move on.

There is an essential difference between a paper cup and a glass.

Say you are throwing two outdoor parties a year, but otherwise will not serve more than 8 people. The best solution, if you start with nothing, is to buy a set of dishware for 8, and then throwaway plastic cups and plastic knives twice a year ad hoc.

Code could be seen as similar. There is one-off bad solutions, that are no better than a paper cup. You can't iterate on them (like washing a plastic cup) because it starts to fall apart.

Then there is glassware. It's more expensive, but durable.

So, one approach is to look at your resources and your immediate and expected future needs, realize that better code is more durable but more expensive, but that there is nothing wrong with "consumable" code that you can't wash more than once or twice before it starts being "a mess".

Just because "code is forever" we tend to think of it as not being consumed after being used for its purpose, but due to the nature of engineering, in fact thinking of it in terms of just that is quite appropriate, in my humble opinion.

Once you realize this difference, you can make strategic investments into durable and consumable code. You usually can't fortify a paper cup, nor turn a plastic cup into a glass one, though, so often this is a decision to make several times over the lifetime of your "household"! :)

For personal use, if you have very little money (time/resources) there is nothing wrong with starting with paper, buying plastic and then glass or ceramic, spending, overall, three or four times as much money as if you had just bought a beautiful antique set of dishware for yourself to begin with. Often, though, that is not the real situation: realistically, you could "do without" for a while, and then buy a durable good you won't replace.

These are difficult investment decisions for households, individuals, and companies.

Don't discount renting, either! In this case, that could be analogous to licensing someone else's software.