Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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)

    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

    • You could check in everything *but* the failing test. Leave that on your hard drive.
      • 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.

  • 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.
    • Beck also points out that this probably only really works if there's just one person/pair on the project.
      • 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
  • 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.