Category Archives: Uncategorized


(Ideally, these things would actually be published on my birthday. But.)

Greetings, humans. I have survived another trip around the sun. This one is not quite a prime number, which is code for: boring. The next one is code for: old.

Being born in December means: it's ambiguous when I'm thinking about the last year as an end-of-year review or an end-of-my-year review. Not sure it matters. We can replay content here. Look at the URL.

I weigh 67.7 kg (149.3 lbs). I am—I assume but can not be bothered to measure in the last *checks watch* decade or so—5' 8.5" (174.0 cm).

I am, as of recently, the Test and Integration Lead of a pseudo-proprietary program at Boeing in St. Louis. It's not proprietary in the sense that I'll go to jail talking about it, but proprietary in the sense that they might make more money if I don't talk about it. I don't worship money, but I believe that someone will collect what I owe on my mortgage if I don't pay for it, so I Don't Talk About It.

I am still trying to learn Chinese, and it's still impossible.

I am a student at Washington University in St. Louis.

I am.


I am trying to get by. But I'm also, really, powersliding the turns, foot on the accelerator, aiming for the gaps that the Squares don't. (Raise your hand if I've given you the ol' left-right jab to the kidneys at work.) But I'm also a Square.

I am on a planet, which is rotating, which is revolving about a star, which is revolving about a... who knows, who knows... it's so complicated.

So much of the world makes sense until you expect precision or 100% reliability. Then the wheels fall off. To wit, I offer you the three-body problem. Although I don't remember all of the specifics of AAE 306 Orbital Mechanics with Prof. Conway in Fall 2002, I still remember the implausible idea that solving for the position, velocity, etc., of three bodies that are interacting with each other eventually devolves into chaos. I mean literal chaos—you can't solve for the specifics. But ask me any specific things about AAE 306 or anything else and I'll have to shunt you off into chaos faster than you can say "impulse".

Where were we?

I've got a better handle on tools—power and otherwise—than I used to. No eyes were lost. Many shelves were made. Muy hombre.



I wish I had read more books, but I didn't.

I wish I had cooked more dinners, but I didn't.

I wish I had learned more statistics/probability, but I didn't.

I wish I didn't wake up so often at 04:30 to get things done that I didn't.

I think the impulse is: get more things done. I think the impulse should be: get fewer things done, but make sure they're the right things.

Feel that blood pulsing. It doesn't do that when you're dead.

I didn't run any races this year. I still tune into the results for the Boston Marathon or the Western States Endurance Run. Our identity is so much more than what we're doing this instant—for good or ill. Our identity is aggregated over time.

By "our" I mean "my". I'm sorry. The words just fall out of my head.

I'm going to spoil the movie for you:

Everyone dies in the end.

But it's more complicated than that.

You alone get to decide if that matters. Is it a maudlin curse? Is it an inevitable conclusion? Is it a constraint? Is it freedom?

It depends.

I have moods. I think you have moods. Sometimes "the end" is a gift and sometimes it's a debt. Either way, don't take it too seriously.

I have gray hair—on the sides, at least, and some on my face, and supposedly I'd have some up on top if that hair had bothered to stick around. It doesn't bother me. Let it do what it wants.

I have no plans for the future. I haven't reached that crystalline point of let-it-happen but I'm amenable to the idea.

I am...

I am?

I am.

And that's that

After taking a final exam for DAT 5402 (data analytics for business leaders) this afternoon, the semester—and it still feels outmoded to measure the passing of time that way at this stage—is effectively over.

The last four months have been busy—subtly so. Typically when I think of busy-ness, or of running short of time, I think of The Grind—when there's so much to do and you just have to put a shoulder to the work and keep pushing and pushing and pushing until it's done or the time's run out. The last few months were slightly different. There were aspects of The Grind, but on balance the work was easier, it's just that the time somehow seemed to be accounted for so much more completely.

