[rachofsunshine]

I'd argue for a third option: don't try to solve it by sitting in your chair. Go out and work on the problem, and see if what you're doing is improving it.

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.

[TheCleric]

A mentor put it this way to me: you can't steer a stationary ship. The ship has to be moving for the rudder to work, and therefore it's better to be heading in the wrong direction (where you can turn around once you figure that out) than to be sitting still, doing nothing.

[WarOnPrivacy]

> I'd argue for a third option: don't try to solve it by sitting in your chair. Go out and work on the problem, and see if what you're doing is improving it.

Amen to this. Doing is a strong teacher, sometimes the only teacher.

Mistakes and failure are awesome and underrated.

[rachofsunshine]

I've grown a ton as a person from my work, and one of the biggest things I've learned is how easy it is to have confident, empirically-supported, well-argued, and totally wrong opinions. There's no better way to test your views than to bet on them and put them out into the world - even if they don't work, you'll learn something.

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).