Visiting Seattle, werkin, flying, etc.

kragen@pobox.com kragen@pobox.com
Mon, 5 Feb 2001 11:43:42 -0500 (EST)


I'm flying back from Seattle tonight; I've spent the weekend here with
Jamie.  It's been a very nice weekend.  Lots of sushi.

My machine in Dayton is currently down; I need to turn off BIND, set
up some kind of remote login service for it, and turn it back on.

Been working a huge amount during the last week.  Lots of software to
write.

I took a bunch of email --- 399 messages, 586 pages, 146,190 words in
402 pages of body text, 1.7 megabytes --- and read them all, or at
least the ones I cared about.  I responded to all the pieces I thought
needed responses.  I hadn't read my personal email since Sunday; this
was everything from Sunday through Friday, six days, really.

My Emacs-based outliner mailreader is working out quite nicely, still.
When faced with 400 messages at once, it might be nice to prefilter
and thread a bit, but just being able to scan the subject lines seems
mostly sufficient.

Jamie is a little worried I'm not taking good enough care of myself.
She's probably right --- I'm not brushing my teeth as often as I
should, I'm not getting the massages I should, and I'm working myself
too hard.  The next few weeks are going to be a little easier than the
last week, though.

On low-tech:

I've said several times that I prefer low-tech stuff, much to the
shock of some of my co-workers; I'm not sure how to explain this
adequately.

The more I work with computers, the more I realize that complexity has
hidden costs --- complex things are less reliable, fail in more
unpredictable ways, are harder to diagnose problems in, are often
harder to fix, are usually more trouble to keep running, are harder to
change (especially to change without breaking), and are harder to get
to work with other things.  These alone are significant reasons to
prefer a simpler solution to a more complex one unless the complex
solution has significant advantages.

But there's a nastier side to it, too.  Complex things hide the
intentions of their makers better.  There's an interesting power
relationship set up between a craftsman and the users of his work
products: the work products are subject to the whim of the users, but
also, the users are subject to the whims of the work products.

This is a given in architecture: our mental state and behavior are
powerfully affected by our surroundings; by manipulating people's
surroundings, we can control what is easy and hard for them to do, and
therefore, what they will do.

So when you're interacting with an artifact, your control over your
environment is directly limited by the extent of your control over
that artifact.  To the extent that you don't control the artifact, but
are controlled by it, you are under the control of the artifact's
creator.

For example, I watched Jamie deleting her spam today.  She uses
Outlook Express, which displays each message as soon as she highlights
it in the message index.  Because nearly all of her spam is HTML spam,
it transmits back signals to its senders (via "web bugs") that
indicate that she has read it, and therefore that her address is a
valid, deliverable address --- simply because she highlighted it in
order to delete it.

I suggested to her that she should not view the spam before deleting
it.  Unfortunately, neither of us knew how to tell Outlook Express not
to view a message when it was highlighted in the index, nor how to
delete a single message without highlighting it; our ignorance made us
powerless and subjugated her to the designs of the Microsoft engineers
who wrote the program --- and, by extension, to the mentally crippled
morality-disabled vomit-lapping spammers who exploit its careless
intrusion on her privacy.

This is a fairly innocent example; the only negative consequence is
that her email address becomes less useful as time goes on, making it
impossible for her to maintain very-infrequent email correspondences
as an inadvertent result of a UI design choice.  Not every harmful
design choice is so innocent --- case in point: the version-to-version
minor incompatibilities of Microsoft Office programs, which force you
to upgrade your whole office, and which eventually render old
documents unreadable --- or so harmless.

As a result of many experiences like this, I do my best to use
software that is as simple as possible.  Maybe I'm too paranoid.  Or
maybe I'm just sensible, while many other people are blinded by the
coolness of the stuff they're using.  Only time and comp.risks will
tell.

I'd really like to work in an operating environment simple enough that
I could actually read and understand every line of code, and flexible
enough that I could easily change whatever I didn't like.  It seems
that it should be possible to build a mailreader, web browser, HTML
editor, web server, GUI, and preemptively-multitasking OS, all in
100,000 lines of code or so.

I argued once that GUI programming is inherently harder than text-mode
programming.  Derek Robinson disagreed with me; he said that
programming with the DOM in MSIE5, which one could certainly conceive
as a kind of GUI programming, was far easier than programming with any
GUI toolkit, or even in text mode, than anything he'd ever done
before.  I think he's right.


On money:

Jamie suggested I should read _Your Money or Your Life_, an enjoyable
book on money.  I've read the first couple of chapters, and they seem
to be mostly devoted to deprogramming city-slicker money-hungry fools.
Now I guess I understand why I never had any serious financial
problems, even when I was working for minimum wage.  I'm reading the
_Tightwad Gazette_ books now.

I'm still undergoing unplanned expenditures, though.  Perhaps I should
list them carefully and treat them as I would industrial accidents:
why did I spend this?  And why did that happen?  And why did that
happen?  Can I keep this from happening again?  Can I predict when
this is going to happen again?

For example, tonight, I'm staying at a hotel, because I caught a ride
to the airport with a co-worker on Friday.  I'm returning too late to
catch the train and bus home, so I'd have to take a taxi back home ---
and that would cost $200 or so, because I'm flying out of San Jose.
Instead, I'll spend the night in a reasonable hotel near the airport
(cost: $75, I'm guessing) and take public transit to work tomorrow
morning.

I could have avoided this $75 cost by taking an earlier flight back or
by leaving my car at the airport.  I didn't think of this because I
was in a hurry when I made the reservation and when I left.

Similarly, I'm expecting to have to replace a wheel of my car when I
get back.  I ran over a nail on Thursday night or Friday morning;
another driver noticed it as we were driving to work.  I reinflated
the tire at the next gas station, and there was no leakage detectable
with the pressure gauge on the hour-long journey.  But after the
weekend, I'm sure the tire will be completely flat, and the left front
corner of the car will be resting on the point of contact between the
rim and the top edge of the curb --- which probably will have ruined
the rim.  I have the unenviable task of changing the tire in this
position (the parking brakes are out, the car is on a slope with only
the curb and the transmission in "park" keeping it from rolling down
the hill and into Rohit's office window, which will be my office
window starting Monday --- so I actually need real wheel chocks and a
decent jack to switch to the spare tire.  I guess I should just hire a
towing service to do the job.) and then getting a new tire.  Estimated
cost: $60 for the tow, $50 for a new tire, $50 for the wheel, $50 for
the labor.  I could have forestalled the whole problem by getting the
tire plugged on Friday afternoon for the cost of half an hour ($100)
plus $10 in labor.  But I didn't plan it.

Reducing the complexity of my life --- the number of things I have to
keep track of --- would probably cut my expenses quite a lot.


Sorry this isn't a particularly well-written post; I've heard several
people really enjoyed some of these posts, but this one lacks literary
merit, I think.