Author: lubkin

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.

Writing bad checks

lubkin0 comment

Don’t write checks on someone else’s account.

One of the quickest ways to damage a relationship is to commit someone else to a task or a deadline without discussing it with them first. Whether it’s promising your spouse will chaperone a field trip, the assault team can rescue the hostages, or the spacecraft is go for launch.

Don’t commit to yes. You need to discuss it with the team. Do commit to that and to when you’ll be back with an answer.

It may ultimately be your decision. But everyone appreciates being consulted and resents being ordered. Be a leader, not a boss. Plus there might be a fundamental reason why what was asked for simply can’t be done, period. That they’d tell you if you ask.

Of course, you also need to be someone they feel safe to tell the truth to, and want to.

And it’s greatly to his credit

lubkin0 comment

I realized at some point that I am at core an engineer. Other things too. But I, engineer. I engineer. Aye, engineer!

Later that the maxims I apply on the job are useful throughout life.

I think I’ve learned a bit worth sharing. In my own exploits, and from the great engineers I’ve known as colleagues, friends, or family. (We’ve been at it for four generations so far, starting in 1928. Computers since 1946. I’ll get into the backstory later.)

I’ll delve into minutiae when it matters. It often does. While the specifics are apt to relate to software engineering, you shouldn’t need a background in either software or engineering to get my point.

Of course, sometimes we’re in the weeds to discuss weeds. If your mind wanders, stick around. We’ll be back to interesting soon enough.

You’re invited to opine too. This should be a conversation among colleagues. But read the comment guidelines before you do.