Ten Steps To Accelerate Your Bioinformatics Lab With Undergraduate Trainees.

Ten Steps To Accelerate Your Bioinformatics Lab With Undergraduate Trainees.

April 3, 2013

Christopher W. V. Hogue - National University of Singapore

What do: 

-the founder of Netfunctional Inc,

-the CEO of Nascent Digital, 

-the VP of Software Engineering at G Adventures Inc., and

-this Harvard/MIT faculty member

        all have in common? 

They started out as undergrad student trainees writing code in my bioinformatics lab over a decade ago. I have seen many more successes too.

While I take no credit for their current achievements, I thought it would be useful to share how my Toronto bioinformatics research lab flourished and grew by taking on and developing keen undergrad students over summer break or through co-op work term programs.

Well before Google Summer of Code appeared, my Toronto lab, (aka The Blueprint Initiative) fostered in-house intensive summer training for undergraduates.  This process started in 1999 and was fine-tuned over a few years with the help of Greg Wilson, who audited my software group for best practices, and who now runs software boot camps for scientists around the world. Here's what worked.

1. Motivate your Mentors.

Have a conversation with your grad students, software developers or postdocs, at an early stage about mentoring undergrad trainees. The benefits are clear. Group project work in software is the rule rather than the exception, outside grad school. Grad students learn a lot more in pair programming setups. Problem solving clarity is often a matter of explaining the problem to someone else. Some tedious non-research elements of a project can be accelerated when the grad student gets help from an undergrad.

Mentoring is, in my lab, an essential part of grad student development. Emphasize the importance of giving credit to the undergrad trainee in papers and in their thesis writeup. Recruit your mentoring staff to be your boot camp trainers and to develop and modify presentation material and for their trainees. 

2. Plan Ahead - Internal Call for Projects. 

Around March, gather the mentoring team around the whiteboard and ask for their wish list. Ask for the list of things they are avoiding, procrastinating over, or putting on the back burner. Spark conversations about deploying new technologies. 

Ask about improving workflow, build processes, user-experience, testing, things that grad students like to avoid because it isn't "research". Better visualization tools. Write it all down- and don't be too critical about the ideas. A long list gives you more to choose from, and projects to carry over to next year.

3. Divide Projects into Short-Win and Big-Impact.

Highlight the ideas that serve multiple goals, and help more than one lab project. These are the ones where the incoming trainee can call on more than one mentor for help.

Break the ideas down into sub-projects. Is there a parser component? Is there existing code that can be ported or refactored to do the task? Is there something new to install and configure? Is there a better way to display results?

Drive down the scope of the smaller projects until you get to a magic 3-week Short-Win effort. You will need one of these for each incoming trainee. 

4. Recruit, Advertise and Interview.

Use your professional network. Call up nearby co-op program organizers at other colleges or universities. Chat up the high achievers in your own classes. Pop in to the CS Undergrad classes and write your recruiting website on the white board. Organize a lab tour for your undergrad students, or host one for a neighboring college class. Encourage your lab members to be on the lookout for talent. Pay attention to the quiet introvert who is brave enough to send you an email or ask a question at the end of class or in lab. Talk to the down-on-their luck, overly pierced and tattooed brother or sister of your grad student and bet on talent having a genetic component. 

Don't always expect to find experience, after all you are providing that opportunity. Ask questions that require active responses, (not yes-or-no) and look for logical and critical thinking skills. Ask why. Ask them to feed back what you just explained about the project in their own words. Look for good listeners, process accumulation skills, and analytical thinking. And don't forget to look for artistic ability in students who will work on visualization - purple and orange and brown do not go together! 

5. No Unpaid Interns.

While it is tempting to have an eager pool of applicants vying for an opportunity to work in your lab solely for the experience, please do not take unpaid interns. If you can't pay them to work on a project, you need to find funding. Google Summer of Code provides stipends. Students can provide amazing work when motivated, and you don't want them worried about rent, bus fare and meals. 

