by PhilipJ on 15 July 2006
I’m home in Newfoundland for a much-needed break from the lab, and given my distance from school right now (Google Maps says around 7500 km, if I were to try and drive back), I’ve been thinking a lot about life in the lab and graduate school in general, and what it is we’re meant to get out of this experience, particularly given my issues trying to re-transform my pPIU1 plasmid a month or so ago. I had an extremely strange result: DNA which I had previously harvested from a bunch of cells which contained antibiotic resistance genes against ampicillin no longer seemed to give cells antibiotic resistance to ampicillin when attempting to transform some E. coli cells again. This is assuming the plasmid DNA was able to enter the cells during the transformation protocol, but a control with another plasmid showed it should have worked just fine.
This takes me back to the biology is weird theme. Things which work just fine today can stop working tomorrow, and it is rarely obvious why. This is particularly true when you’re working in an interdisciplinary environment like a biophysics lab, where you have the optics junkie playing with cells. What I’ve been thinking about in particular is, how “long” (in the time domain) should your tracking-down-oddities persistence length be?
I’ve been given two very different answers from two very different people. The PI of the group we collaborate with said that one of the things she thought was critical to graduate school was learning when to give up on something that doesn’t make sense, when it isn’t central to your project. My end goal is to have an endless source of this particular piece of DNA, and if I’ve tried all the standard controls to make sure I’m not doing something wrong, or the cells are “bad” (ambiguous as that is), etc, and if I have a backup at her lab, then by all means stop trying to understand why, get some cells from frozen stocks left in her lab, and get back on track.
A fairly different take on the problem comes from Isaac, a commenter on the Pain in the USS peice who said (and I’m combining a couple of comments here),
Debugging is a pretty key skill. Itâ€™s very tempting to move on, but catching problems and being observant will help you in the long run. Experiential knowledge will tell you when some new observation is important, even in some of the most prosaic of techniques.
Iâ€™m not quite done with graduate school, but looking back on things, the most important thing to me so far has been figuring out why things havenâ€™t worked. Ideally, grad school is a training ground, where you are supposed to screw up. Maybe in a few years my opinions will change.
I’ll be the first to agree that debugging is an extremely important skill, since I find that most of the work we experimental scientists do is repeat experiments over and over again. Being able to understand why something isn’t behaving the same way yesterday as today is critical when the instruments we use are complicated, and living cells make an optical tweezers instrument look simple. But I’m going to have to disagree with Isaac for a moment, since debugging a problem is often not an easy task, and the “persistence length” for this process should depend almost entirely on the importance of the confusion. As Isaac mentioned, graduate school is a place where we’re “supposed” to screw up, but if screwing up is all I end up doing (and it is extremely easy to spend a lot of time trying to track down problems), I don’t think I’ll feel like I’ve accomplished anything, degree in hand or not.