Make it work, then make it pretty.
Undelivered pretty code doesn't deliver any business value.
Same applies to 100% code coverage that isn't running on customers computers.
Undelivered pretty code doesn't deliver any business value.
Same applies to 100% code coverage that isn't running on customers computers.
There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.
Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.
It is a balance that needs to be learnt, and a trait of seniority.
This philosophy less relevant in larger companies with more engineers also.
I get your point, I just question the specific example.
Make it work and make it as straightforward as possible.
The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.
So you better not tie your self worth to the quality of the things you produce.
You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them.
You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.
See also: https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).