I don't know. I think the key is just knowing how to prioritize. Sometimes it makes sense to go deep, especially if the problem is causing a lot of expense. Other times it's important to work on other problems.

Right now we're refactoring our codebase from one language/framework to another. Identifying which parts are still maintained and need the refactor vs. which parts would be a waste of time because a developer hasn't touched it in years is important.

This is especially important if you're one of few/sole engineers on a project.

"that's what she said."