In the light of last week's discussions, this repost seems appropriate. Original post and comments can be found here.
*******************
One of the many similarities between advising and parenting is that you think you will do everything so much better than others once it's your turn, only to find out that things are so much harder than you anticipated and many of other people's parenting choices that you so vehemently criticized start to completely make sense. The same with advising -- things look much different once you actually have to do it yourself.
What we do as advisors is certainly strongly influenced by the way we ourselves were advised. There may be differences, as we perhaps try to correct the things we didn't like when we were students or postdocs. Sometimes -- perhaps often? -- things that made us furious as trainees start to make sense once we are on the other side. (Sort of how you develop newfound appreciation for your own parents once you become a parent yourself.) And then there are undeniable differences in style we bring with respect to our advisors, simply because we are indeed different people or we may be at drastically different stages in our careers or at different types of institutions or we simply envision a different work-life balance for ourselves. Here are a few vignettes from my grad school life, which I think influenced how I advise students now.
1) I got a faculty position right after grad school, so my PhD advisor is the advisor who had the greatest influence on my career in every aspect. (In other fields, perhaps a postdoc advisor had a dominant influence.) My advisor was very well known and awe-inspiring. He also had a reputation for having a really bad temper and being extremely bellicose with colleagues, which hurt his recognition in the long run and did not help his advisees. He did not like being wrong or challenged in an environment where he perceived he would lose face; you could see his blood boiling and him becoming increasingly agitated and very unpleasant when it was becoming clear that he was losing an argument. I learned that the best way to go about is to drop the issue that we argued about and let him cool down, and then follow up with an email exchange. He was at the end of the day always in the pursuit of the truth and would always acknowledge when I was right in the end; the key was to finalize the exchange so that everyone has had the time to process it. I think this little bit of workaround around his temper was key in the two of us getting along very well for many years, and much better than he got along with many other students.But, it is also important that every single time the original idea or argument was always much improved after having talked/emailed with him -- just the process of hashing it out was extremely stimulating and useful.
-- What's the moral of this story? One is that advisors are people, with all that entails: they are not infallible or stoic; they get tired and pissed and defensive and everything else that other people get, so consider this aspect in your interactions. Second, when I have a disagreement with a student/postdoc, this experience taught me not to get defensive or aggressive (I am not 100% successful in this aspect, I admit) but to persevere in the discussion for everyone's benefit. Even when you as an advisor are wrong, you typically have a lot to bring to the discussion because you have much more experience in various aspects of the scientific process, so the idea is always much better and cleaner after the discussion than before it.
2) My advisor had a number of non-negotiable rules. For instance, I was trying for years to convince him to use Latex for text processing, and he would never budge. It was MS Word exclusively for all text, Power Point for all presentations, and one specific programming language and one image processing software for all programming and image processing needs. Nobody was allowed to use anything else for anything research-related. At the time, I honestly thought he was just a petty tyrant for insisting on such uniformity and failing to see the benefits of Latex; now I see the benefit of uniformity within the group to streamline everything from training new members, to software licence renewal, debugging and trouble shooting, sharing codes and other files. As soon as I was on my own, I went back to using Latex for most text processing; when he heard of it, my advisor told me somewhat sadly that I had switched over to the dark side. Now my group uses Latex for research papers and theses while we use MS Word for shorter texts and because virtually all our collaborators use only MS Word. We all use PPT for presentations and one programming language and one image processing software, as uniformly so as my old group did.
-- This story teaches us a couple of things too: (1) While you work in someone's group, it's going to be their way, whether you like it or not. Once you are on your own and lead your own group, you can do things any way you like. (2) Some rules are there for a good reason, which may not be obvious until you are in your advisor's shoes. Try to give them the benefit of the doubt that they actually may know what they are doing.
3) On the other hand, my advisor was very hands off in other aspects of mentoring students. For instance, we had weekly group meetings, but not during my entire time in grad school. He would rarely seek a student out and would generally expect you to come to him if you had problems; when you asked to see him, he'd accommodate you pretty promptly within a day or two, even though he was very busy. I was happy with this style and I think it works well for people who are independent. But I knew there were my group mates who really would just do nothing for weeks or would go off on unproductive tangents for way too long, and then once they got together with the advisor after a long time and presented what was, shall we say -- suboptimal output -- unbelievable wrath was unleashed upon them. Which only made them even less likely to seek meetings in the future and the vicious cycle continued. In my own group, we have weekly group meetings as well as weekly 1-on-1 meetings: my best students would likely be fine to be left alone, but for most students, especially when they are new, weekly 1-on-1 meetings keep them out of trouble/away from being stuck for long and the feedback offers them reassurance.
-- What's the moral of this story? Don't assume independence in all your students. Actually, assume that most will not be as driven or as independent as you may like them to be, at least initially, and ensure they have enough structure (or, if you will, hand holding or micromanaging) to maximize their own potential and make good progress in good time. This is critical especially in the initial stages of a research project. Brilliant students do well almost irrespective of the advisor. I think a successful advisor is one who can get a decent quality research output from a student who is not entirely independent or obviously brilliant from the start -- for many such students picking out a good topic and seeing them through their initial struggles can actually reveal a great hidden potential once they gain some confidence, and that's where structure and regular feedback is key.
4) When I was a grad student I was quite productive, wrote many papers and went to a lot of conferences. My advisor even threw a couple of his invited talks my way. I traveled more than his average student, to probably 5-6 conferences per year in my last few years. When I became faculty, I thought that's what I needed to do -- send my students to as many conferences as possible and have them present all the work.
But there was one significant difference between my advisor and me. When I was a graduate student, he was in his 60's, well known and well funded. He needed neither exposure nor funding, and could send me wherever and whenever. I, on the other hand, was a newbie faculty -- I neither had his funding resources, nor the name recognition or clout that he commanded. I had to balance sending students to conferences against ensuring that I myself got enough exposure, and doing it all on what were initially
relatively modest funds. I only realized this after several senior faculty colleagues kept insisting that I myself needed to travel and get exposure in order to get tenure, and that delegating everything to students at the beginning of my career would be devastating. So my students initially went to 2, occasionally 3 conferences per year. I also did not start delegating my invited talks (which were initially quite few and far between) to group members until I was near the end of my tenure track; invited talks mean a lot on the CV in my discipline, and count for a lot at tenure review time. Was this selfish? Perhaps. But had I not received tenure, I would not have ended up being of much use to anyone, including my students in their subsequent careers.
5) When I was a graduate student, I subbed for my advisor a lot. A LOT. One semester, I actually ended up teaching more classes than him (it's not like I was a TA or anything like that. He would just tell me that he'd be going out of town for 2 weeks and that I needed to cover these chapters from the book in class). I don't know why he did it -- initially it looked like he distributed the subbing load among students, but at some point it became only me. My guess is that he knew I wanted to be faculty and figured I could use some practice. I think I ended up subbing for him in about 5 different courses during my grad school. I actually enjoyed it but it was often a lot of time to prep.
-- What I do differently is that I ask my students if anyone wants to substitute. I think that for some of them it would be a good idea considering that they either want to teach or simply need practice talking in front of an audience, and I try to nudge them to do it and explain my reasons for thinking they should do it, but if nobody wants to (which is usually the case), I don't make them do it. I consider teaching classes to be my obligation; it is a situation in which the learning outcomes of the class, especially with undergrads, do depend strongly on the quality of teaching, and if I have to twist arms to get someone to cover, it's not going to be a fun experience for anyone. So then I ultimately reschedule.
If you are a professor/PI or a scientist out of academia, do you think your professional self resembles your advisor? What are the differences and similarities? If you are a student/postdoc, what are your advisor's characteristic that you might like to emulate in your career and which ones would you hate displaying yourself?
12 comments:
In short, as Mitt Romney would put it, "Advisors are people, my friend." (Sorry, too good to resist!)
Wait, your advisor didn't want the group using LaTeX for _anything_? And he is a theorist? There's a time and place to defer to the advisor on software, but if you find yourself doing substantial numbers of equations in Word, that is the time and place for rebellion.
Trust me, I kept pushing for Latex politely but persistently for years. My advisor would not budge, apparently he had used it in the past and just didn't like it... Yes, writing my dissertation with hundreds of equations in MS Word was an exercise in pain. But, out of necessity, I now know lots of little tricks and shortcuts that people usually don't and have used many more of its capabilities than I would have ever learned otherwise. So even though my group and I largely use Latex now, I am not allergic to MS Word, which comes in very handy in my many collaborations with experimentalists.
Here's my shortcut of LaTeX+Word if you e.g. have collaborators that don't know LaTeX, but also a lot of equations in the text and so you don't want to use equation editor in Word.
Write your equations (only) in LaTeX, produce a pdf, cut each one from pdf as an image and paste in Word document at the required location. That way you get the whole thing in Word for non-LaTeX savvy people, but still have the LaTeX look for equations (and simplicity of writing them).
I learned many things from both my graduate and post-doc mentors. Mostly from the former I learned how to grow up and be an adult. From the latter I learned--both in positive and negative ways--many more of the nuts and bolts of how to design and implement a research program and how to run a group. I also learned how to compare my own strengths and weaknesses with people I am working with so as to maximize collaborative effectiveness and enable my trainees to maximize their potential.
One of the most important things I learned was that highly creative people do not want to be told what tools they must use, and that if you do battle with trainees over this kind of minutiae you sap their motivation to create. So if you want to have a lab group where the trainees actually invent new technical approaches and novel ideas, you need to give them the freedom to choose their own tools. The real epiphany was to learn that my job is not to tell people what to do, but to create an environment in which people are excited to figure out on their own what to do.
For example, I don't even know what the fucken difference is between "Ruby" and "Python", but I do know that some people in my lab use Ruby for scripting analysis of massive biological datasets, while others use Python. They argue with each other over which is better, but they all are highly effective at moving their science forward.
As another example, some of the people in my lab use traditional restriction enzyme/DNA ligase methods for subcloning, while others prefer recombination-based methods. They all manage to obtain the clones that they need to achieve their experimental goals.
Yes, these things mean I probably spend more money than otherwise for reagents. But they also mean that people are exploring their creativity using the tools they most prefer, and my experience is that they are most productive that way.
If you want to run your lab like an Army platoon, I guess you can just demand absolute conformity. If you want to run your lab like a creative collective, however, you need to think about things differently. And the greatest value and freedom of the latter is when you finally realize that in many cases, your trainees know better than you what tools to use. For me to actually get down into the weeds with low-level tools and make some determination which are "better" and then demand absolute conformity is a poor use of my time, which is much more effectively spent on higher level strategic scientific planning.
CPP, do you also let your students pick, completely on their own, without your input, which massive biological datasets they analyze and what they clone? GMP and her students are the TOOL DEVELOPERS, not the tool users. She would be insane to let them work in whatever programming language or OS they want, as that would result in bunch of incompatible small tools, instead of a large extremely useful, beautiful tool. They can express their creativity by different coding techniques, approaches to the problem, but there has to be some uniformity for the sake of the long-term progress of her research program.
CPP, do you also let your students pick, completely on their own, without your input, which massive biological datasets they analyze and what they clone?
My students and post-docs have a tremendous amount of freedom to choose their own research directions. Obviously, this occurs within the broad outlines of my overal research program, and with advice, input, and mentoring from me.
This may sound scary, and can be very difficult for PIs to feel comfortable with, especially those with rigid personalities who are convinced that other people can't make decisions as well as they think they can. But once you relax your ego a bit, it becomes clear that creative young trainees are frequently *better* than you are at intuiting interesting new directions.
I have never commented on this blog before, but I notice that CPP seems to have an axe to grind with GMP's interest in using uniform programming languages/platforms. As GMP seems to have thought through this issue in great detail and have no interest in changing course for the foreseeable future, and you yourself (in the comment at 6:53 am) point out that determining which strategies are "better" is 'a poor use of your time' (presumably in other people's labs even more than in your own??), I would suggest that you give up this line of badgering.
Anons, CPP is just fucking with us. It doesn't take a genius to understand that when you develop large codes the pieces have to be able to mesh together; CPP understands that perfectly well, but he simply prefers to always fall back on "No matter what GMP writes, she's a tool, she's rigid, she's a bad mentor, she's all sorts of ridiculous, etc." and pull up whatever strawman argument suits him at the moment. Currently, the argument is how what I do stifles creativity, which I cannot see because the broomstick up my ass makes it hard to turn around and take a good look.
What I find funny is how "creativity" appears to be equated with having endless resources to play with that the PI pays for. What a deliciously first-world sentiment! That sounds like, in order to unleash creativity, you need to treat your trainees like pampered kindergartners -- all the toys you can play with, all the toys you can imagine, the PI will pick up the tab, you just go ahead and play, no worries! Granted, I don't understand the world of life sciences, where everything costs a ton and where you cannot be competitive without a lot of money. Maybe it's the fact that I do theory/computation and/or that I come from a country with very scarce scientific resources, but there is plenty of good science in my and related fields being done with very modest resources. My students have excellent computational resources and stable RA funding. So when someone tells me they don't want the resources available, but that they need exactly the setup they have at home and can only work on one OS that they love dearly, that does not indicate to me that I am cruelly stifling their breathtaking budding creativity; on the contrary, it sounds like that person is very inflexible and probably quite spoiled. And no, I am not worried that I will demotivate a true quirky genius this way; true quirky genii are rare and it would do them good, as well, to learn to utilize available resources.
My work is a mix of analytical theory and computational simulations. The simulations are usually developed to answer a specific theoretical question, and when we have answered that question we move on to another question and a new simulation. In that type of work, where pieces don't have to work together as often, I can let my students work in whatever language they want.
On the other hand, we also translate some of our work into plugins for ImageJ. For that, we have to use Java.
Also, while they can write in whatever language they want, I insist that they walk me through lots of internal details, which means that, in practice, it has to be something I'm at least somewhat familiar with. I know from painful experience what can happen if you don't thoroughly check the innards. Checking output is NOT enough, even if you check it very exhaustively. If you don't believe me, I can show you an erratum that I had to publish. Hence I now insist on checking innards. Not necessarily line-by-line, but I say "Tell me what this function does. Show me the output of that function for this case and that case. Tell me when it is called."
From what I have gathered from GMP's posts, her simulations are usually bigger than mine, more complicated. I gather that she makes use of a mix of legacy codes and in-house codes that took years to develop and validate. For projects of that scope, you can't let the n00b toss everything out and start anew. And you can't just say "OK, it ran fine this one time in this new environment, let's do that from now on." That statement carries a host of embedded assumptions about something of great complexity.
If I were in GMP's shoes, I'd probably let students try out other things for non-essential tasks, small calculations done on the side, or for "last step" data analysis (i.e. doing something with the output of the larger simulation), but I'd do like her and insist on uniformity for the larger simulations, and also insist on uniformity for any data analysis files that are shared among the members of the group. The ability to share among members of the group is absolutely crucial for spotting errors. It isn't just about doing things in a software package that GMP likes, it's about doing things in a software package that everybody in the group knows.
Since I don't have a blog any more and GMP's topics are always so fantastic and relevant, let me take this opportunity to describe my relationship with my advisor.
My extended research family is like competing mafia clans. Others refer to them as the high priests of mathematics with all the positive and negative impressions that bring. Fights of your fathers (just one or two mothers here) do become your fights. Blood will be spilled. But everyone keeps up appearances of collegiality.
Damn I hate my extended research family. Distant relatives would like nothing more than for me to drop out. Immediate family is supportive.
When I become an Ph.D advisor (only MS advisor so far) I will have to think through every step of the way.
To take down the level of seriousness a notch:
When I am looking at perplexing data from a simulation, I do exactly what my thesis advisor did in similar circumstances. I stretch out, put my arms above my head, and let out a deep breath in an exaggerated manner.
I should do this when one of my grad school classmates is visiting, to see if they pick up on it.
Post a Comment