
Want to write some code? Get away from your computer - robintw147
http://blog.rtwilson.com/want-to-write-some-code-get-away-from-your-computer/
======
psadauskas
I find I solve the trickiest problems in one of three places: Walking my dog,
taking a shower, and laying in bed trying to fall asleep. I find that stepping
away from the keyboard, and my programming environment entirely, allows me to
let go of all the basic assumptions I hadn't even realized I'd been making.

~~~
revorad
This is often repeated by a lot of people, but I think it might be affected by
a bias. Perhaps we notice more when we solve problems away from the keyboard
because we are not supposed to be working then. Perhaps we selectively label
those the trickiest even though we solve many more problems staring at the
monitor trying really hard.

~~~
dspillett
There is certainly some confirmation bias going on in these reports, but I
must say I sometimes find walking away from the problem for a short while
(looking at something else, taking a relaxed lunch instead of eating at desk,
just nipping out for a few minutes of fresh air, or just chatting to a
colleague about something related or otherwise) can work wonders.

Sometimes a relevant idea will just come to me while I'm away (I carry a
pencil and bit of paper for such occurrences, as it is very annoying to get
back to my desk and forget the beneficial train of thought!), sometimes I'll
hit the problem from a slightly different angle when I get back and find
success that way.

I think mainly the difference is usually stress. Forcing your mind to think
about a particular problem can drive you into a mental rut in which you think
the same things over and over and get nowhere, getting more irritated at your
lack of getting anywhere as time goes on which creates more stress and makes
matters worse. At times like that inspiration is less likely to strike (or be
recognised when it does). Having time to ponder a problem, consciously or
otherwise, can be very fruitful.

This fits in quite nicely with the idea that the sleep pattern we've evolved
is as much about rearranging what we've learnt and experienced while awake as
it is about anything else (like the brain's DBA taking time to run DBCC
REINDEX on everything so our thinking is more efficient the next day). It also
tallies with the fact that some of the most successful people I know are
generally more relaxed (and not just because they are more comfortable due to
earlier success) than myself!

------
sliverstorm
_One of the best lessons I learnt from my first boss was: “when your code
doesn’t behave as expected, don’t use the debugger, think.”_

Can't entirely agree. I'm not a grizzled programmer, so sometimes when I'm
coding for microcontrollers the debugger winds up teaching me about some new
quirk in architecture. It's often something I was aware of (endianness, some
of the finer details of addressing) but had not yet actually dealt with in
person.

~~~
ChuckMcM
It drives me nuts when people 'fix' things by making the symptom go away
without understanding what causes that symptom in the first place.

~~~
glenjamin
When used correctly a debugger will help you unravel the root cause of a
problem, I don't see using one as a route to just fixing symptoms.

~~~
jerf
A poor developer uses his tools to cover up the symptoms. A good developer
fixes the root cause. The ability of the good developer to fix the root cause
quickly and efficiently is bounded by the quality of their tools. If you want
to claim that a good developer will find it no matter what, fine, but don't
tell me the developer with better tools won't be able to do it _faster_ ; it's
almost the definition of "better tool". I find it very strange how people just
write off using a debugger, ever, for any purpose, and think it labels them as
a _better_ developer, as if a carpenter who refuses to use a plane under any
circumstances is thus a better carpenter for resisting the temptation to
easily-smoothed wood. (The fact that a plane is good for more than that is
deliberately part of my point.) It isn't the best solution for every problem
and I certainly don't reach for it directly, but when you need it, you _need_
it.

~~~
prodigal_erik
The root cause of every problem is that I don't fully understand my code. A
debugger can only show you what the code happens to do in one particular
scenario. The fear is that people are doing that and fixing only obvious
mistakes as a substitute for static analysis and diligent review of the code
leading to a correct model in their head of how it would handle _any_
scenario. It's like declaring a bridge to be sound because you could
successfully send one truck across.

~~~
jerf
"Doctor, it hurts when I do this." "Don't do that."

That fact that _other_ people can misuse a tool is a really stupid reason to
not use it yourself. I've had great success in using debuggers to identify
which assumption I was wrong about when the code did something unexpected. If
you're _so awesome_ that you never make bad assumptions about your code...
you're probably not pushing yourself hard enough. Perhaps that's your job's
fault. I'm pushing myself to my limits in my job, and I'll take all the help I
can get.

------
wslh
This is good mostly for algorithms but for system software (drivers, a lot of
different technologies involved) is impossible because issues are outside of
your control, without debugging you'll lose 100x of time.

~~~
wildanimal
Agreed -- the author of the post is talking about writing or debugging
algorithms; coding is the stuff you need your computer for.

