I will add a personal anecdote from software development. On one project I had a difficult objective (to write a database that met certain criteria). I had neve

I will add a personal anecdote from software development. On one project I had a difficult objective (to write a database that met certain criteria). I had never done database work before. For the first year, I worked with almost no supervision and developed a routine where I would select an area to work on, give it a week, and if I could find no good solution, would switch to something else. All the while I read many related technical papers. Often after a couple weeks of "not working on the problem" I would think of a clean solution and implement it fairly quickly. After that year, I got a new boss who insisted that I schedule my work using agile techniques, which meant that when I started something I had to focus on it until it was delivered, while trying to meet my estimates, planned to at most a two-day delivery cycle. My productivity in the second year was terrible and much of the coding I did then sucked, as it was full of hacks designed to make my first, sloppy approach work quickly. For me, downtime, and reading papers that were indirectly related to my problem area, vastly increased the quality and quantity of work done.