I would add the amount of effort put into designing and polishing any project that you can defend is correct is related to how much future development and use the project will see and how critical the project is for the company.
So, if you want to work o a nice quality project or want to spend a lot of your time on improvements to quality find yourself a project that will either see a lot of future development or a lot of future use or is extremely critical to the business or, best, all of these characteristics.
I see this mistake happen all the time -- people complaining on quality, disparaging previous developers or demanding effort to improve it just for quality sake ("because I just read this book and it can be done better") without reasonable arguments to support from business POV.
Also I see people categorizing all project deficiencies as technical debt where what they should be doing is to first establish what would be reasonable expectation regarding quality and then the debt is only what would be absolutely necessary to reach that reasonable expectation.
So for example, if you make a small app that will not reasonably see a lot of future development but is critical to work reliably in production (and it isn't) your debt would most likely be centered around making the application reliable enough and probably not around making the code nice (as long as it isn't preventing makeing the application reliable).
This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends.
I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess.
I don't care what your code looks like if you did not achieve a good end-product.
Is that a good metric to judge a developer, though? Good UX requires either formal training in the field, or a very gifted individual. In my opinion it has very little to do with the quality of either the code or the developer.
To have baseline UX awareness is crucial for every developer on any team that sets out to build a great product, just like any effective designer has to be aware of physical limitations of his design space (for example speed of light, bandwidth)
If your UX designers job is to point out that responsive UI is indeed important for your product, he is not actually doing UX design and you are likely in deep trouble.
Apple and Google shouldn't fire their best compiler/JIT writers just because they write lousy GUIs.
A designer is not responsible for making sure that the implementation of their design runs at stutter free at 60fps in a browser -- that is an engineers job. If the engineer who implements such a design is insensitive to these things and needs convincing that it's important to not have the implementation not stutter, jerk or jank you are never gonna get good results.
I do care if your code is a mess if other engineers have to maintain it.
My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.
But what if you have a component here or there with well defined, well tested interfaces, but internally it's a bit of a mess? Or what if you hack together a proof-of-concept for a new feature to get it out the door and see what users do with it before investing a lot of time in making it perfect? Those kinds of things can help your organization move faster.
As with most things, clean vs messy code is not a binary. It's the sum of a lot of individual value judgements about when it's pragmatic to focus on code quality.
Even so, I am inclined to argue that in most cases the exact opposite is true. That is, it is actually “easier” to create a “good product” with a messy codebase, because in most cases “easier” and “good product” are understood by primary stakeholders to mean business value at this moment.
- One coder writes his product with a high quality code base.
- Another coder sits next to 3 users of his product, and hacks stuff in as fast as possible.
I would bet on the 2nd one for having the better user interface.
And that, of course, has it's exceptions too. Non-optimized stuff exist, and everything that isn't on the optimum line can be improved in some way without drawbacks. Besides, the optimum line is always moving.
- How certain are you that you didn't introduce a bug? - Is it also running faster on this exotic platform that we still need to support? - Did it involve API changes? - Do we need to put this into production now, or wait for the next optimization to save some time? - How much time did we spend on this? Was there something else that would have made a bigger impact?
In theory you can improve things without drawbacks, but in practice you always have to make the right trade-offs.
Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?
See "Unity build".
"Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less.
Clean code doesn't mean "no bugs" and "good software":
- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example).
- I've seen a terrible mess of code, that was practically bug free (because it was running for years in production). And have seen that same code refactored to clean code by a junior (who thought he would 'fix things'), and introduced a lot of bugs (because that is just what happens when you write code, even clean one, even by a senior developer).
If you deliver a final product (such as a game for example), that will not need extra features, you can hack stuff in at the end. When you would hack code together at the start, you will shoot yourself in the foot by needing to go through your mess all the time. But when you do this at the end of the project, you can save time by adding in quick hacks. The technical dept that you introduce doesn't need to be paid off. Of course you cannot do this with a long running project. But with a deliverable product go right ahead.
The main thing that you have to consider is this: EVERYTHING IS A TRADE-OFF. I see juniors make this mistake all the time, selecting the best programming language, the best VCS, the best whatever. You know, that 'best' thing also has drawbacks. So it's always about making trade-offs, selecting something despite the drawbacks, because of the benefits.
General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet.
How to make the proper trade-offs? Experience ;).