1) When adopting tools, methodologies, and practices, think about /why/. Don't use things because they're "good practice", look at what problem they solve, see

1) When adopting tools, methodologies, and practices, think about /why/. Don't use things because they're "good practice", look at what problem they solve, see if they solve your problem, adopt or adapt accordingly. If you're going to use design patterns, great. But don't argue about the exact official gang of four definition of the facade pattern - a more productive conversation is about which specific bits of the pattern help you solve your problem and which are an impediment. Tests great, but when you're just starting a brand new project where the behavior and spec is changing as you build and learn, should you suffer through brittle unit tests because "not testing is bad practice", or could you perhaps start only with integration tests, and wait a little bit until you start doing anything more granular? Complex git branching / release / hotfix / etc schemes can be great in a larger organization, but when you're on your own, do you really need all of it or is it too much overhead? If you don't have a staging environment, should you have a staging branch? Summary: a) Am I actually trying to solve a problem? What problem am I trying to solve? b) Is this thing going to solve my problem or a problem that I don't have? c) What can I change so it /does/ solve my problem? 2) In a large enough codebase, there is always bits that are shitty for a variety of reasons involving bad programmers, bad practices, no practices, bad requirements, terrible deadlines, old tech, whatever. You don't /want it/ to happen, but it will. Or perhaps you'll be dropped into that codebase, and so you'll have had no say to begin with. An unappreciated part of the practice of software architecture is about containing current and future shittiness, stopping it from spreading, managing the risk around that, not allowing that to impede current development, setting up a surrounding architecture, getting people on board socially to do the right thing, having a good plan to replace it and acting on that. "No new code until everything is clean and tested" sounds so valiant, but I'd like to see it happen in a 100 person organization with bills to pay. Alternatively, after you've contained things, then you can feel free to adopt such policies at a smaller scale within well-defined regions of the code.