Oh gosh, yes. I've found that approach to be the most helpful. In a year (or three?), I know that I won't remember anything about what it was supposed to do. I'm pretty sure I'm stupid or forgetful. Probably both.

I like your assertion of documentation being a measure of progress. As dumb as it sounds, even if you're the only consumer of an API you wrote internally for some on-off application, documenting it thoroughly is a tremendous time saver. Granted, I still slip up occasionally, especially if it's a quick script of sorts, but I find more often than not that when I do regret not having taken the time to document something, it's (now) usually something deceptively simple that I wish I had better curated, because it eventually finds new life as part of a greater work.

Yeah, especially with one-off scripts I keep upgrading my machine / reinstalling to clean things up, and wondering wtf -nRT means and why I thought it was important. Something like half the time I google / manpage around for a while and find out it wasn't important, or assumed something incorrect about what it was trying to do.

I've started wrapping everything I do frequently in small bash scripts, and documenting what and why. Saves a lot of time when migrating to a new system, since I can glance and say "nope, don't need it" within a couple seconds, or remember why it was useful (and sitting in a cronjob somewhere) and reinstall the things I actually use.

When writing scripts don't use the shortened flags, use the long version.

For example, the deploy script from a simple php app I wrote:

    rsync --recursive --links --verbose --rsh=ssh --exclude-from ./exclude_from_deploy.txt --delete ./ kazan:/srv/simple-paste/