> This reminds me of advice I give to junior devs who over-complicate things in the planning phase: "Start with the stupidest thing that will work".
> You need to make something work before you can make it work well. You need to start simple before you dig into the complexity. Sometimes you find that the "stupid" solution is good enough.
100% true.
People love to dig at Test Driven Development, but it solves a common problem and is great for junior developers because it has 3 important rules.
1. Understand your requirements. And not in a wishy-washy hand-wavey way. But in an explicit, expressed as a single test verifiable/falsifiable requirement.
2. Implement the simplest solution that meets your requirements. Don't over-engineer anything, don't chase the latest fad, don't sleeve solve a way more complicated generic problem that you think we'll hit later, because you don't have enough experience to know how likely we are to hit it and the costs to make that tradeoff.
3. Keep you codebase clean and well factored. Don't let cruft and hacks build up.
Ignoring TDD, any junior engineer that can consistently exhibit those three behaviors is almost by no longer a junior engineer. Those are hard things to learn as an early coder.
Yes as you become mid-level and senior you should be more independent and break the above often - but at that point you have good foundations and the experience to make the tradeoffs to know when to deviate and by how much.
TDD is a very effective method for solving a problem that otherwise often takes a while to solve. Developing good fundamentals.