As you know from my previous blog entries, I’m a biologist who makes lab equipment for a living. In my new work life as a machine builder, I spend much of my time working with engineers. It’s great fun, and I’m learning tremendous amounts from them.
One of the most interesting parts is what I think of as the “engineer mind.” Even though science and engineering are both very analytical disciplines, I’ve noticed a more subtle difference in how I was trained to deal with unknowns vs. the way they were. To put it on a bumper sticker, they reason and I interrogate.
Biologists see the world as having sense and order, but also an element of unpredictability. One of the things we internalize is that our experimental organisms are complex (even the viruses) and, more importantly, that they’re not fully understood. We expect our subjects to act funny every once in a while. I still have a sign with the Harvard Law of Biology on it: “Under the most rigorously controlled conditions of temperature, volume, humidity, nutrient levels, and other variables, the organism will do as it damn well pleases.”
We don’t design our critters or cells: we work with them, come to understand their quirks, and learn how to experimentally poke them in an informative fashion. At some level, I think we all tend to think of them as black boxes: comprehensible, but imperfectly comprehended.
Engineers do not think like this. If there was one single thing that gave me some culture shock in my new career, this was it. And nor should they. An engineer’s work revolves around designed things, not grown things. That’s not to say that engineers ignore chance and unanticipated effects: they build bridges that have to stay up, and pacemakers that had better keep working, so they can’t ignore flaws and chaos. But they seem to start from design and test its limits, whereas biologists often parachute into unknown intellectual territory and set about making sense of what they find there.
Learning the bioinstrumentation trade means learning to use theory first. It is infinitely more efficient to choose components and materials with known properties and put them together in specific ways than it is to take a pre-existing machine and tweak it until it does what you want. Evolutionary processes can create magnificent devices, but they take a lot more time and money than your average company has.
Experimentation also isn’t the best way to understand a machine, at least not at first. Unlike organisms, machines come with an operator’s manual. There will be drawings and diagrams and descriptions that explain the designer’s intent, and how the item is supposed to function. Reading these is a lot more productive than experimenting on the machine to see what it does. (Of course, that’s why people use model organisms, too – better manuals – but E. coli isn’t nearly as predictable as a machine.)
So, does that mean that a biologist’s training is not useful in a machine shop? Definitely not, because there are times when you didn’t quite build the machine or computer program that you intended to. I’m a programmer, and I can tell you that computers are actually very obedient. They do what you tell them.
The problem is, they do exactly what you tell them to, even if you meant to tell them to do something else. If your design is acting wonky in a subtle way, it’s sometimes faster to treat the machine as a partially-understood “black box” and feed it informative inputs – you know, the way biologists approach experimental organisms.
Quite often, my colleagues and I find ourselves dealing with a machine that is Not Behaving Itself. In some cases, it’s because we don’t have a fully functional design for one of our new inventions–what an engineer friend of mine calls “reality failure” is a fact of life during the prototyping phase. But we also get the occasional returned item, and some of those have either broken in shipping or have been modified by the scientists who use them. In all of these cases, we have some unknown variables in play.
When that happens, the engineers usually try to theoretically understand the mechanics and then implement a solution, while I instinctively hypothesize and perform a series of informative tests in order to understand the underlying mechanism.
This approach can be especially useful when it helps us uncover additional variables that we weren’t previously aware of, odd behaviors in one of the components we buy, or changes in one part of a device that caused unanticipated changes in another. In those cases, someone who’s used to designing and running experiments to tease out unknown properties can be a handy member of a team.
I think the engineers have been observing my thought processes, too. Recently, we were working on a program for the microchip that would control one of our new products, and we were re-using a piece of code someone else had written for a previous project. The program was behaving in a way we didn’t expect, and I suggested we send a group of carefully-chosen numbers at the function in question and figure out its behavior based on the output. Our product development manager started to laugh and said “You are such a biologist.” (He admitted it would work, though.)
So, if you find yourself in a design-driven workplace, don’t give up on those experimental skills. They aren’t always the first intellectual tool you should reach for, but sometimes they’re just what you need.