5 ms·

Want to write some code? Get away from your computer

129 points by robintw147 16y ago

astrofinch 16y ago
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.
whimsymachine 16y ago
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.
ZeroMinx 16y ago
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.
ashleymoran 16y ago
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 16y ago
  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.
- alnayyir 16y ago
  > 5. Make small change to the code on the off-chance that it might solve the problem Guess and check, supported by a scaffolding of tests is not the path to being a better or more professional programmer and this is precisely what he's advocating against.
jarin 16y ago
I think this article would be better titled "Want to write some code? Get away from Visual Studio".
- mattmanser 16y ago
  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 16y ago
    Exactly :-) (It so happens that I was using Eclipse anyway...)
dhruvbird 16y ago
+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 16y ago
  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!
listrophy 16y ago
"Step Away From the Computer" or "Hammock-driven Development" by Rich Hickey (author of Clojure): http://clojure.blip.tv/file/4457042/ http://clojure.blip.tv/file/4457042/
- DTrejo 16y ago
  Thank you for this. Can't wait to start reading the book he recommended, http://en.wikipedia.org/wiki/How_to_Solve_It 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
drblast 16y ago
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.
spullara 16y ago
I find when going to sleep is the best time to code like this. No distractions.
- barkerja 16y ago
  And in the shower!
  - spullara 16y ago
    Yep, shower too!
sliverstorm 16y ago
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.
- true_religion 16y ago
  I don't agree 100% but I think debuggers are for code that you didn't write yourself and has insufficient documentation. When it comes to a dynamic language, knowing how and what lead to a particular function being called is important and all that information isn't exactly saved on the stack trace---you have to step through to find it.
- ianl 16y ago
  It depends on the type of bug, sometimes its just simple quirks or something you've done incorrectly like the wrong pointer arthimetic or trying to write to a null pointer or something along those lines. However, a lot of the biggest headaches are conceptual and in which case taking a break from the computer almost always helps I find.
- ChuckMcM 16y ago
  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 16y ago
    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 16y ago
      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.
barkerja 16y ago
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 http://en.wikipedia.org/wiki/Unified_Modeling_Language
nikcub 16y ago
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
wslh 16y ago
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 16y ago
  Agreed -- the author of the post is talking about writing or debugging algorithms; coding is the stuff you need your computer for.
ChuckMcM 16y ago
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/ http://xkcd.com/862/
- ScottBurson 16y ago
  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.
Tycho 16y ago
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 16y ago
  What an interesting idea...puts on list of things to do sometime
keeran 16y ago
100% agree, I write my best code in the shower, as I'm getting ready for work :)
d135-1r43 16y ago
I have a piano standing next to my PC. The most productive days are those on which I play/compose/improvise the most…
- robintw147 16y ago
  You may have just persuaded me to change the location of my piano...
- nitrogen 16y ago
  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.
psadauskas 16y ago
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.
- niels 16y ago
  Same here... Just a week ago, I spent the whole night looking at code trying to find out how some mysterious data loss had occurred. Needless to say, I had been to bed half an hour before it hit me what had happened. I instantly got up and fetched my laptop to confirm that was indeed the case. I think you are right, about letting go of all assumptions, and that helps you find the edge cases.
- robflynn 16y ago
  At one of my old jobs, some of the other employees jokingly referred to me as "the master of the arcane." Any time they had a problem they couldn't figure out, they'd come to me and ask me to help with it. My trick was to listen to their problem and then go take a walk. Our office was in a nice area with plenty of sidewalks. So, I'd get the details of the problem and then go take a walk for about a half hour while I thought about the issue. After the walk I was able to sit down and my computer and implement whatever weird thing it was. These days I do work from home (freelance) so I find myself pacing around my house while trying to figure out something odd. I think I've worn a groove in the grass at this point. It really does do wonders for the brain.
- deleted 16y ago
  [deleted]
- Aaronontheweb 16y ago
  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.
