All the Perl that's Practical to Extract and Report
use Perl Log In
ziggy (25)
The XP Ideal
Regardless of how you feel about XP, it has helped the industry because it has given us a goal and opened up a discussion on how to achieve it.
For example, take test-first development and refactoring. Test-first may be a controversial practice, but it has raised the profile of automated testing, which can improve code with or without any other XP practices. XP's love of constant refactoring may be hard to swallow, but it has brought a positive light onto rewriting nearly working code and replacing it with something better.
Today, I came across another example: pair programming.
At $WORK, I'm writing a parser for a rather complex and underspecified grammar in Haskell. This week, another wrinkle came up: the need to read and write Tcl-formatted strings. I'm sorta the research programmer on the team, so I'm pretty much on my own on this project. Which sucks, sometimes. For example, it's hard to bounce ideas off of a partner.
Again, XP gives us a model and a goal. With pair programming, one of the goals is to keep both a low level and a high level perspective in mind when writing code, rather than just one or the other. The model is to program in pairs, where one person focuses on the implementation details, and the other focuses on the larger level issues. Imagine my surprise when I started feeling some of the benefits of pair programming while programming solo.
Here's the trick: pairing $me[time()] with $me[time()+3600]. A couple of times today, I felt myself getting stuck on a problem without making any progress, I put it aside and pulled myself up to a higher level perspective. (Maybe that process took an hour, maybe less. I wasn't exactly keeping track of time. I'm sure some psychologist has an explaination on why and how you need to take time to switch perspectives.)
All of a sudden, my mistakes became clear, and it became obvious where I was hitting the wall. I couldn't see the way out exactly, but I could see the problem that was holding me back, and I got a vague feeling for where I needed to be. When I started diving back into the code, things gradually got clearer, until I hit the next wall.
I shouldn't have been surprised, but I was. There have always been times when I'm writing code where the best thing I can do is walk away from the keyboard. What did surprise me is that I found yet another instance where the best way to improve a non-XP process is to borrow a page from the XP book, ferret out the goal, and aim for it.
but computer language design is just like a stroll in the park.
Jurassic Park, that is.
--Larry Wall in <1994Jun15.074039.2654@netlabs.com>
agreed... (Score:1)
I don't really write my tests first, but I always do my best to have an automated testbench, that increases my confidence and allows me to refactor more freely, therefore being a productivity boon in general.
Pair programming is also great in improving output.
Changing focus (Score:1)
Like the ability to not being stubborn about solving a problem that turned out to be too hard, or by doing it the wrong way. After a while you simply need to calm down and reassess the entire problem and see if you can solve it using a different approach. That's much easier when you have a co-pilot with a level head, but it can definitely be trained on your own as well.
There is also the be
Time makes one programmer into many (Score:2)
I used to hear grips that version control and software engineering practices were only useful on "large projects, or projects with more than one person," none of which were allegedly applicable to what we did here. However, I came up with the axiom that given enough time, any project appears large enough or appears to have more than one person. Come back to your code three months later, and it's like you're working with an older version of yourself.
J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
Tell the bear (Score:2)
Basic idea is you keep a teddy bear on your desk, or in a different room, and any hard programming task you get stuck with you explain it to the bear first. Inevitably you come to the solution during the explanation.
Of course you look like a complete nutter - I'm sure someone invented this idea as a bet.