"Oh, heh, cute that scientists need to confirm what's clearly obvious to me." Often with an anecdote about how they've always known it, and with an explanation about how it works (obviously) which you think would be unnecessary if it was such common knowledge.
When we realize it's not common knowledge, we get excited and/or become proud of ourselves, and explain what we think to indulge ourselves (because we were just given evidence that the knowledge isn't as common as we thought).
It is pretty common to explain sleep as when your mind cleans up and store stuff in long term memory. From there it is largely a point of view distinction between “keeping stuff you want to save” and “throwing away stuff you don’t want to save”
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.
On the other hand we might ask, is three 8 hour days better than six 4 hour days? What if there are break days in between the 8 hour days? Maybe only the first night of sleep on a new program is particularly effective. Who knows.
Empirically I'd wager most of my coworkers had similar habits, although the people I believed had more overall mental capacity than me did seem to have a much quicker ramp up time on just about anything.
It's exploitable, too. Health concerns aside, it seems like if someone needs to crack some really hard problem, then they might:
1. Prepare by deep sleeping until the mind's a blank slate.
2. Start working on the problem while avoiding deep sleep (to avoid wipes) and extraneous information (to avoid junk that'd force you to get sleep).
3. Upon completing the problem, thoroughly document (the mental copy's about to get shredded), then sleep it off.