We are talking about research code here. And from many of the comments, it seems like the biggest hurdle is not understanding requirements the first time around

We are talking about research code here. And from many of the comments, it seems like the biggest hurdle is not understanding requirements the first time around. This is incredibly common. I work in computational biology, and my normal thought process is that by default, you should expect to write the code three times (especially for less experienced developers). The first time, you don’t know the problem. The second time you’ve figured out the problem, but don’t know the best way to do it. The third time, you’ve figured out the problem and a decent strategy to solve the problem. With more experience, you can narrow that to just two iterations. But really, especially with research, you rarely have a good feel for the problem domain the first time around. And when you have the expectation that you’re going to throw the code away, you don’t get quite as hung up on implementation details for the first two rounds. And because of that, the process is easier. And you don’t have to worry about refactoring bad code. Just accept the first round as an experiment and take what you’ve learned about the problem to write better the next time.