I don't remember where I saw this quote, but... "It's okay to half-ass something, when all you need is half an ass".
EDIT: Totally agree about the 'important mindest for startup', I had a similar eye-opening experience, working in a startup with 'cowboy' code that was actually quite good, but I had to unlearn a bit of stuff I read as a junior/mid-level developper.
It was code that was well-architected, had well-concieved data structure, and had business value, but every "professional" coder would deem bad-quality, since it had no unit test, did some stuff unconventionally, and probably would have many linter warning.
Most scenarios only warrant fractional assing. Also this philosophy provides the opportunity to say “ok guys, this time… we have to whole ass this one,” which is always fun.
Well-architected + well designed means you can go back later and fix the code if the project survives. I'm hitting this personally right now - the amount of code I can write is dwarfed by the amount of features needed to get something like a working demo out the door - I can spend time and make every thing perfect, or I can squint and imagine how I will implement fixes later and focus on making sure that I don't have to rearchitect.
Ask yourself: Will the amount of work it takes to "do this right" increase over time? (And by how much?)
I drew some quick placeholder art for a game I'm working on for fun. One day I might sit down and draw some good art, but not today. When the day finally comes to finish the art, the difficulty of creating that art will be no greater than it is now. In fact, with improving art tools, it may be easier to do later.
On the other hand, if I'm not quite happy with my database scheme and I want to change it, I can spend a day on it now, or I can spend--based on my experience--months on it in the future. In fact, there's a good chance if I don't fix the database schema now, it will never be done.
But aren't unit tests the half-assed solution? They are a wonderful help if you want to deliver something fast, but if you had more time you'd probably do something else.
It doesn't get said enough that unit-tests are not the ultimate in good code. There's a lot of shitty code with unit-tests, and there's a lot of really good code with no tests.
That's true, but a codebase without unit tests is apt to be deemed poor quality by professionals due to the time factor. Being able to release fast is an important quality of business software. Professionals don't look for perfect artistry, they want to see painter's tape in the right places to get the job done efficiently.
EDIT: Totally agree about the 'important mindest for startup', I had a similar eye-opening experience, working in a startup with 'cowboy' code that was actually quite good, but I had to unlearn a bit of stuff I read as a junior/mid-level developper.
It was code that was well-architected, had well-concieved data structure, and had business value, but every "professional" coder would deem bad-quality, since it had no unit test, did some stuff unconventionally, and probably would have many linter warning.