I do not agree tactical programming should be used most of the time. It's much better to learn to do strategic coding fast. Yes, we need to cut some corners from time to time, but without understanding of what one is writing (inability to name variables, ignoring not-so-happy paths, overlooking failure modes) one should not write code at all. Mindless typing code in is the major problem in the industry. Everyone writes better code with growing experience, but instead of switching tactical/strategic "modes" of coding, it's far better to just learn techniques to code right first time, think about the task and it's wider context, ask for missing problem domain knowledge. And surprise! When one does it, he or she can be faster. I do not propose TDD, but many times writing unit tests in parallel makes you faster as well, provided you learned to write testable code and tests. Documentation may require some extra time, but if the code is clean, then the need for documentation may remain minimal. And actually careless code may require more documentation, because it may not reflect problem domain faithfully, contain arbitrary constraints where corners were cut). Having controlled technical debt is a business decision, but then novices working in a very early startup is bad idea - hire those, who knows how to program with longer-term outlook... or fail.

Also form another perspective. Codifying something in software is actually gathering knowledge about the problem domain. If the knowledge is messy or contains careless mistakes, coding is useless.