Principal Software Engineer | React | Next | Astro | Node | JavaScript | TypeScript | Python I write what I wonder✍️
Unpopular opinion: There’s no such thing as universal “best practices” in software engineering. I've watched countless teams slow themselves down by following "best practices" religiously without questioning whether those practices fit their specific situation. What works brilliantly at FAANG scale can cripple a startup. Practices that empower a 5 person team often collapse under a 50 person organization. Even celebrated design patterns become anti-patterns when applied without thought. The truth? There are no universal best practices, only good practices in the right context. The Real Problem "Best practices" have become intellectual shortcuts. We treat them as immutable laws instead of what they actually are: solutions that worked well for specific problems, in specific contexts, at specific points in time. But context changes. Team sizes evolve. Requirements shift. Technology advances. Yet we keep cargo-culting practices that may no longer serve us. A Better Approach: As engineers, our core skill isn't memorizing rules, it's making informed trade-offs. Before adopting any "best practice," ask: Best for whom? (A 10-person startup or a 10,000-person enterprise?) Best for when? (Early-stage exploration or mature, stable systems?) Best for what trade-off? (Speed vs. reliability? Flexibility vs. consistency?) Question the context. Understand the trade-offs. Adapt the practice to your situation or abandon it entirely if it doesn't fit. Because the best engineers aren't the ones who follow all the rules. They're the ones who know when to break them.
It all depends where your product is at the moment and what trade offs you can afford? Every product goes through certain stages one approach would work best for you but when there is shift in the product your previous approach may needs revision.
Software Development
1moyup, at the end of the day everything is prone to some trade-off