Atlas · Details
Saving Time
Author’s note
A fiddly and overly-long essay about automating your micro-tasks as a programmer, stuff you do over and over. Emacs gives you a lot more tools than a typical IDE, so it explores some of them. It also explores how to decide when it's worth automating a task.
I think a simplified version of this thesis holds up in the world of AI. You need to think carefully about whether to spend _tokens_ to save time (or save more tokens), and I think a lot of the decision process remains similar.
AI Notes
Written live at the keyboard one September evening in 2004,
timestamps included. Steve budgets ten minutes for the blog post,
takes two hours, and at 9:43pm walks out on the reader mid-essay to
chase a "WAY cool" idea, returning 36 minutes later and refusing to
say what he built until the end. The structure shambles to match: the
Second Significant Point gets announced before he remembers he never
stated the first one, and every time a book link lands in the text he
runs his new function on it and gleefully counts down toward
break-even ("718 more bottles of beer on the wall..."). Buried in the
middle is the piece's actual sales pitch — a patient explanation of
Emacs's lisp-interaction-mode, where broken half-written
code can lie around a buffer like parts in a mechanic's workshop and
"happiness is never having to restart." Whether calling that "the
ultimate form of unit testing" would survive contact with an actual
TDD practitioner is a question the essay does not stop to ask.
The pull quote near the top of this page belongs to a commenter, by the way: a reader named Raif showed up the day the post went up and put its economics more crisply than Steve had. The rest of the thread earns the scroll too, including a nicely timed comeuppance over the mystery tool.
Related listings
-
2005
Effective Emacs
Same year, same toolkit, more general advice. Effective Emacs is the broader case for living inside the editor; Saving Time is one specific worked example of doing it for an hour.
-
2005
My .emacs File
The companion show-and-tell: a walking tour of the accumulated little customisations Steve has built up the way the URL-munger gets built up here, one hour at a time, over years.
-
2005
Practicing Programming
The argument that working programmers don't practise. Saving Time is one description of what practising actually looks like in your editor on a Tuesday afternoon.
From the peanut gallery
Read the rest of the thread · 7 more
-
OK, that part about order-of-magnitude wasn't very clear. Convert the timestamp to Seattle time and you'll see why.
What I was trying to say was this. In my experience, the direct time savings from automating a task is far outweighed by the indirect time savings -- avoiding context switching and letting software do the thinking for you.
Or put another way, the really big advantage to automating tasks like this is not that it's faster per se, but that it makes you more productive in the task at hand.
-
Here you go, you can track the value of your function with this:
(defadvice fix-amazon-url (around fix-amazon-url-value-counter activate)
"Keeps track of how many times you've used this function" ad-do-it (customize-save-variable 'fix-amazon-url-invocation-counter (1+ (or (and (boundp 'fix-amazon-url-invocation-counter) fix-amazon-url-invocation-counter) 0))) (message "Please use me %d more times" (- 720 fix-amazon-url-invocation-counter)))
-
Thanks - htmlize.el looks really, really cool. Thanks for not telling me about it before. ;-)
This is why we need to productize Emacs, by the way. All the elisp-archive listings suck, as none of them are complete.
My 35-minute version is a little baby version of htmlize.el. I had fleeting thoughts of multi-version compatibility, overlay support, working on files as well as buffers, properly handling HTML escapes... just about all the things that are fully supported in htmlize.el. I just figured Derek would do it, once I'd done the proof of concept. :-)
Interesting how similar my basic approach is to theirs. Scan the text properties at change boundaries, look up the face name in the rgb alist, format as hex, insert font tags, escape the HTML... I guess I had it *basically* right.
Regarding your irony filter - point taken, but the various Lisp-y folks out there (e.g. Richard Gabriel, JWZ, Paul Graham) would say that you drew the wrong conclusion. You concluded that Emacs should be better at helping you develop things other than itself. They would conclude that you should write everything in Lisp (since you can get essentially the same level of interaction if you're doing Scheme or Common Lisp development.)
-
Cool -- I've always wanted that feature somewhere, but usually ended up googling for the term concat Amazon to get a canonical link. I always imagined that there'd be some internal or external service to do it, but never found it.
-
Even if you never "gain the time back" by executing the function enough times, you've increased your work satisfaction greatly. You got to spend a happy hour programming, whereas you were probably getting slightly annoyed every time you had to convert a url.
Sometimes automating a task is more about keeping things interesting than saving time in the long run.
-
BTW you could also take into account the amount of time /other/ people save into your cost-benefit equation :)
-
Several things: One, automating things is cool and useful. For example, and in a similar vein, I once spent half an hour or so muttering perl incantations, to get a script that would transform a url from the onlines, devo, or master, to one for my desktop, including adding in the right port and such. This made it really easy to find a page of interest elsewhere, and dissect on my desktop.
I too believe in the Rule of Three, id est, that any task I do more than twice ought to be automated. Browse my ~/bin directory on my home box (or even my work one) to see the things I have done to automate my life. For example, any one not using command line completions for our common commands (like, for example, /apollo/bin/runCommand or pubsublisten) is doing WAY too much typing.
Excellent. Also note that saving time is not the only reason to automate repetitive tasks. You can also save thought as well.
In the amazon-url-fixing example above (which, as detail-page QA, I can appreciate and will probably steal), you don't have to stop thinking about what you're writing. You don't have to "remember to fix them all up later."
You let software (in this case, emacs) handle much of the depth of thought. You save context-switching and it makes your other work faster.
Can you measure that as easily as time? No, not really. But for me personally it's an order-of-magnitude greater effect than the time effect.
BTW if all of your documentation is for folks at Amazon, you can eliminate .amazon.com as well.
Sorry if any of this repeats what you said -- I had to go this entry pretty fast, even though it was really good.
— Raif · September 24, 2004 02:13 PM
"Emacs is the word processor of development environments."
That's the Velvet Elvis of metaphors.
— Brian R · October 2, 2004 02:06 AM
OK, now that I've read the rest of the blog:
My irony detector went off here:
"Emacs makes it easy when you're developing Emacs-Lisp code, but Emacs is less helpful if you're using it for doing, say, Java coding."
Hmm. A development environment that's best suited for developing the development environment... It's like a perpetual motion machine.
Dumping a highlighted buffer as html:
There's an 'htmlize' feature that someone wrote, which will turn a buffer into html. But kudos to you for writing it.
http://fly.srk.fer.hr/~hniksic/emacs/htmlize.el
— Chris Thomas · September 24, 2004 06:53 PM
Yes, but I'd have to subtract out all the time they waste reading my blog, so I think I'll just keep it simple. :)
— Steve Yegge · September 28, 2004 12:20 AM