My wife, the molecular biologist, tells me she spends her days “at the bench” and “in the hood.” There, she works with cells, plasmids, RNA, enzymes and buffers, incubators, water baths, columns, gels, filters and spectrophotometers. She transfers various quantities of liquids into and out of plastics and glassware. At least, that’s what I understand when I ask her, “how was your day?”
I can’t really understand her fascination with all of this, but then I don’t have to: I’m an app developer, a programmer who designs and builds applications for smartphones and tablets. My work day consists of sitting in front of a laptop, cranking out code. There’s the occasional break afforded by meetings and presentations, writing up design documents, sketching out how a user interface might look like. Then it’s back to the computer, and programming.
But in spite of these differences, there is a critical aspect of my wife’s work that, whenever she speaks of it, I immediately recognize in my own professional life: We both rely extensively on kits and components, and doing so profoundly affects the way that we approach our jobs.
Kits aren’t just sophisticated tools – every field of human endeavor has those. They package together all you need for performing a specific procedure, along with clear directions how to use them, that you can then incorporate as part of a more complicated experiment or program. Working with kits involves knowing how to string a sequence of them together so that you go from your starting materials to your desired results. This holds true in both computer science and molecular biology.
I suspect that one of the reasons for this similarity has to do with the kinds of insidious errors that can infest both experiments and programs, and frustrate even the most carefully laid plans. In the earlier days of computer science, before kits and components became commonplace, the programmer had to write pretty much everything by hand. So even as she concentrated on the overall architecture, goals and flows of the program, the programmer had to manage the computer’s memory, access to disk drives, and the like. Any error in such underlying tasks would “bubble up” and crash the whole program. And detecting these bugs is an art form of its own.
Components solved this problem by bundling common actions: Accessing a database, drawing a text box to the screen, or making a web request, that could then be strung together to make up an entire application. The beauty of using such components is that they’ve been battle-tested in hundreds of other programs by thousands of other programmers. If there’s still a bug in your program, it’s highly unlikely that it’s hiding inside one of these components. Debugging programs becomes, if not quite pleasant, then at least something tractable.
From conversations I’ve had with my wife and other molecular biologists, I believe that the same is true of lab bench work: Every mundane step in a procedure introduces new and exciting sources for errors that can wreck an otherwise beautifully designed experiment. Freeing the biologist from having to worry about, say, isolating their own restriction enzymes, or having to jerry-rig their own RNA purification procedure, brings much greater confidence of success. If something goes wrong, there are far fewer places to re-test. And in the case of lab procedures, redoing an experiment with modifications to find the source of error can take days or weeks – something that boggles my programmer mind, used as I am to re-compiling my code in a matter of minutes or seconds.
The price I pay for the vastly accelerated progress afforded by the use of kits is a loss of control and understanding. I no longer really know what network magic goes on behind the scenes when I employ a component to, say, access a web page on my behalf. All I know is that the component comes back either with the webpage’s content in hand, or with some error message that I can act upon as I see fit. I know some programmers who find this “black box” aspect of components unnerving, and others who find it liberating. I usually count myself in the latter group, but I wonder, how do biologists feel about the take-over of their field by kits: Do you, dear readers, feel that molecular biology kits hide too many important details in their quest for simplicity and reproducibility? Have you ever avoided using a kit because you felt that some of the underlying science wasn’t adequately explained?
Maciek Smuga-Otto
Latest posts by Maciek Smuga-Otto (see all)
- OneZoom, The Fractal Phylogenic Tree Explorer - May 24, 2013
- Science in the Service of Art - February 27, 2013
- How Is a Molecular Biologist Like a Computer Programmer? - October 29, 2012
Yes, I have avoided using kits. I hate it when companies don’t reveal what the exact contents of “buffer A” etc are… Then I’d rather go for the old-fashioned way and be sure of what I’m doing. Unless a few colleagues can convince me with independent experiments that those kits really do what they promise and nothing more or less!
Hi trockeneisbombe,
I know that what helps me accept the use of “black box” components in programming is the presence of a large and active online support community: Other programmers who use a particular kit or component are usually more than willing to help out when I have a question regarding its use.
This is probably similar to what you’re asking for, and for what it’s worth, I’d be wary of a component if I felt I was the only one out there using it. Which leads me to wonder: Are there online communities of biologists willing to contribute their experience with kits to the common good? And would this be enough to overcome your understandable reluctance?
Reblogged this on Promega Scientific Training.