As a very HN-y analogy: there's a reason programmers don't debug purely by static analysis. They don't just stare at the code. They do step-throughs. They look at logs. They tweak things and see what happens. They experiment and learn from their experimentation. A program is about as controlled and isolated an environment as you will ever have in the real world, and even in that domain, pure analysis is rarely sufficient.
Amen to this. Doing is a strong teacher, sometimes the only teacher.
Mistakes and failure are awesome and underrated.
Of course, that can go too far in the other direction, because empirical results are often driven by factors outside your control too. So you do need to be doing analysis and not just looking at results. But analysis alone doesn't get you there, even if you're extraordinarily brilliant (and, statistically, you probably aren't).
The tendency is to think ALL complex problems can be solved if I just have the right info, the right skill, the right people, the right resources, enough time etc etc. But for some problems the stars will not align. In those cases what do you do?
You have 2 option - 1. pick a Simpler problem where u do have the info, skill, resources, people, time to ensure the outcome is going to be positive 2. pick the complex problem but accept you are not going to solve it completely.