There are many reasons to write software: for fun, for learning, as a hobby, often as a job. In our context, as an application developer team, we write software to solve business problems.
Few people care about the intricacies of programming outside the developer community. What people crave are solutions, regardless of the implementation details.
When it comes to decisions about technology or processes, the fundamental question then should be: how will this move the project towards the ultimate goal - delivering a solution?
This type of thinking can prevent technology choices that are motivated only by curiosity (also known as "CV Driven Development") or the imitation of others.
Create a minimal end to end journey as soon as possible. Treat it like a skeleton and add the "meat" later. A working draft brings clarity by serving as a roadmap towards essential goals. Knowing where to go helps avoid getting bogged down in details (over-engineering), leaving no time for crucial features (under-engineering).
Code is a means, not a goal. Writing more doesn't necessarily help. Adding code is not always the answer - keep the priorities in mind.
Clients expect software systems to work for an extended period and also to evolve as requirements change. So we can't be too myopic. But today has priority over the uncertain future.