The Terminator Metric

The Terminator Metric is an outstanding (perhaps superior) design mantra:

...what you should really be worried about is the possibility of someone building a Terminator robot and sending it back in time to kill you for building whatever it is you are about to build.

To which we (naturally) respond:

bring it on.

Case based reasoning

There's a case sensititivity discussion going on at Lambda the Ultimate. I assume this is one of those conversations that is just doomed to repeat itself ad infinitum (or at least until doublespeak starts to gain ground as an alternative to natural language).

One of the things they have over there is a genealogy of programming languages. I find that in this world of formal specifications, reference manuals, and cookbooks, just sampling the history of a subject really does the most for me. Maybe part of that is because history is more apt to tell you about the reasoning behind design decisions rather than trying to force feed them to you.

Web 2.5

I like the name Web 2.0. It implies that there will be a Web 3.0, only when 3.0 has too many problems (having been rebuilt from scratch) we'll get a Web 2.5 that adds the best of the new features with better backwards compatibility (or maybe I'm thinking of AtariDOS iterations - or Windows OS releases for that matter).

Expertise.

Question: what is the most important book you haven't read?

Teach Yourself Postmodern Programming in Ten Years (or Whenever)

What do I know? Probably nothing. I have no theory. But here's an ill-considered list of possibly postmodern programming challenges:

• Use think through debugging. Use step through debugging. Use delta debugging. Experience a compiler bug. Experience a hardware bug.
• Make a user interface. Script a user interface. Scrape a user interface.
• Write (and debug) a program in a language that requires you to manage memory explicitly. Persist data (and reclaim expired data).
• Write (and debug) a program that passes messages to another program. Use a stateful protocol. Use a stateless protocol.
• Break modules (object / file / compilation unit) apart and put them back together.
• Work on a program using two or more languages on multiple levels. Work on a program that mixes languages throughout.
• Generate code. Delete code.
• See how long a task actually takes to do.
• Stay with a program until it gets used by someone else (i.e. until after a round of maintenance).
• See what happens to your program after someone else (better/worse) has taken responsibility for a cycle or two.
• Make a change to another person's program using their programming style.
• Work too close to someone else. Work too far away from everyone else.
• Resolve a conflicting merge (see above).
• Roll back a change.
• Replace a perfectly usable module because of licensing issues.
• Write a program to compare the previous behavior of an old module with that of its replacement.
• Never do anything more than twice manually.

Notes on Postmodern Programming
How to Teach Yourself Programming in 10 Years