Stephen Hawking and Me

Eddie Redmayne’s Best Actor win at Sunday’s Oscars for portraying Stephen Hawking in The Theory of Everything has reminded me of a footnote to the story.

I segued to computer science from linguistics and math. In my application to graduate school, I painted an I-meant-to-do-that portrait of my academic path. How I wanted to use computers for natural language understanding. So when I started my master’s at Michigan State in 1979, the department assigned John Eulenberg as my advisor. He was director of the Artificial Language Laboratory.

Dr. Eulenberg’s passion is inventing ways that computers could bring speech to those who couldn’t speak. Starting with designing the system that in 1974 yielded the first use of a speech prosthetic.

My mother, as editor of Physics Today, was always telling me stories from the physics world. Through her, I first learned of Stephen Hawking. And how the only way he had to speak was through his wife and graduate assistants, who could interpret his incoherent speech for the rest of us. Continue reading

Don’t blink.

Blinking is notorious as the least justifiable behavior on a web page. (But don’t blame Lou Montulli, who came up with the idea.)

It’s also British slang for annoying.

I just looked up something in the online documentation for PHP. Pages are generally clean and usable as they appear in the browser, although there are a few poor practices if you look at the underlying HTML.

However. Take a look at a typical page. Below each formal section are (often useful) comments. Try moving the focus down the page different ways—scrolling, moving the mouse, page down. One comment at a time appears in dark colors. The other comments are pale and washed out until you move the focus to them. Then, over 0.4 seconds, they become opaque and readable.

And most of the goodwill from how well thought-out the rest is is squandered.

There is no reason to make text unreadable. And less still to waste the user’s time as they’re made readable.

Since transitions are new to CSS3, my guess is that programmers were playing. As they had in 1994 with <blink>.

Playing is fine.

Then someone in the room has to say it’s great to know we can do this if we ever need it. But we don’t now. So take it out.

Talk to users

When I am talking to someone who is using software in a customer-facing context—a librarian, a pharmacist, a customer service rep, a cashier—I like to ask them about it. Are there tasks you need to do every day that are hard to do in the software, that you’ve learned a cumbersome hack around?

Every time the answer is yes. Every time.

Today it was a rep who needed to reschedule an appointment for me. She had to write down all the particulars from the existing appointment, cancel it, and then book the appointment all over.

Where a sane design recognizes that customers reschedule appointments a lot. Add a reschedule command. And support direct manipulation for the many cases when the change is simple. Show the appointment on a calendar that gives visual cues to what openings are available. Use the mouse to drag the appointment to a new date.

My library is using new software for circulation. If a book’s barcode is scanned twice, the second scan is treated by the program as a renewal of the book.

Librarians get distracted. They will forget if they’d scanned a book. A sensible engineer anticipates this and does the right thing, which is to ignore the second scan altogether. Don’t try to check it out again. Don’t report an error. Just ignore it.

I suspect that the problem is that no one thinks about what the people who use the software will actually do with it in a typical day, sits down with them and asks, or watches them doing their job.

This is not hard to do. It is not expensive or time-consuming. And it can make everyone along the way happier and more effective.

All in the Family – Samuel Becker

In telling you about the many engineers and scientists in my family, my father’s father, Samuel Lubkin, would be an obvious person to start with. But I think that one who was neither is a better choice.

My mother’s father, Samuel Becker, had wanted to be an engineer. He had to quit school early to help support the family. Still, he always loved gadgets and science.

My uncle and my mother discovered chemistry in the darkroom of Sam’s portrait studio. He grew up to become a chemical engineer. His kid sister went into nuclear physics before taking a job at Physics Today, where she reported on physics for 45 years.

I, too, learned to develop pictures. And watched Star Trek with him, which we both loved.

I’m proud to be in Sam Lubkin’s profession. But it was Sam Becker who planted the seed.

Programming without coercion

One of my core values is clarity. Clarity in what you think, what you write, what you say. In programming, this means clarity in your code. What you write should equally make sense to compilers and people.

I remember one program. What they used to call dusty deck, after the deck of punched cards they were on. Dusty from years sitting on a shelf. It had one constant for two very different purposes. The equivalent of using foo for both the range of values for the month and for the hour in a date-time because they both happen to be 12. Lots of luck in Israel, where the Hebrew calendar (1..13) and military time (0..23) are often used.