------
ChuckMcM
In many ways the responsiveness of the machine can work against you. Back when
the Amiga was a hot machine to work on there were two compilers Lattice C and
Manx C, Lattice was the one sanctioned for development and it took a long time
to compile and link, Manx on the other hand compiled really really fast. A
number of developers discovered that the fast compiler had a weird effect of
making it easy to try lots of things quickly, rather than contemplating what
you needed to do next.

Then recently Randal Munroe published an XKCD cartoon on attention deficit
management [1] which when I saw it, it really resonated with this same
experience. Basically by slowing things down, quality improved. Clearly there
is a fundamental principle here somewhere, something along that lines that
there is an ideal pace for development (perhaps unique to each individual)
where going faster or slower than that ideal negatively impacts quality.

[1] <http://xkcd.com/862/>

~~~
ScottBurson
I find that fast compile turnaround helps me stay engaged with the problem.
Even a 30 second delay gives me time to get distracted by one of the
temptations that surround us all. The ironic result is that I sometimes
actually think _less_ about what I'm doing when I have to tolerate these
delays. Ideally, when I catch myself doing this, I make myself stop and think,
but sometimes I'm tired and lack the patience.

On the other hand, in a fast-turnaround environment like Lisp, I can make
three stupid mistakes in about a minute, and when I realize I'm thrashing, I
still have all the context in my head to figure out what I should really do.

------
whimsymachine
There's a rich history of research into the nature and methods of problem
solving (Polya et. al), the role of unconscious (e.g. walk away from the
lab/tools) and so on. The more intractable the problem, the more it required
being able to walk away from the tools (see anecdotal history about discovery
of the structure of benzene for example).

The experience of "coding", with its quick feedback loop hypnotizes people
into an unproductive leash. The nature of the problem, the language and tools
either help or exacerbate.

My experience is that most hard problem solving needs at least three
approaches - I paraphrase them as 1. Zoom Out, 2. Zoom In 3. Zoom away.
Debuggers aside, I found that program construction in interpreted languages
(my work was in Lisp) supported with a good toolset and modularity in design,
allowed productive zoom-in, zoom-out whereas programming in
"edit/compile/debug" languages even with the toolset and modularity required
"zooming away" more often. Could be that the context switching cycle of
edit/compile/debug is a cognitive tax that really hampers hard problem solving
or when things are not working as expected.

------
listrophy
"Step Away From the Computer" or "Hammock-driven Development" by Rich Hickey
(author of Clojure): <http://clojure.blip.tv/file/4457042/>

~~~
DTrejo
Thank you for this. Can't wait to start reading the book he recommended,
<http://en.wikipedia.org/wiki/How_to_Solve_It>.

 _Marvin Minsky said in his influential paper Steps Toward Artificial
Intelligence that "everyone should know the work of George Pólya on how to
solve problems."_ \- Wikipedia

------
ZeroMinx
Hardly news for anyone who's been a developer for a long time. I generally
solve my dev problems wandering around London. This has the added bonus of
when I've sorted out the problem in my head, I'm at a location I've never been
before and have the chance to find a new restaurant/pub. Win/win.

------
nikcub
I was told years ago by an older developer that "90% of code is written away
from your computer"

I adhere to this adage and find it to be true

------
ashleymoran
While you can get the benefit of clarity by stepping away from the keyboard
for a while, I've found the best return is from test-driven development. TDD
forces you to think about what you're trying to achieve before you try to
solve the it. The thing I took exception to in the post was:

> 5\. Make small change to the code on the off-chance that it might solve the
> problem

Whether practising TDD or trying to formalise the problem on paper (or in your
head), this is not the way to write code. Programming is not a random search
problem.

These days, I tend to only step away from the keyboard when I'm losing my
bearings for where I am in the big picture. Usually, that's when I'm "making
small changes to the code on the off-chance that it might solve the problem"…
this means I don't really know what the problem is.

~~~
ohyes
Please re-read.

"It’s very easy to slip into the mindset of:"

His point is that the procedure that he gives (in particular step 5) is the
wrong one.

------
Tycho
Maybe someone could make paper based IDEs, like notebooks that have columns to
trace variables, rows for declarations at the top... Edit: terrible idea, just
look for a suitable jotter in the stationary sections.

~~~
robintw147
What an interesting idea... _puts on list of things to do sometime_

------
drblast
I have a personal project I've been working on for years, mostly in pen and
paper.

Every once in a while I'll get motivated and start coding it up. I'll start to
think "I didn't think I could do it that way when planning it on paper, but I
can't remember the reason...I'll just see what happens."

A few hours later I get to the "oh yeah..." part.