- 16y ago
mmb 16y ago
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.
jayzalowitz 16y ago
I love chalkboards, they are the best coding instrument since the abacus, true fact.
airfoil 16y ago
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...
makmanalp 16y ago
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.
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
nazri1 16y ago
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 http://www.pragprog.com/the-pragmatic-programmer
pepijndevos 16y ago
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.
cloanic 16y ago
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.

129 points by robintw147 16y ago

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.

whimsymachine 16y ago

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.

ZeroMinx 16y ago

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.

ashleymoran 16y ago

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 16y ago
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.
alnayyir 16y ago
> 5. Make small change to the code on the off-chance that it might solve the problem Guess and check, supported by a scaffolding of tests is not the path to being a better or more professional programmer and this is precisely what he's advocating against.

jarin 16y ago

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

mattmanser 16y ago
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 16y ago
  Exactly :-) (It so happens that I was using Eclipse anyway...)

dhruvbird 16y ago

+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 16y ago
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!

listrophy 16y ago

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

DTrejo 16y ago
Thank you for this. Can't wait to start reading the book he recommended, http://en.wikipedia.org/wiki/How_to_Solve_It 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

drblast 16y ago

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.

spullara 16y ago

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

barkerja 16y ago
And in the shower!
- spullara 16y ago
  Yep, shower too!

sliverstorm 16y ago

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.

true_religion 16y ago
I don't agree 100% but I think debuggers are for code that you didn't write yourself and has insufficient documentation. When it comes to a dynamic language, knowing how and what lead to a particular function being called is important and all that information isn't exactly saved on the stack trace---you have to step through to find it.
ianl 16y ago
It depends on the type of bug, sometimes its just simple quirks or something you've done incorrectly like the wrong pointer arthimetic or trying to write to a null pointer or something along those lines. However, a lot of the biggest headaches are conceptual and in which case taking a break from the computer almost always helps I find.
ChuckMcM 16y ago
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 16y ago
  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 16y ago
    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.

barkerja 16y ago

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 http://en.wikipedia.org/wiki/Unified_Modeling_Language

nikcub 16y ago

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

wslh 16y ago

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 16y ago
Agreed -- the author of the post is talking about writing or debugging algorithms; coding is the stuff you need your computer for.

ChuckMcM 16y ago

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/ http://xkcd.com/862/

ScottBurson 16y ago
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.

Tycho 16y ago

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 16y ago
What an interesting idea...puts on list of things to do sometime

keeran 16y ago

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

d135-1r43 16y ago

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

robintw147 16y ago
You may have just persuaded me to change the location of my piano...
nitrogen 16y ago
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.

psadauskas 16y ago

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.

niels 16y ago
Same here... Just a week ago, I spent the whole night looking at code trying to find out how some mysterious data loss had occurred. Needless to say, I had been to bed half an hour before it hit me what had happened. I instantly got up and fetched my laptop to confirm that was indeed the case. I think you are right, about letting go of all assumptions, and that helps you find the edge cases.
robflynn 16y ago
At one of my old jobs, some of the other employees jokingly referred to me as "the master of the arcane." Any time they had a problem they couldn't figure out, they'd come to me and ask me to help with it. My trick was to listen to their problem and then go take a walk. Our office was in a nice area with plenty of sidewalks. So, I'd get the details of the problem and then go take a walk for about a half hour while I thought about the issue. After the walk I was able to sit down and my computer and implement whatever weird thing it was. These days I do work from home (freelance) so I find myself pacing around my house while trying to figure out something odd. I think I've worn a groove in the grass at this point. It really does do wonders for the brain.
deleted 16y ago
[deleted]
Aaronontheweb 16y ago
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.
16y ago

mmb 16y ago

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.

jayzalowitz 16y ago

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

airfoil 16y ago

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

makmanalp 16y ago

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.

deleted 16y ago
[deleted]
deleted 16y ago
[deleted]

nazri1 16y ago

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 http://www.pragprog.com/the-pragmatic-programmer

pepijndevos 16y ago

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.

cloanic 16y ago

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.