Estimating work in a new problem domain is challenging (as if estimation in software wasn’t hard enough already). It’s more challenging due known unknowns and unknown unknowns.
Consider a problem domain you know well. You know what you know and have a good idea of what what you don’t know. If you don’t know something then you’re also likely know how to answer your questions. In other words, turn a known unknown into a known known.
Now consider a problem domain you don’t know well. You don’t know what you don’t know. That the unknown unknown. They’re also likely known unknowns (the “here be dragons!” type areas). The uncertainty from known unknowns and unknown unknowns may be paralyzing enough to prevent exploring and experimentation. That’s the key activity for converting unknown unknowns into known knowns.
This is where engineers need to swap their hats. When working with knowns then executing is a straight forward process: make the change that meets the requirements. When working with mostly unknowns then solely focus on learning: convert unknowns into knowns.
Each mode has different outcomes. The first mode produces functionality in terms of some concrete deliverable like commits. The second mode produces information as an input to mode one. Work product from this phase should be discarded because its experimental by nature.
Real productivity comes from being able to toggle between these two modes depending on the task at hand. Some tasks you may be able to just pull up the keyboard and hammer out. Other tasks may require much more experimentation and learning to even to the point where you can consider a theoretical solution.
Alternating between these to modes is expected and intended. Everyone has unknowns. Some are just better at the process for converting them into knowns.