in reply to Algorithm design
For a small or medium-sized script, I like to write a throwaway version, just to get an idea of the problem, in deference to Brooks' admonition: "Plan to throw one away: you will, anyhow." That gives me a chance to try out one or two ideas without committing to them, and generally the process of coding up a solution gives me other (often better) ideas. Of course, hacking up a half-assed solution just to get started isn't all that great an idea when you know that Management's going to assume that the first working program you come up with is the Solution. In that case, it's probably better to proceed more slowly, and be more careful.
As far as algorithm design goes, I have a fairly well developed (read: geeky and obscure) interest in "the standard Comp. Sci. algorithms" -- things like graph traversal, network flow, various and sundry data structures, etc -- and keep a handful of algorithms books around my computers. I've gotten used to trying to think of problems in "formal" terms -- "Wait a minute, this is a directed graph" -- which comes in handy when I'm trying to figure out the "how" of solving a problem. It does take some getting used to, though.
This study also gave me a decent understanding of a few basic techniques for building algorithms -- divide and conquer, dynamic programming, recursion, and so on. It's much easier to hack up an algorithm for your particular problem with more tools in your chest than basic iteration and branching.