> I think the common understanding is the opposite. That you are better off thinking about the problem 4 hours today and 4 hours tomorrow, than 8 hours today.

> I think the common understanding is the opposite. That you are better off thinking about the problem 4 hours today and 4 hours tomorrow, than 8 hours today. I think it depends on the problem being solved. If it's a separable problem, then we can attack it like we code up object-oriented programs: this is, we come up with an overall design, break it into pieces, then do those pieces individually. Separating the logic like this vastly reduces the complexity of the problem space. But, I hear that before object-oriented programming and such, programmers used to make really confusing programs in Assembly, relying on unstated assumptions about what states the program could enter, leveraging `goto` statements in ways that'd get people fired today, etc.. I think that if you're able to attack a problem using separable logic, e.g. object-oriented design, then you can fairly readily complete a smaller part of it, then go to sleep. Sleeping'll help reset the mind, but still leave enough information about how the coded parts work to continue later. But if you're working on certifiable abomination of Assembly where the program logic is critically dependent upon all sorts of ideas you have in your head, then you've really gotta finish programming it in one shot -- if you sleep, then you'll forget that the `int` that shouldn't ever be `10` can be `10` in one particular edge case, then everything else will break in a way that no one could ever untangle. I think the core quality that makes some problems hard is not knowing a way to break them down, because they're these huge, floating monstrosities where every little thing is inexorably dependent upon every other little thing, much as in that Assembly-programming paradigm. It's in those cases that skipping a good-night's sleep can make sense. That said, I completely agree that breaking a problem down into parts is great whenever possible.