[mnemonicsloth]

If it solves the business problem your clients are paying you to help them with, your code is definitely good enough.

The people with opinions about your code are probably not paying you. So coding well is more like being polite to them. Really good code makes their lives slightly easier than average code (which is way better than no code).

But politeness goes both ways. If they see you trying to improve, they'll probably try to help you.

PS - When people want to get better at somthing, the biggest mistake they make is assuming they can get better inside their current comfort zone. So if you want to improve, get lost for a while. Try writing an OS. Or a physics engine. Or learn a Lisp. You'll be surprised how fast Experience - From - Elsewhere translates into more skill in your day job.

[pyre]

"Do whatever it takes to solve the business problem now and we'll worry about the other stuff later" is what produces horribly complex code bases because "later" never comes and management will never justify the time to fix things.

This presents you with a number of problems:

* It makes it harder to pivot in the future. You may end up having to rewrite a lot in order to extend the original model.

* In most cases, this means no tests.

* Maintenance costs significantly more.

* When you hire new people to work on the code base, it will take a significant amount of time for them to come up to speed and be productive in the code base.

[mnemonicsloth]

I assumed OP was competent but not stellar, so my answer was about the difference between average and good.

You're talking about bad. I agree that no competent programmer would do the things you're describing if they could possibly help it. So we probably would have given OP the same advice if we had started with the same assumptions.