Although the nature our work varies quite a bit, here are some things that I have found in my domain (earthquake-related science broadly, with a large computati

Although the nature our work varies quite a bit, here are some things that I have found in my domain (earthquake-related science broadly, with a large computational component) that I think generalize fairly well: 1. Tightening feedback loops as much as possible. This means both recursively breaking down the problem into subproblems (as discussed by the author), and having very fast ways of doing formal testing, sensitivity testing, etc. Sometimes I'm working on a problem where I have to solve a system of equations that takes a few hours. This means that progress is really slow and I just won't be able to turn all the knobs that I want to or try alternative approaches. If I can subsample the data or the model domain down to 20 minutes, then that gets better but I still need to do something else during the downtime. If I can get it down to 2 minutes, then I can really make progress and if it's a few seconds then I can fly. To do this I might have to invest a few hours or a day into making a testing dataset and environment that allows for very rapid iterations (but may not be useful once the particular issue is addressed), but I am often averse to doing because it feels like a waste of time, even though my velocity averaged over the month is usually higher if I do it. 2. Work on the hard problems first. This is in contrast to what the author suggests but I would rather take the bull by the horns knowing that once I address the hard parts it's going to be a lot easier. If the hard parts loom in the distance I worry that I will run out of time, because even on the easy parts it's possible to spend all of the time making small tweaks. Do the hard parts, or at least a draft implementation, first so you can allocate your time over the project more efficiently and ensure that you're not going to blow up when you're 80% done but just hit a massive roadblock.