It is simply too distracting for them and your project needs mental focus. Get them on payroll asap. If your institution is painfully slow in paying them, let the trainee know up front and dig deep and extend a bridging loan. I've done this for at least 7 students over the years, without problem. 

6. Boot Camp Training.

We ran  boot camp sessions tailored for all the trainees so they understood the engineering side of our software environment. Some of that material is here. Explain how your builds work, how is the source tree organized, how to make a simple hello world app, how to connect to your databases. Effort spent on organizing and presenting this material can be reused and updated in subsequent years. Software Carpentry is highly recommended if you do not have the resources or know-how to do this in house.

7. Assign the Short-Win Project First.

The Short-Win project sets up the trainee for their first month at your lab. Week 1 is spent on orientation, finding out where the washrooms are, getting accounts on the wiki, version control, bug-tracking and ticketing systems, digging into any training material needed, and boot camp if you choose to run one. Don't have version control/ticketing/bug-tracking? Make their deployment a trainee project.

I aim for a three week project after the orientation week. Pair trainee and mentor and listen carefully for any early personality or style conflicts. Advise your mentor as needed and make sure they understand that constructive support works way better than criticism, micromanagement and rewriting all their trainee's code. Mentors need to understand the important nuance of actually finishing the Short-Win, and assisting the trainees in rolling it out at the completion of the project. After all, a win is not something to be thrown on the back burner. Trainees need to witness the finishing and deployment steps. 

So, as the name Short-Win suggests, the trainee has an achievable project that they can feel good about delivering by the end of the first month. Getting all your trainees to a modest success at about the same time does wonders for their group morale, and the Short-Win deliverable is powerfully motivating. 

8. Assess, then Assign the Big-Impact Project.

If a trainee is struggling, cut down the project scope so it becomes achievable. In some cases bright students simply cannot code very well. Change up their project to something that involves curation, organization or installation/configuring. There are multiple kinds of intelligence and not everyone can play the piano.

After the Short-Win the trainee is ready to sink their teeth into a bigger challenge - the Big-Impact. Ideally the scope of the Big-Impact project should be limited so that a good novice can pull it off in 2 months - that is delivery by the end of their time in the lab. 

Explain each project's impact personally to the mentor and trainee together. Why is this important? What immediate hole does it fill? What will completion of this project allow us to do in the future? Make sure the mentor buys in to the importance of finishing the task themselves should the schedule run late.

Then, stand back and watch it happen.

9. Watch out for 6:39pm Mental Fatigue.

Oatmeal-raisin cookies were not just a treat I provided in my Toronto lab, they helped bridge fatigue. Staring at code on a monitor all day can block programmers stuck on a problem. Symptoms include random cursor movement, that deer-in-the-headlights stare and a steadfast refusal to step away from the code. Subconsciously the problem seems immediately solvable, but hours pass without breaking through to the answer.

When I walk around at the end of the day, I look for this blocked state. Yes, they put up a fuss about staying and finishing, but this isn't a death march project. It is training. 

I have on numerous occasions heard, after sending a trainee home - in spite of their reluctance - that it "came to them on the subway", or "I figured it out while eating dinner", or "at breakfast". Let the trainee understand that mental capacity is not limitless and needs to be replenished. Yes, sometimes even senior staff need to be reminded of this. Mental fatigue never seems to be self-evident, it is often a hard-learned lesson.

10. Celebrate, and Bring em Back Alive.

A first or second year undergrad, trained in your lab, is of immediate value in the next year. Stay in touch, and encourage them to come back. At the end of the summer, organize a lunchtime Posters and Pizza session so your trainees can show off what they have done. Have a chat with them about the next project idea for next summer. Show them the "big picture" at the grant or funding level. You may be delighted by the response. Pass on recommendations to your students for other positions they may be interested in, and write an honest reference letter when requested.