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.

Comment onRe: Algorithm design