Continue reading

Check the price tag

On The West Wing, in “Guns Not Butter,” Charlie—who I see as the series’ protagonist—tries to reach a pal to ask him a simple question and triggers a memo from the Secretary of Defense, CC’ed to the Joint Chiefs and the Secretary of State.

Delegation is a basic principle of engineering. Do what you need and don’t tell you the details.

But sometimes you need the details.

Would you like me to arrange for someone to pick you up? It would be my pleasure. Did I not mention that we’ll charge your account $2,500 for the service? I’m sorry, but you should have asked. Continue reading

Quotations about engineering, part 1

I am, and ever will be, a white socks, pocket protector, nerdy engineer. And I take a substantial amount of pride in the accomplishments of my profession.
—Neil Armstrong, “Engineering in the 20th Century”, National Press Club,

It seemed to me that, in this business, someone was continually making me face up to facts, instead of letting me dodge unpleasant facts the way most people manage to do throughout their lives.
—Robert A. Heinlein, “If This Goes On—”, Astounding Science Fiction, -

If you’re not being rejected regularly, maybe you’re not trying hard enough.
—Kathy Ireland, The Talk,

Being ignorant is not so much a shame, as being unwilling to learn.
—Benjamin Franklin, Poor Richard’s Almanack,

“Can you and your people do it, Captain Tyrosian?” he asked at the end. “I know this is a very difficult engineering challenge with a very short time line, and I’m told it’s the sort of thing only the best weapons engineers can handle.” He could scarcely be more blatant, but it didn’t seem to be a good time for subtlety. Besides, he was dealing with an engineer, so subtlety might well be wasted anyway.
—Jack Campbell, The Lost Fleet: Valiant,

Give us a sign

For my money, businesses never have enough signs. To answer: Where am I? Where is the section I’m looking for? Where are the bathrooms, an open register, the entrance by where I parked?

Signs should use words. Then color as a redundant cue. (Some people are color-blind.) Then icons. (Most icons aren’t as recognizable as .)

Use walls, end-caps, shelves, and the floor. While it doesn’t help the color-blind, I love the cue of colored tape on the ground I can follow from here to my destination. Well-designed maps, with You Are Here marked, a legend, and an index. A floor directory at each entrance, and in every elevator. Single-floor directories at the top and bottom of every escalator. A grid system.

If possible, when an item could logically be located in more than one place, put copies in both. If you can’t, put a sign in one place that directs customers to the other. This is especially useful when you have to follow a system that may not make sense to them. Continue reading

Clever Hans

Physicist John Killeen was director of the National Magnetic Fusion Energy Computer Center (NMFECC) at Lawrence Livermore National Laboratory, but deputy director Hans Bruijnes was our day-to-day boss.

The morning would almost always start with a Hans-led all-hands meeting. It usually felt like a waste of time. But he believed in it. We should come together every day as a team, and all know what everyone was working on and what the key issues were.

Hans was a great practitioner of management by walking around, long before it became popular. He’d randomly stop by your office, ask what you were up to. Occasionally confusing matters by telling you to do X when your group leader had told you to do Y. Eminently mockable, but always with affection and respect.

I wish I’d known all the backstory in his obit when I’d see him every day. Find a long lunch at the Concannon winery to hear his version.

A good man, who will be missed by anyone who knew him.

Emacs, also a way of life

If you’ve programmed or been a sysadmin on UNIX or Linux, you’ve undoubtedly already taken sides in emacs versus vi. You won’t be convinced to switch to the other text editor. It’s like trying to persuade someone to flip allegiance between the Red Sox and the Yankees.

If you haven’t, be aware that GNU Emacs is a very powerful text editor that probably runs on any computer you’ve ever edited a file on or ever will. Although calling it a text editor is a profound understatement. It could as easily be considered a software development environment (IDE), an office suite, or a personal information manager (PIM).

Learning GNU Emacs, 3rd Edition is an excellent way to get started. Yes, the book was last revised in 2004. But even the 1991 first edition is still useful—one of the strengths of Emacs is that the basics are stable. Continue reading