“The fact I can talk to people in no way obviates my desire (yes, desire) to handle a fine machine. I drive a fast car with a big engine. An old Leica camera -- miracle of graceful glass and velvety metal -- sits in my palm as if part of me. I tried piloting a plane just to touch it: taking the yoke into my hands and banking into a turn gave me the indescribable pleasure of holding a powerful machine while it held me. I'm an engineer for the same reason anyone is an engineer: a certain love for the intricate lives of things, a belief in a functional definition of reality. I do believe that the operation definition of a thing -- how it works -- is the most eloquent self-expression.“
- Ellen Ulman, A Life In Code (2017)
It is perhaps hard to tell these days, but I am an engineer at heart. My earliest memory is watching an artist's rendering of the Juno probe arriving at Jupiter in the then-distant 2016 and deciding that I would be an astronaut. Self-doubt slowly eroded this into a more modest desire to be a rocket scientist and facing the reality of what most rockets are in fact used for (primarily murder, secondarily establishing telecommunication monopolies) pushed me away from physical construction and into the abstract but seemingly safer realm of the social sciences.
And yet, the central impulse remained: I wanted to be close to the machine. To study the math, to learn the models, to watch the systems, to feel like I was connected to a great machine of unmatched power, a fine web of interlocking systems that flowed together, fascinating alone but truly beautiful when tied together to simply function.
Of course, it is easy to get lost in the sauce. To assume that just because you find something cool everyone else will, or more abstractly and harmfully, that since a solution is particularly ingenious for one problem it will just naturally expand to do good things in the world, eventually becoming beautiful for all, is the most common mistake among anyone who really appreciates machines.
At the end of the day, the machines we make are only as good as the uses people come up with for them. It doesn’t matter how compact the units are if nobody can repair them, how shiny the chrome if it immediately gets scratched, or how potentially game-changing the feature if your boss doesn’t see it expanding profit margins. These are all essentially design problems, but they are all design problems defined by the people who surround the machines, not the machines themselves. Thus, to make sure that the machines are useful, not just beautiful, we have to learn to communicate with the users, either to get them to use the machines better or, more likely, to get us to make better machines.
I am not the first person to have these ideas. They seem to even be articulated in any basic description of the design process (“First, identify a problem…”) but there are shockingly few venues for this to happen. Engineers will spend years learning the nuances of the machine with the careful guidance of learned professors, but are expected to just figure out for themselves how to effectively communicate their ideas and find real problems to solve. The aim of my club is (partially) to provide a space for developing these skills.
The essential form is a variety of guest lectures, about 10 minutes long, given by a mix of people from very different parts of campus. Each presentation will have an attached Q&A, as well as a whole bunch of unstructured time to mingle. Take this as an opportunity to learn how to tell people exactly what the thing you want to build will do for them, or find out whether what your building will really do anything for anyone– or if you have something non engineering related, bring that too. I am getting people together to speak at the first meeting, January 23 starting at 4pm , so if this interests you at all shoot me an email and I will write you in for the first meeting.
e.f.saltlake@gmail.com