Month: December 2014

All in the Family – Samuel Becker

lubkin1 comment
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

lubkin0 comment
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

lubkin0 comment
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

lubkin0 comment

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

lubkin0 comment
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

lubkin0 comment
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

lubkin0 comment
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 →

Flying in close formation

lubkin0 comment
When you’re over Mount Rainier, you want your pilot flying an airplane, not 100,000 parts in close formation.

Companies don’t ship software. They ship products. (Or deliver services. Same thing.)

A product has (at least) code, test code, graphics, documentation, training, customer support, marketing, sales, advertising, technical marketing, HR, maintenance, legal, accounting, other products it needs to work with, and a bevy of external partners—alpha and beta participants, investors, administrators, recruiters, third-party developers, book authors, industry writers, competitive partners, customers, and end-users.

And you succeed if the entire product succeeds. Not just your corner of it. Continue reading →

The Design of Everyday Things

lubkin0 comment
I’ve always been interested in human factors. That is, ergonomics or usability. I think I’d first heard of it as a kid, as applied in the Gemini space program. Which guaranteed I’d want to know more.

My opening was in graduate school. The only class offered was in the Department of Agricultural Engineering. One assignment: Here’s a hall of farming machinery. Analyze the ergonomics of each vehicle’s controls and displays.

But it was Don Norman‘s The Design of Everyday Things that fanned my interest into a lifetime zeal for usability. He “places before mankind the common sense of the subject, in terms so plain and firm as to command their assent.” (1776, book by Peter Stone.)

Thence I rage at shoddy design. Especially when those subjected to it blame themselves. Oh, I’m such a klutz. I’m not that good with technology…. No, you’re not that good with poorly designed tech.

Norman is always worth reading. But for me, that first retains the glow of first love.

Beware of strange faces in dark dingy places

lubkin1 comment

I’ve been on job interviews where the interviewer writes the equivalent of char *(*(*a[])())() on the whiteboard and asks what it declares.

I usually answer that I could probably figure it out but I’m not going to try.

If we, smart as we are, have to scrunch forehead to decipher a line of code, it’s probably a mistake to have written it that way.

If it’s unclear to you now, it will probably be less clear when you look at it again in six months. Less clear to the engineer who has to fix it after you’ve moved on. That way lies bugs.

Further, if the code relies on an advanced or obscure feature, who says that feature works correctly? It’s probably also a confusing facet of the language for whoever wrote the compiler code. And their interpretation might not match what the standard actually requires. Or how the authors of another compiler interpret it.

Let alone whether you can readily translate your approach into another language. Which is handy.

Sometimes a complicated construct really is the best solution. When it is, write as clear a comment as you can that explains what it does, why it’s correct, and why apparent alternatives wouldn’t have worked.