use Perl

• Having a break (Score:2, Insightful)

  by koschei (147)

  Another good thing about it is that you get 16 hours (assuming 5pm-9am) of not looking at the code.
  
  You come in the next morning and can approach the code with a fresher outlook. And can often solve it instantly =)
  
  

  --
    ---ict / Spoon
• Not Sure (Score:2, Informative)

  by chromatic (983)

  Allowing known failures is a very slippery slope. Like bugs, test failures should be an exceptional thing.

  If you're doing XP, your engineering tasks should be short enough that you don't have to leave them overnight. If they're that large or that complex or things are going that poorly one afternoon, split them or just start over in the morning. The further you stray from a checkin, the less feedback the rest of the team has from your code.

  If you're not doing (or aren't trying to do) full-blown XP
  • Re:Not Sure (Score:2)

    by Matts (1087)

    You could check in everything *but* the failing test. Leave that on your hard drive.
    • Re:Not Sure (Score:1)

      by chromatic (983)

      Great minds -- that occurred to me right after posting. :) Since getting started is the hardest part, fixing a simple, failing test might have jump-start the day.
• Starting with a failing test (Score:2, Interesting)

  by dws (341)

  Kent Beck advises this in the back of his book on Test Driven Development. He got the idea from Richard Gabriel, who adopted it from advice often given to writers: Stop a writing session when the dramatic tension is nearly, but not completely, resolved. The mind loves resolution. Without it, your subconscious will continue to churn overnight, and when you pick things up in the morning, you'll have better ideas for how to resolve the tension, and this puts you right back into flow.
  • Re:Starting with a failing test (Score:1)

    by pdcawley (485)

    Beck also points out that this probably only really works if there's just one person/pair on the project.
    • Re:Starting with a failing test (Score:2)

      by merlyn (47)

      Beck also points out that this probably only really works if there's just one person/pair on the project.

      On the contrary, it probably works ideally well if you're in a pair, and you leave a bug to be fixed overnight, but then don't come in the next day. {grin}

      --
      

      • Randal L. Schwartz
      • Stonehenge
• GNU screen (Score:1)

  by mary.poppins (3530)

  I use a very long-lived GNU screen session. At the end of the day, I leave under the cursor in my editor a roughly one-sentence description of what I'm doing.
  
  This way, when I come back to the problem, I've still got all my editors and shells set up, with their histories intact.