One of the great killers of software projects, its potential and the commitment of (future) assigned developers, is going fast and making a mess in the process. The video at the bottom, describes tactical vs. strategical programming in a nutshell.
What can a developer do to combat this?
A first would be to educate oneself on topics revolving around clean code and clean architecture. More specifically, in the principles and patterns resulting in such practices. Although there are many books and videos to learn from, working with a peer developer who applies the above, can be invaluable.
Think critically about the code you write, "Think twice, code once.". Improvements can range from the usage of logical operators to leveraging external solutions, and productivity-boosting tooling, ...
You can often write it with fewer lines of code and improve its readability for your teammates. Aim to leave a codebase in better shape than you found it. Take it one step or one ticket at a time, and separate yourself from the "code monkeys".
Optimize and fully utilize your tooling for increased productivity while minimizing code smells or bug potential. This encompasses the features of your programming language, frameworks, IDE plugins and beyond automated release cycles. Don't "half-ass" or refuse to evolve the above since that will only decrease productivity over time. There are plenty of proven systems to adopt, no need to reinvent these.
I can see how, from a business perspective, tactical programming might appear to be praised in the short term but will lead to technical debt in the long term. Sooner rather than later. As tactical programming has its perks, it's the least advisable approach to be used beyond a concept phase.
What can an employer or project manager do to combat this?
Hire proven, quality competence for your back-end systems. As quantity in years might improve your odds, it's unfortunately not a guarantee. Recruiting for battle-tested programming language frameworks might improve the odds. Once obtained, it's an idea to pair them up with rookies on a new project, when possible.
In time, your development team might live by great coding practices, delivering highly maintainable projects which in turn frees up time for bullet-proof technical decision-making. Don't allow for bad practices to train your rookies, as described in the video below.
Entertain your developer's requests for improvements or refactoring. Involve them (more) in crucial technical decision phases. Phases to tackle structural or procedural improvements should have a place in any software project. Not to be shrugged off as "unbillable". It pays in the long run by preventing frustrated developers and dissatisfied clients.
If possible, don't take on existing projects another tactical development team already ran through until they could no more. You're likely to repeat the cycle the video describes. If you do, be very transparent about it to your development team or new hires. It's dirty work.
You don't have to take my word for it, watch the video, it describes many software projects. Clean Code - Uncle Bob
If you are interested in seeing more of my work, you can find it:
on my website: kiss-code.com/products
on my Patreon
on YouTube
Subscribe to my newsletter to stay up-to-date & receive discounts.