Posted On: 2020-03-16
When developing, I sometimes find myself getting into a groove: quickly solving every problem that comes my way and generally making very good time in implementing a particular task. Whenever I realize this is happening, I will make an effort to schedule two specific, highly important details into my work for that day:
Taken together, these two can lead to some seemingly odd behavior, such as working straight through regular lunch hours, only to suddenly stop and take lunch as my peers are packing up to go home. It can also impede scheduling time with others (such as lunch or dinner plans), as it can be hard to predict whether I will be working straight through a regularly scheduled break on any given day. Nonetheless, I have found that diligently adhering to these two items, together, is the best for both my productivity and the quality of my work.
On the face of it, there might not seem to be anything particularly odd about trying to stay focused for as long as one can. One might reason: "if I'm highly productive right now, I should try to stay that way." One might even take that intuition to an absurd extreme by assuming anything less that complete focus is a productivity failing*. Yet both those ways of thinking overvalue the productive time, and fundamentally miss the benefits associated with the breaks themselves.
While it is true that being able to stay focused is nice (it sure beats being distracted), the main reason I let it drive my schedule is all about timing the break itself. Breaks are a precious resource when programming*: time away from the task can inspire a new perspective or help one solve seemingly intractable problems. A well-spent break can re-energize the mind, helping one stay optimistic about one's possibility for success**. Above all, a break is an opportunity for the mind to clear out its otherwise cluttered short-term memory (the "RAM" of the mind, if you will); all the little details and nuances of the code that one must constantly juggle while working can be safely forgotten.
After a break, one will return to the code as a stranger* - what works and what doesn't won't be immediately obvious, and one must spend time refreshing oneself on all the little details that control its behavior. Importantly, this makes it possible to catch bugs and possible improvements that one might have overlooked, since one assumed they were working correctly. Suddenly, something that seemed "done" will now appear flawed - giving one the opportunity to revise and polish up things that one hadn't even seen before. In this way, adding a break to one's coding habits makes it possible to achieve a higher quality of code than one might otherwise have.
If one incorrectly times a break, all the benefits can be converted into significant penalties. Code that is misbehaving or not compiling can be difficult enough to debug when one is intimately familiar with it, but it is much worse if one is unfamiliar. Likewise, code that is technically working but incomplete is simple to extend while one is familiar with it, whereas it will take a stranger time to get up to speed before making changes. Finally, any small flaws or unrelated bugs that one might discover as a result of gaining a fresh perspective are distracting when one is only partway through a task: rather than being able to be immediately investigated and resolved, such items need to be set aside and saved for later*.
Nothing beats a well-timed break - not just for morale, but for productivity and code quality. Getting a lot done in a short amount of time is useful, sure, but following it up with time spent revising that code to make it really shine is invaluable. In my experience, virtually all code needs to be revised before committing it to the project (many teams have mandatory code reviews to accomplish this.) Effectively timing a break can be a massive help for accelerating the revision process - and one of the few tools available for developers working solo.