Funny thing is, that works both ways. Sometimes no matter how much you plan,
if you just start coding you get the positive "Oh yeah!" moments that wouldn't
have happened on paper.

------
dhruvbird
+1. I've found that thinking hard and long about most problems before coding
them results in less buggy (sometimes even no bugs!) code. I remember my
friend telling me that his dad had to stand in line and wait literally days to
execute code on a computer (using punch cards) and they had all the time in
the world to write the code, but very little to execute it. One mistake during
execution and they would have to wait a few days for their turn, delaying the
results that they were seeking.

I try to emulate this environment (by not compiling/running code) and trying
to tell myself that I really should get a large chunk of thought (followed by
relatively bug-free code) down before I let the compiler/interpreter in. This
discipline has helped me a lot imho.

~~~
robintw147
Yeah my Dad has told me similar stories. In fact, I'm finding a similar thing
now when I'm using the university supercomputer. I don't have to submit using
punched cards anymore (thank goodness) but I do have to submit jobs to the
batch queue and give them an estimated time the job will take to complete.
This impacts the scheduling of the jobs, so if I submit a job and say it'll
take 12 hours to run, then it is unlikely to start for a while. This gives me
another reason to check the code very carefully, or I wait overnight and find
that my code crashed after 2 seconds with a silly error!

------
makmanalp
Why is the write test -> code -> run test -> code -> run test -> etc. circle
being derided? Given that your test cases are stringent enough, it should be
fine.

If you did indeed write good test cases, then that's a prime indicator that
you understand the problem you're solving well. Try test first programming,
it's trickier than it sounds at first. In my opinion, it is too easy to get
caught up into coding something (especially with languages that have large
amounts of boilerplate, such as Java) and lose perspective of what you're
actually trying to do. Writing test cases beforehand forces you into thinking
about what you're actually doing.

------
nazri1
This is mentioned in the pragmatic programmer [1] book as deliberate
programming, as opposed to programming by accident.

[1] <http://www.pragprog.com/the-pragmatic-programmer>

------
mmb
Having a baby caused me to transition to this style for personal projects. I
spend a lot less time in front of the computer now and when I do it's for
shorter times.

I've found this approach does give a better result and eliminates false
starts. When I'm at the computer now I have already thought through what I'm
going to do completely and writing the code is just a minor detail.

------
pepijndevos
While I do agree that stepping away from the computer helps for getting
started or when you're stuck, I am more in line with people using CSS rather
than Photoshop for prototyping. As the author wrote, converting thought to
code is fairly easy, so by writing as I think, I free my mind from containing
all the stuff I thought out already.

------
d135-1r43
I have a piano standing next to my PC. The most productive days are those on
which I play/compose/improvise the most…

~~~
nitrogen
I have always had one or more musical keyboards by my desk, and I agree that
there is a correlation between musical and software inspiration. However, I
think in my case both forms of inspiration are derived from the same cause,
rather than one causing the other. I'm still working on discovering that
common cause.

------
barkerja
I can't begin to express how much more productive and clearer I think when not
behind the computer.

I do most of my outlining away from the computer, with pen and paper. UML is
your friend! <http://en.wikipedia.org/wiki/Unified_Modeling_Language>

------
airfoil
Agree. Some of my best coding and problem solving was done when I was pacing
around my office while playing with a stress ball. Sitting in front of the
computer is my least productive spot for solving problems. I code best when
pacing around, in the shower, or driving...

------
astrofinch
Is it really true that many real-world programming tasks require this level of
thought and dedication?

Honest question, I'm a student and none of my school/pet projects have been
difficult enough that stepping away from the computer was beneficial. Only
puzzles have been hard enough.

------
cloanic
For myself it goes one of two ways, I can actually write the layout on a text
editor or I like to go to the park when hardly anyone is there and just walk
around. It takes my mind off the problem, thus leading to a solution I never
thought I would have gotten.

------
jayzalowitz
I love chalkboards, they are the best coding instrument since the abacus, true
fact.

------
spullara
I find when going to sleep is the best time to code like this. No
distractions.

~~~
barkerja
And in the shower!

~~~
spullara
Yep, shower too!

------
jarin
I think this article would be better titled "Want to write some code? Get away
from Visual Studio".

~~~
mattmanser
Perhaps better titled get away from the IDE. Every IDE has exactly the same
capacity that he's ranting against.

This is a rant against write, run, debug, repeat, not visual studio.

Even Notepad++ has run in it.

~~~
robintw147
Exactly :-) (It so happens that I was using Eclipse anyway...)

------
keeran
100% agree, I write my best code in the shower, as I'm getting ready for work
:)

