Agile Zone is brought to you in partnership with:

Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Stumped by a Problem? Try Coding Less

05.08.2014
| 18228 views |
  • submit to reddit

Running into challenging situations or problems is a fact of life in software development. From complex coding constructs to tricky phantom bugs, programmers spend many hours traversing their own minds in search of the right answer. Unfortunately, this brain spelunking doesn't always yield consistent results. At times the problem seems obvious, while on other occasions, it seems to hide behind a subtle impenetrable veil. This shroud can be very aggravating to developers. In these moments a stubborn few push on, but most give up and set the problem aside. Then, at some point in the near future, without provocation, the solution arrives like a rushing tidal wave. Sometimes it happens during a seemingly unrelated conversation or while driving home from work. For some, the solution wakes them up from a sound sleep or is the first thought after waking. Why is this?

The answer is simple and often overlooked. Software development is not natural. Although some can excel at it, no one is born with the knowledge of programming. It must be learned. Developers are responsible for converting concepts into reality using a vast array of flexible, yet rigid constructs. For most developers, programming is the most mentally taxing activity of the day. At times this thought is lost or forgotten. Similar to the religious concept of the Sabbath, a day (or time) of rest is important for developers. This programming break does not require absconding from all technology. It's an opportunity for the brain to slow down from the high cognitive load brought on by activities such as programming and problem solving.

In software development the temptation to stay late, work through lunch, or indulge in marathon sessions is far too easy. Developers rationalize these actions with thoughts such as "I need to stay heads down," "I just want to finish this," or "I can figure this out." Although these actions are honorable, it's important to recognize there is a point of diminishing returns. One area of concern is developer burnout. Taking time after work and on the weekends to break away from development is vital. Watch a movie, play a game, attend a concert, go shopping, enjoy a sporting event, spend time with family/friends, volunteer, etc. These activities can be wide ranging but all have one thing in common. They are low effort tasks. They provide the time necessary for the brain to relax and refocus. This is a hidden key to programming success.

Published at DZone with permission of Zac Gery, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lund Wolfe replied on Sun, 2014/05/11 - 3:37pm

Completely agree.  I thought you were going to say "when the going gets tough, simplify, simplify, simplify".  How did we get into this convoluted mess?  How do we get out?

The mind wants to work, but only for so many hours a day, awake or asleep.  It seems like most people want to work hard but not smart.  Give them an "A" for effort.

Wait until the answers are simple and obvious.  When the mind is tired and low on blood sugar it will make bad judgements, play it safe or take shortcuts (with solutions that don't fit the problem), and do more harm than good.

Raging Infernoz replied on Wed, 2014/05/14 - 3:56pm

Yes, trying to burning both ends of the candle can give diminishing returns, waste time on blind alleys, or cause nasty new bugs, when you really should eat a proper meal, and let your subconscious and REM sleep digest the situation and spawn ideas; however some problems can't be solved just in your head, but rather require you to persistently dig by iteratively tweaking code, and adding breakpoints in (Java) API call trees to find API quirks and nasties * e.g. for the Stripes Java web framework where there is inadequate config. validation and shameful namespace booby traps in the example war project!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.