I don't think it's about time/schedule but rather intensity. I would agree in that the majority of application code really is just little bits of accumulation - piling on another feature or fixing another bug. Those are things you do optimally if you're lazy, knocking off a few each day while spending the rest with non-coding tasks. And with those tasks the slow pace is beneficial in giving yourself room to examine all angles and stop yourself from a trap later on.
You only need to pull the long hours when a big impact is really needed - generally, learning something new or introducing major new concepts into the codebase. With those projects, slicing up the hours is detrimental to understanding of the problem. You still don't want to make an unnecessarily complicated solution, but long hours make necessary complexity easier to tolerate.
You only need to pull the long hours when a big impact is really needed - generally, learning something new or introducing major new concepts into the codebase. With those projects, slicing up the hours is detrimental to understanding of the problem. You still don't want to make an unnecessarily complicated solution, but long hours make necessary complexity easier to tolerate.