> The user doesn't know how the codebase looks. The user just sees what features that product is offering. So don't get overly attached to your clean and elegan

> The user doesn't know how the codebase looks. The user just sees what features that product is offering. So don't get overly attached to your clean and elegant code. Focus on shipping the feature on time and bug-free. This is a slippery slope. True, the user doesn't see the code. But they do see the feature set (or lack thereof), and the speed at which you're able to update that feature set to suit your customers is a function of how easy the code is to change. In turn, that ease of changeability is a function of how easy it is to read, maintain, and reason about. Focusing on "shipping the feature on time and bug-free" is good, but at the extreme it can lead to the mentality of "I'll fix the tech debt later", with "later" being indeterminate. Which is when the old saw about tech debt being like credit card debt starts to bite one in the ass.