This is a fantastic perspective on managing ignorance. It is told from a personal perspective, but there are fascinating applications of this at an organizational scale.<p>My initial thought was that the primary challenge here (which the author addresses in part) is in estimating the time it takes to complete a task. If you already 'know' how much time something is going to take then is there really uncertainty? How much uncertainty? The author seems to be going in the right direction, but there seems to be something more here about sources of ignorance that touches on the number of special cases in the problem space, or something of that nature. I wonder if there is any work trying to infer the number of special cases, or 'practical realities' of a problem space (maybe a kind of roughness, inhomogeneity, or irregularity?) that will ultimately be the major time cost.<p>Another thought is that 'bad' negative results don't have the provenance required to rule anything out, but if you know exactly what was done then you have much stronger evidence about where the problems might lie.<p>Finally this is deeply connected to another issue which is that sometimes we don't have the resources to devote to solving the really big problems so we never even try. The economics of cutting edge research only serves to drive us further from the hardest questions because we don't have anywhere to start because we haven't the faintest idea why we fail.<p>Somehow this reminds me of my first play-through of Darksouls -- the only thing that kept me going was the belief that it could be completed. My repeated failures were required for me to slowly gather enough information to see where I was going wrong. Funding basic research that is truly at the edge of the unknown is like only funding noobs that have never played before, or maybe more like funding good players from one game that come to another, they'll get there eventually, but they have to be able fail, and if you make them play Ironman mode then we might as well give up -- the game is too hard.