> Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the pro

> Besides that, I'm a huge fan of disposable code. In my experience 99% of the time, the best approach is to just dive into the problem and try to solve the problem My approach is slightly different. I think for a while and then start on the path that gets me to what I think is a common case. If the whole seems more complicated than reasonable, I back out the part that seems to be troublesome. Eventually, I get one case "working". That case might not be complete, but it does something. I then work on an adjacent case, using the same "back out the troublesome" process, going into a bit more detail (or perhaps deciding that some detail on the first case was wrong). I repeat "work on adjacent cases" until most/all cases are handled. As I do more cases, I use opportunities to reduce the cognitive footprint.