Moving into the house and starting the Tuesday/Thursday evening PMBA program at the same time turned into the biggest test of time. One weekend, we moved into the house. The next weekend I had the kickoff weekend for school. And immediately, I was behind on all fronts. Then on and on in a feedback loop. Losing a weekend of unpacking and building at the house meant I fell behind there. Using Monday and Wednesday evenings to catch up on the house meant falling behind in school. Like drowning, it wasn't necessarily the water itself that was most threatening but the thrashing about to stay above water—the thrashing saps energy and will at the expense of The Goal, versus the in-the-panic counterintuitiveness of simply floating.

Floating is a good solution. Floating is focus. It's focusing on the one thing that really matters—not even keeping your head above water, but just the bits that need to be above water.

So this week starts a break from school until sometime in January. And this week is the last week of work for the year—if you can call it that, once the reality of staff discovering their unused vacation and sick leave sets in. The cycle eases itself a bit. I'd like to lay on the ground, one side of my face in the dirt, and just witness the world from the vantage point of a worm. Don't bother me—it's the season for hibernation. But. The downcycle is the best—sometimes the only—opportunity for reflection. Doing and reflecting are necessarily opposed. Each requires the focus that the other requires. Where do we go from here? And where is here? And how did we get here? It's not really about getting ahead of the future, but getting down into a coiled position, alert and prepared to grapple with it when it arrives.

I don't know if it fits, but that last brooding passage from The Great Gatsby floats to the surface of its own volition:

Gatsby believed in the green light, the orgastic future that year by year recedes before us. It eluded us the, but that's no matter—tomorrow we will run faster, stretch out our arms farther. . . . And one fine morning———
So we beat on, boats against the current, borne back ceaselessly into the past.

The ritual of the notes

At work I'm fairly methodical about planning ahead for the next day, week, month--almost as methodical about planning as I am about disregarding the plan when the time comes. It involves OneNote and I should explain it sometime--it's a useful system.

One key part of it is making a new note page for every (pertinent) meeting in my calendar. It serves two purposes: (1) to line up the day's or week's events; (2) to catch notes from the meeting. The first part I'm good at; the second part I'm not.

I think that a slight frame of reference shift would improve the actual keeping of notes. I tell myself: it's about the information. It's about keeping receipts. It's like an old school engineering lab notebook. (A fine ritual itself.) But I don't think that's the most useful thing. The notes themselves aren't as important as the ritual of the notes. Why don't I write meeting notes as frequently as I think I should? Can't keep notes when you're not paying attention. Can't keep notes when you're talking too much (or doing that thing where you're just waiting for an opening to talk). Being present in that moment is the real value.

I am good at keeping notes when I am or feel responsible for keeping notes for the group in a meeting. Perhaps tapping into that is another method to self-motivate.

Metrics and their discontents

A fair amount of my job involves figuring out how to collect some data about work processes and... well, just packaging it in a table or chart so that managers can, presumably, use it to make decisions. Sometimes it's interesting because you have to get down into the esoteric nuances of the definitions involved in the data, debugging things along the way to get the data right and the right data. Most of the times it's just work.

But sometimes there's a little itch in the back of my mind that seems to indicate: maybe we don't need to do this. Or: maybe we're not measuring this right and someone who isn't us, whose work we're overseeing, is going to pay for it. Or: aren't we just expressing the same measurement in three different ways that say the same thing. And so on.

Measuring work is somewhat enjoyable, in the sense that you and your team can get better at what you do, but the time spent doing the measure sometimes also unironically eats the time you would spent doing what you do, which drives an unironic feedback loop of more measurement, less doing. It's frustrating.

There's an art involved in selecting what to measure, how to transform it, how to show it, who to show it to, how to use it, etc. I'm not an expert. But I think the most important question is: how am I going to use this? If the measurement doesn't have a specific use, throw it out. Go lean. Collecting for the sake of collecting is a disorder--hoarding. Side effects include: what's measured gets managed, even the data you collected that doesn't have a specific useful purpose. Don't believe it? Hand your boss a chart with a downward-pointing graph. Exchange your dignity for a few action items.

