Live data from Hacker News

Want to write some code? Get away from your computer

blog.rtwilson.com

41–50 of 64 posts

Re: Want to write some code? Get away from your computer

#41

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.

I find that getting exercise really helps me think through tough problems.

Related anecdote: I heard that Seymore Cray used to dig holes in his backyard when he was trying to think through engineering problems and that his peers used to joke that he would end up getting killed by a cave in.

Re: Want to write some code? Get away from your computer

#42
post #32

Earlier quoted context omitted.

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.

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 too…

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.

Re: Want to write some code? Get away from your computer

#43

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.

I'm the exact same way.....I've solved quite a few pesky problems with my code in the shower at the start of my day.

I've found that when I'm in bed trying to fall asleep is when I do a lot of brainstorming for my ideas rather than problem solving

Re: Want to write some code? Get away from your computer

#45

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 th…

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.

Re: Want to write some code? Get away from your computer

#46
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.

Re: Want to write some code? Get away from your computer

#47
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...

Re: Want to write some code? Get away from your computer

#48
post #32

Earlier quoted context omitted.

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 too…

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 be…

The problem isn't using a debugger, it's being overconfident in how much you can infer from any given debugging run. The solution is to have realistic levels of confidence, not to swear off the use of debuggers. Obviously, if you're trying to understand how the code works, having one empirical sample is better than having zero empirical samples.

Re: Want to write some code? Get away from your computer

#49
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.

Re: Want to write some code? Get away from your computer

#50

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

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.
Post reply on HN