J Ben Deaton

Thesis to committee

Yesterday, I uploaded a 355 page pdf, ordered six bound copies, and delivered the final draft of my dissertation to my oral defense committee members. My PhD defense is December 17th.

Then I went home and literally slept 12 hours. I had previously thought I was well past the era of all-nighters, but these past two weeks proved me wrong more times than I care to admit publicly.

After all these years of labor, the only word that adequately describes yesterday’s experience is: surreal.

How user-friendly should technical software be?

Imagine you are writing software someone else will use for one of the following life-critical scenarios:

• Design of a nuclear core containment structure
• Design of an emergency backup power system for a hospital
• Stress analysis of an artificial heart valve prototype

You obviously don’t want your software to be misused. What I mean is not that someone uses it with malicious intent, but rather someone uses it inappropriately—either because they don’t possess the expertise in the problem domain or they do possess the expertise but perhaps don’t accurately understand what your software is computing—and Something Bad Happens. Human life is threatened. Money is lost. Property is damaged. Lawsuits abound. You get the idea.

When that happens, is it your fault as the software developer, or not? It wouldn’t be that hard to absolve yourself of responsibility because, after all, your software shipped with a detailed disclaimer about how it’s not even necessarily correct, and that person using it obviously should have known better. But it doesn’t mean you shouldn’t try to minimize this possibility.

Technical software is easier to use than it’s ever been. Users of such software would certainly agree this is a good thing and has improved productivity. But on the other hand—and I am speaking for my industry of structural engineering design software—the unprecedented ease by which you can click a couple buttons and design a building… is actually quite terrifying when you stop to think about it.

Fancy dialogues. Beautiful contour plot animations that make your clients cry.

And results that might be completely wrong.

How can we can set the bar higher? Here is my idea for developers:

Insert roadblocks into software workflows which demand expertise.

Make it so the unqualified user can’t get to a final result without their ignorance being challenged.

I’m not saying to send engineers back to the olden days. You’d be crazy not to take advantage of pandas if you are a Python programmer or automated mesh generation algorithms in FEA, for example. But at some point—and preferably where a lot of assumptions reside—stop holding the user’s hand. Don’t pre-fill certain dialogs with default parameter values. Treat certain parts of the model definition like a technical challenge—solve this riddle to proceed. (What is your quest? What is your favorite color?) Point to resources that guide parameter or algorithm selection, but do not do it for them.

I’ll end this with an example from my personal experience where I think software developers got it exactly right.

Several years ago I had to solve a concrete failure problem in Abaqus, one of the standard finite element codes in the mechanical, aerospace, automotive, biotech, and defense arenas. I was using the so-called concrete damaged plasticity model (Lubliner et al. 1989 and Lee and Fenves 1998). Abaqus is probably best-in-class in terms of model visualization and creation—I don’t know a faster path to a detailed and accurate finite element mesh. I love Abaqus.

But when it came time to define the nonlinear material model, I could not move past this stage without deep immersion in the source journal articles. It took me weeks to understand the formulations well enough to define the material input. Yes, they could have pre-populated the material definition dialogue with default values. But I think Abaqus got it exactly right here. Their “limitation” forced me to take responsibility in a way that I couldn’t circumvent. My results were all the better for it. (As a side note, there are multiple peer-reviewed publications simply exploring how to determine the input parameters for this particular model—it’s not just me.)

Monumental pain? Yes, but that’s my job as an engineer or scientist.

And it’s your user’s job as well.

Heilmeier's Catechism

Here is a helpful set of questions to ask yourself before embarking on your next project, attributed to George Heilmeier:

• What are you trying to do? Articulate your objectives using absolutely no jargon.
• How is it done today, and what are the limits of current practice?
• What’s new in your approach and why do you think it will be successful?
• Who cares?
• If you’re successful, what difference will it make?
• What are the risks and the payoffs?
• How much will it cost?
• How long will it take?
• What are the midterm and final “exams” to check for success?

Unfortunately, I cannot guarantee that asking these questions will result in great enough work that you will get a catechism named after you.

How much would you say you work?

From the New York Times Economix blog:

Americans tend to overestimate how many hours they work in a typical week by about 5 to 10 percent, according to study published in a Labor Department journal, with the biggest exaggerators being people who work longer weeks.

The typical person who reported having worked 40 hours, for example, actually worked closer to 37. The report found that “The greater the estimate, the greater the overestimate”; people who said they worked 75 hours actually worked closer to 50 hours. At the other end of the spectrum, people who worked relatively few hours (under around 25) actually tended to underestimate their hours.

Several years ago, I installed RescueTime to start quantifiably tracking my computer usage. The results were eye-opening to me. I learned:

• I spend much less time on the Internet (RSS and social media) than I would have guessed. Quantifying that was a big relief.
• The above estimates are reasonably consistent with the personal data I collected during graduate school. I attribute this to:
• There is an upper bound on the amount of hard concentration you can employ in a given day. You can’t be always-on and firing at full capacity. Besides the primary knowledge work that requires full attention, there’s email and other administrative things to accomplish. If you are “working” in your office for 8 hours a day, two 3-hour blocks of hard focus on your actual knowledge work (research, programming, writing, non-email) is probably a reasonable goal.

Toxic professional comparison

At the risk of getting a bit too honest, I want to talk a bit about the toxic plague of comparison in academia. While I’ve got academia in my sights today, I think my message today is more universal.

Early in graduate school, I fell prey to CV anxiety. I have no idea if anybody else has ever called it that, but what I am referring to is a constant worry that I would never build an impressive CV with as many papers as the next person. I hit a point where seeing another academic’s CV could sideline me for the rest of the day because I’d be convinced I’d never achieve as much as that person. It wouldn’t matter if it was another grad student or a retiring professor—I could find a way to normalize their achievements against mine in a way that consistently left me discouraged or even paralyzed.

I eventually hit a wall and had to get help, which I received at different levels and in different ways from friends, family, colleagues, and yes a therapist or two. What I eventually learned is this:

What other people accomplish has nothing to do with me. It says nothing about me. It is not targeted at me. It shouldn’t have bearing on my life.

Everybody achieves what they achieve in an entirely different context. By that I mean that everyone was raised in different families, went to different schools, was surrounded by different social circles, devoted themselves to different extracurriculars, developed at different rates (not only as children, but also as adults), entered grad school with differing grasps of mathematics and science, carries different burdens and life responsibilities, cares more or less, pursued PhD’s for different reasons, has an advisor with different levels of control of the project, and wants to do different things afterwards. Almost all of these are private factors that you will never know about others. Given all that, how do you expect to objectively benchmark yourself against someone else?

You don’t have to live up to what somebody else accomplished. That’s not to say there isn’t a threshold for what will earn you a PhD—there is. But within that framework, who really cares exactly how many or how prestigious your papers are as long as you’re happy, it gets you where you want to be, and you can be proud of who you are.

That person who accomplished n-times your output may have had to sacrifice something that would never be worth it to you. You kept your humanity and lived by your convictions, something far more important. And before anybody cries foul, I’m not saying that in order to be successful, you must have sacrificed something important. I’m more saying that you have no idea what another person’s life looks like behind the scenes and whether you’d want to live that person’s private life to have their public perception.

At the end of the day, do the best you can. It’s really satisfying. You’ll sleep better. Do live a curious life trying to learn and push yourself to get better, but for God’s sake, put down the stick.