Fuzzy ideas, fuzzy ideas... I can't quite put my finger on what I think the problem is. In the meantime, a reference that for me has turned into a source of references, and a comfort when I think I'm the only person wondering why I'm carrying this bag of numbers around everywhere: Jerry Muller, The Tyranny of Metrics (2018) (notes).


It's just as well that I haven't read David Foster Wallace's A Supposedly Fun Thing I'll Never Do Again, because this presentation I gave last week on lessons learned from the excesses of running 100 miles in a past life would have been besotted with footnotes.

(Pause to read: David Foster Wallace, "Shipping Out: On the (nearly lethal) comforts of a luxury cruise", Harper's Magazine, Jan. 1996.)

For our MGT 5315 Leadership Communications I class, we were instructed to give a 4-minute "TED" talk to the class about... actually I didn't read the assignment, so I'm not 100% sure what the framework was. But: 4 minutes. Essentially nothing. The question for me was: should I recycle the Apollo 11 presentation I gave over the summer at Venture Cafe? Or go for something different.

Let's talk about a supposedly fun thing I'll never do again: running the Western States 100.

Honestly: 4 minutes isn't enough to say anything about anything, so I just pulled together a few lessons learned from the race, then threw some away, pared it down some more, then let 'er rip.

It's no good posting my slideshows here (eh, pdf, here you go) because I do what I think any humane person ought to do: rip out the content like old wallpaper. It's an experience. You've got to be there. It requires gaging the audience like a barometer, then—somehow—adjusting the talk as it goes. Each audience environment comes with its own terrain, and if you can feel the contours of that terrain you can find different approaches to where you want to go—you can even find different places to go. I don't understand it. It's some alchemical process that transforms anxiety into rocket fuel.

I very much enjoyed telling a story that I never get to tell. (#2: F*** gear.) Somewhere around mile 15 or 20 or so, someone who I was passing, one of the multitude who confuses the things you run with and the run itself, asked about my shirt:
"Is that a cotton shirt?"
[long pause]
"Is that OK?"

The best part is the deke at the end. Start off with some high quality TED-cult content (#6: Don't quit)—which is all very well, good advice, etc.—and then waiting until the audience leans that way and edging it back for the score (#7: Quit). Which, by the way, is better advice. How many people in the world give you the "never give up" speech without any context whatsoever? These people don't have your best interests at heart. I only dropped out of one race, the 2012 Ozark Trail 100, at mile 50, though if ego hadn't gotten in the way I would have dropped out when I should have at mile 37, saving myself weeks of recovery on a bum leg. Never quit. No. Never never quit. Quit in context. Live to fight another day.

Sit back, relax, and enjoy the flight

Flying is de rigeur now. Has been. I don't notice so much the outside of the plane--the environment through and over which we're hurtling. No more counting grain elevators until they're flat with the perspective. No more noticing the creeks and rovers like fire as they briefly reflect the sun. No more naming the features down below. Looking out the window, when it happens, is just to watch the flight surfaces trim slowly back and forth. (Until it's speed brake time.)

It's all still there if you want it. The magic or wonder of those first (many) flights isn't really replaced by anything. Flying is now just the simple subtraction of distance. Step in a tube on one side in St. Louis, step out the other side in Shanghai--an ellipsis in between. It's still about sitting back back, maybe a little more relaxing, but a little less enjoying the flight.

Hysterical and useless

This song popped up on a random play of my entire music library today, and it surfaced some memories with it: Radiohead, "Let Down", OK Computer (1997).

Mostly I remember it because I would sing the lead part during the bridge, and Sunil would sing the harmonies—although I only specifically remember playing it at The Embassy in Urbana in 2003, we might have played it elsewhere.

I also remember it because of a few recurring lines that have always stuck with me, for whatever reason:

One day
I am gonna grow wings
A chemical reaction
Hysterical and useless
Hysterical and useless

I don't know what Thom Yorke intended with that. I don't always know what I take from it. "Hysterical and useless" sounds bad, in isolation—but isn't that how you could describe all of our flights from who we are and what we are? To some extent, don't you really have to reach beyond your grasp to become something new, something different?

Systems engineering and agile

A few weeks ago, the INCOSE Midwest Gateway Chapter (the local professional society for systems engineers) hosted an event called Agile in Systems Engineering. Basically, I begged one of our directors, Adeel, and one of our best members, Matt, to explain to systems engineers what the hell agile development is. Whether it's a fad or not doesn't matter. If you're going to be exposed to it, you should know more about it. Even if it is a fad, you should steal the good parts mercilessly and incorporate it in your repertoire.

Systems engineering and agile development (agile software development, at least) are fundamentally opposed. We're not supposed to say that out loud, but it's true. Systems engineering is largely a top-down decomposition from what a customer wants to how a system should satisfy that to how subsystems should support the system, and so on. It's about definition and control from the top. Agile is more about bottom-up. Develop the system by developing the system—develop the system (software) by doing it, and respond to changes as they come.

The problem is not that there is one idea or the other but, inevitably, when a top-down organization wants to incorporate agile or a bottom-up organization wants to incorporate systems engineering, there is capital-P Pain.

I am living in capital-P Pain.

The purpose of my life at work right now, as a systems engineer in an organization that wants to pursue agile software development in an environment of top-down control, is to serve as a kind of buffer. On one hand, I'm trying to be a buffer to block the software developers—the people actually doing the work—from the vagaries of the people who own the project schedule. (See also: Shield.) Agile is, in very rough terms, about establishing a backlog of work that needs to be done for a project, and then selecting the most important bits of it that can be done in a sprint (two- or three-weeks). As the people up high want to shift the schedule, they lose patience with the priority of the backlog and the sprint, and they (naturally) want to adjust it. But that's not allowed. Make a plan and stick to it.

On the other hand, I'm trying to be a buffer to block the specific details of what the developers are doing from the managers. If you try to say specifically that today was a slow day and yesterday was a slow day because the work being done is subtly difficult, the top-down managers only see a blinking red neon sign that says LATE. So it takes some finesse to translate the work being done, or the preparation for the work being done if there aren't any discrete accomplishments, to keep the managers from bothering the developers to death.

So a lot of working as a systems engineer in an agile environment—an agile environment in a large organization used to top-down control, at least—is about acting as a translator between two fundamentally opposed paradigms. It's thankless work of questionable utility. It takes a lot of time and effort to translate schedules and still, at the end of the day, some joker will come up and ask you: why aren't your requirements done yet?

So I'm thinking to submit an abstract to the 2019 INCOSE Great Lakes Regional Conference (call for submissions to talk about this. Many people, in my opinion, spend their time in top-down or bottom-up jobs, so maybe it's time for somebody to provide some kind of Rosetta Stone to link the two together. At the very least, it might cause me to crystallize some things I do in my day-to-day work. Stay tuned, etc.

Now reading: Digital Apollo

David Mindell, Digital Apollo: Human and Machine in Spaceflight (2008). (Goodreads/review - notes)

I found this book while searching for more information about the Apollo Guidance Computer in preparation for a talk (see: Landing on the moon: three visions attained). Fortunately for me, the nearest St. Louis County Library branch to work had a copy.

I had assumed the book was just about the computer itself, which was why I got it, but at ~80 pages in, it really hasn't been covered except by reference. Instead, what the book has covered is something that I recognize from developing flight controls back at Mason, and to some extent in systems engineering in my current position: the tension between the human pilot and the automatic pilot (and by extension its designers). It's an inevitable tension—in simplistic ego terms, the fight between controlling and being controlled. In more sympathetic terms: it takes more than equations to design and more than human experience to fly a sufficiently complex aircraft.

So: straight ahead, learning more about X-15, etc., until I get to the parts about the AGC and flight software that I wanted to learn more about. In the meantime, the book has also been the source of some interesting citations:

[p. 73] In those days, airplanes were unreliable and I thought they might become more so. I never flew without a pair of pliers, a screwdriver, and a crescent wrench in pocket so I could fix things on the airplane. This was being a mechanic, not an engineer. I had applied for the Engineering School because I thought there should be a better rapport between the aeronautical engineer and the pilot. It seemed to me that the engineers felt pilots were all a little crazy or else they wouldn't be pilots. The pilots felt the engineers as a group were, if not incompetent, at least not thoroughly acquainted with the pilot's viewpoint—that all the engineers did was zip slide rules back and forth and come out with erroneous results and bad aircraft. I thought from a philosophical point of view that it would be good to have engineers and pilots understand one another better. It seemed desirable to marry these two capabilities in one person—and I wanted to be that person.

—General Jimmy Doolittle, I Could Never Be So Lucky Again: An Autobiography (1991)

To train the pilots for the X-15 landing phase, several methods were considered. First, an analog computer was used with an oscilloscope presentation to indicate approach attitude. This gave the pilots and engineers an understanding of the relative importance of the factors affecting the landing flare, but definitely lacked the in-flight realism afforded by the rapid approach of the ground.

—Dick Day, Training Considerations of the X-15 Development, NSIA Meeting (1959-11-17). In: Gene Waltman, Black Magic and Gremlins: Analog Flight Simulations at NASA's Flight Research Center, NASA SP-2000-4520 (2000).

Landing on the moon: three visions attained

A follow-up to: Systems engineering and Apollo

The trouble of talking about the Apollo program, without resorting to tropes—redacted comments about how the same people who brag about being able to design things to land on the moon when they were in their 20s with no experience whatsoever are the same people who require you to go through twelve reviews to publish a test plan that they still have veto authority over if it passes—is that there are still a million things to cover.

I think that if I do go ahead and give this talk in July that I would focus on the landing. I got some interesting feedback about mission design and about the Saturn V rocket, but it's still the landing that most captures my imagination. My parents gave me a copy of Tom Kelly's Moon Lander: How We Developed the Apollo Lunar Module (2001) (notes) sometime when I was in college, and I still offer that book as an example when people ask for a book about systems engineering. The book even mentions systems engineering by name, which I didn't realize until I was reading through it again (I wouldn't have known what that meant in college anyway, though that matches fairly closely what I was doing on projects, etc).

"Three visions attained". That idea is ripped off from an interesting New York Times Magazine article about Robert Moser Neal, Frank Lloyd Wright, and Alex Jordan Jr: "Wisconsin: Three Visions Attained" (1993-03-07). It's a good article—read it. I like it because (1) I lived in the Driftless Area for a while, (2) The House on the Rock is one of my proto-memories from summer vacations while growing up, and (3) for reasons I don't understand Frank Lloyd Wright is a Midwesterner who is To Be Revered As A God. Just read it.

I don't even care if I give a talk or not. Just thinking about it, and organizing my thoughts, is a kind of love letter to the idea of space travel that has more-or-less been shelved. So be it.

But: landing on the moon. What would the three visions be?

The first one is easy: Tom Kelly—the guy in charge of the Lunar Module program at Grumman. So: talk about the design of the Lunar Module.

The second one also presents itself: John Houbolt, the chief instigator of the Lunar Orbit Rendezvous mission mode of landing on the moon.

And the third one? Open.

The temptation is to dig deep into something esoteric. Space suits. Display panels. Apollo Lunar Surface Experiments Package (ALSEP). Software... bingo. Maybe it's a good place to talk about Margaret Mitchell and the flight software on the Apollo Guidance Computer.