Matt Suntay’s jump into the PINC computing program

Matt Suntay is one of the students in the PINC program and also a research student in my lab in the E. coli / drug resistance / machine learning team. A few days ago he gave a speech at our PINC/GOLD/gSTAR graduation event. I thought it was a great speech and Matt was kind enough to let me share it here both as a video and the text for those of you who prefer reading.

“To those of you who may know me, you all know I’m pretty adventurous. For those of you who may not know me, first off, my name is Matthew Suntay, and I have jumped off planes, cliffs, and bridges – and each time was just as exhilarating as the last. But, let me tell you about my most favorite jump: the leap of faith I took for the PINC program.

I call it a leap of faith because when I first heard about the PINC program, and specifically CSC 306, I thought, “Ain’t no way this could be for me. I may be stupid because I can barely understand the English in o-chem and now I gotta understand the English in Python? Maaaan, English isn’t even my first language… But they said I don’t need any prior computer science knowledge, so why not? It’s Spring ‘21, new year, new me, right?”

And let me tell you, it definitely made me a new me. I went from printing “Hello World!” to finding genes in Salmonella to constructing machine-learning models to study Alzheimer’s Disease and antibiotic resistance in E. coli. These are some pretty big jumps–my favorite, right?–and they weren’t easy to make. However, I was never scared to make any one of those jumps because of the PINC program.

When I think PINC, I don’t only see lines of code across my screen or cameras turned off on Zoom. I see friends, colleagues, mentors, and teachers. I see a community.

I see a community willing to support me in my efforts to develop myself as a scientist. I see a community providing me the platform and opportunities to grow as a researcher. And most importantly, I see a community that shared hardships, tears, laughter, and success with me.

I can confidently say that the PINC program was, and still is, monumental to my journey through science. Thanks to the PINC program, many doors have been opened to me and one of those doors I’m always happy to walk through each time is the one in Hensill Hall, Room 406 – or the CoDE lab. It was here in this lab that I met some of the most amazing people who want to do nothing but help me reach new heights. I’m so grateful and lucky to have them. So thank you, Dr. Pennings, for believing in me and continuing to believe in me. Thank you to everyone in the CoDE lab for supporting me and laughing at my terrible jokes – and real talk, please keep doing so, I don’t know how to handle the embarrassment that comes after a bad joke.

If I haven’t said it enough already, thank you so much to the PINC program. If you were to ask the me from a year ago what his plans were for the future, he would tell you, “Slow down, dude, I don’t even know I’m trying to eat for breakfast tomorrow.” But now if you were to ask me what my plans for the future are, I’d still tell you I don’t know what I’m trying to eat for breakfast tomorrow because I’m too busy writing code to solve my most current research question, whatever it may be.

For many students, including myself, one of the biggest causes of an existential crisis is, “What am I gonna do after I graduate?” To be honest, I’m still thinking that same thought, but without the dread of an existential crisis. One of the coolest parts of the PINC program is the exposure to research and the biotechnology industry, and learning that research == me and not just != the stereotype of a scientist.

Dr. Yoon, thank you for taking the time and effort to push me and my teammates forward, because even though our projects were difficult, we learned a lot about machine-learning and ourselves, like who knew we had it in us this whole time? You definitely did and you helped us see that. Professor Kulkarni, you also helped us realize that we should give ourselves more credit. 601 and 602 showed us we can be competitive and that we’re worth so much more than we make ourselves out to be. Also, I would like to give a quick shoutout to Chris Davies and Chun-Wan Yan for the wonderful seminars because those talks gave me hope and inspiration for the future. Knowing that there’s something out there for me makes going into the future a lot less scary and a lot more exciting because who knows what awesome opportunity is waiting for me?

And one last honorable mention I would like to make is to Professor Milo Johnson. He was my CSC 306 professor, and I don’t know if he is here today, but he was an amazing teacher in more ways than one. He helped me turn my ideas into possibilities and I have him to thank for helping kick start my journey through PINC. When I thought “I couldn’t do it, this isn’t for me,” he said “Don’t worry, you got this.”

So, once again, to wrap things up, thank you to everyone who’s helped me out this far and continues to help me out. Thank you to all my friends, mentors, and teachers that I’ve met along the way. And thank you to the PINC program, the best jump I’ve ever made.

Matthew Suntay – PINC graduate 2022

SCIP 2021 helped 130 bio/chem students improve their coding skills.

This past June and July, 130 participants improved their coding skills in the 2021 SCIP program at SF State University! I am so excited about this program and very grateful for the amazing team of people who ran SCIP 2021 (Rochelle Reyes, Ryan Fergusson, Olivia Pham).

I would like to share with you all how it went. The 130 participants were mostly biology and biochemistry students, but we also had some alums and staff who joined. Just over half of the participants were undergrads, and most had little or no coding experience.

Our participants were ethnically diverse and 63% identified as female, non-binary or gender non-conforming.

How was SCIP 2021 organized?

The participants were organized in teams of 5-7 people. This summer, we had 10 R teams, 11 Python teams and 2 ImageJ teams. For each team, we pick one member to be the team leader. Team leaders are chosen based on their leadership experience, not their coding experience.

MaryGracy Antony, an incoming SFSU Biology Master’s student was one of the team leaders – she had no coding experience at the beginning of the summer. Here is an image from one her zoom meetings. I asked MaryGracy how it went for her and she said: “I let my team know on the first day that I, like them, have no experience with Python and we will be helping each other out throughout our time in SCIP. It definitely worked. […] As the weeks went by, people who were further in the course were helping others and even me. It was a very fulfilling experience 🙂“

Each team met 4 times a week for 2 hours during 6 weeks (48 hours total). All meetings had a similar structure with time to talk and time to work quietly. The “I” in SCIP stands for immersion, which means that the learning is done during the zoom meetings. We discourage working on the materials outside of the zoom meetings, to avoid getting stuck on a coding problem with no help nearby. If the teams got stuck, they could ask questions on the Slack forum, which was monitored by the SCIP admin team.

Once a week we held a webinar for one hour, with speakers who use coding in biology, chemistry or biochemistry. This year, we hosted a teacher, a PhD student, someone who worked in the biotech industry and many others. Many of our guests were SFSU and PINC alums.

Outcomes

One of the main goals for SCIP is to allow participants to learn coding skills in a non-threatening, ungraded environment. We think we are succeeding in this for most participants, but to make sure our environment is as non-threatening as possible, we don’t test their coding knowledge and we don’t keep track of attendance. Still, there are several indicators that show that participants are learning and finding a community in SCIP. First, 97% participants would recommend SCIP to others. Second, self-reported coding confidence goes up a lot. Third, almost 90% of participants expect that coding will be part of their future career – that is huge, given that most of our participants had no prior coding experience.

New materials received very well

Participants in SCIP all learn from freely available online coding classes that we pick out for them. While these coding classes from Udacity and EdX work quite well, there are also some issues with these classes. They are not made for science students and they are mostly taught by white men. The SCIP team therefore created new materials this year.

These new materials included a series of videos about R made by Ryan Fergusson and coding projects designed by all of the SCIP admin team members (see here https://vimeo.com/showcase/8775548). More than 90% of the participants scored the new videos as a 4 or 5 (on a scale from 1 to 5) in terms of how helpful they were.  

The story behind SCIP

Last summer, in 2020, many of our bio/chem students were stuck at home, without a job or summer research experience. In the meantime, Dr Megumi Fuse, was looking for something that our research students could do during the summer, while they were funded to do research but the labs were closed. We designed a community-focused online coding program to make the most of the summer of 2020. It worked great! 160 people joined in 2020, and most of them loved it and learned new coding skills! To learn more about SCIP have a look at our website.

The people behind SCIP 2021

The most important people behind SCIP 2021 were Rochelle-Jan Reyes, Olivia Pham and Ryan Fergusson. Rochelle did most of the admin work, Olivia ran the webinar series and Ryan created videos for learning the R programming language. All three of them answered many technical questions on the Slack channel.

Funding

Funding for SCIP 2021 came from the NSF-funded Center for Cellular Construction (NSF grant DBI-1548297) and the NIH MBRS-RISE grant (#R25-GM059298). Some of the SCIP participants, especially those who had learned ImageJ spent the second half of their summer in the CCC research workshop. Many SCIP participants are now in the PINC or GOLD programs (link).

How we run an inclusive & online coding program for biology and chem undergrads in 2020

By: Nicole Adelstein, Pleuni Pennings, Rori Rohlfs

In 2018 this team (led by Chinomnso Okorie) met in the “yellow room” for 8 hours a week to learn R.  

We have been running combined coding/research summer programs for several years, with a  focus on undergraduate students, women, and students from historically underrepresented racial and ethnic groups. This summer, we will run our 9-week program as an online program. We think that others may be interested in doing this too, so we’ll share here how we plan to  do it. 

Some of the information below will also be published as a “ten rules paper” in Plos Computational Biology*, but we wanted to share this sooner and focus on doing things online vs in person. 

TL; DR version

1. Have students work in teams of 4 or 5, for 2 hours per day, 4 days a week. Learning to code should be done part-time, even if your program is full time. 
2. Use near-peer mentors to facilitate the team meetings (not to teach, but to facilitate). 
3. Use existing online courses – we’ll share a few that we like. Don’t try to make your own curriculum last minute. There are good online courses available. 
4. Give the students a simple (repeat: simple!) research project to work on together. 

1. Have students work in teams for two hours a day – with pre-set times. 

Learning to code is stressful and tiring. Even though many students may not have jobs this summer – it doesn’t mean that they can code for 8 hours a day. First, because they have other stuff to do (like taking care of family members) and second because there’s a limit to how long you can be an effective learner. 

Our program is 10 hours per week (8 hours of coding, 2 hours of “all-hands” meeting). We make it clear that no work is expected outside of these hours. For example, a team may meet from 10am to 12pm four days a week for coding. 

Check-ins, quiet working, shared problem solving. 

During the coding hours, the near-peer mentor is always present (on Zoom, of course!) and facilitates the meeting. The very first day should be all about introductions and expectations. After that, we suggest that every day, there is time for check-ins (everybody shares how they are doing, what they’re excited about or struggling with, or what music they’re listening to), quiet working (mute all microphones, set a timer, everybody works on the online class by themselves) and shared problem solving (for example, let’s talk about the assignment X from the online class). One of the mentors last year was successful with starting every meeting with a guided meditation. 

Each team has a faculty mentor in our program (this could be a postdoc or faculty member). Once a week, the faculty mentor joins the meeting for about 1 hour. This hour could consist of introductions / check-ins, a short presentation or story by the faculty mentor, and the opportunity for the team to ask questions. It’s great if the near-peer mentor and the team prepare questions beforehand. 

1B. Add a non-coding meeting (if you can/want)

In addition to the 8 coding hours per week, our students also meet for 2 hours per week in an “all hands meeting”. Such an all-hands meeting is not absolutely necessary, but if you have the bandwidth, it may be nice to meet once a week to do something other than coding. Maybe to read a paper together or meet with someone online (an alum who is now somewhere else? A faculty member or grad student?). 

If your program is full time (like an REU program), we suggest to still only do about 8-15 hours of coding per week. Fill up the rest with more standard things such as lectures, reading etc (and don’t make anyone do Zoom 40 hours a week!). If students are enjoying themselves with coding and getting more confident, they may do more coding by themselves, but in our program it is not the expectation. 

2. Mentors and teams are key 

When working alone, we’ve often seen students get stuck on technical problems, leaving many feeling lost and inadequate and wanting to discontinue learning this new skill. Working in a mentored team, however, students have access to immediate support from their peers and mentor. This helps them learn technical skills more efficiently, develop relationships with each other, and cultivate a shared sense of belonging in computational research (Kephart et al. 2008). We recommend that each participant in a coding summer program be assigned to a team of 4 to 5 students with similar technical skill levels led by a near-peer mentor. 

Mentors in our program are typically a year or two ahead of participants but belong to similar demographic groups and come from similar academic backgrounds. The mentor facilitates the meetings and leads the team in learning skills and applying them to a research question (without doing the work themselves). 

Each team also has a faculty advisor, who comes up with a research project that is likely to be completed in the available time and that is of interest to the students (Harackiewicz et al. 2008). The faculty advisor meets with the whole team at least once per week to guide learning and research. Of note, acting as a mentor improves students’ retention and success in STEM (Trujillo et al. 2015) therefore, this setup benefits mentors as well as mentees. 

2B. Who can be mentors? 

Over the years, we have found that near-peer mentors are incredibly useful for a number of reasons including 1) student participants are more likely to ask for help from a near-peer mentor than from a faculty advisor, 2) near-peer mentors serve as role models, giving participants an idea of what they can aim for in the next year or two, and 3) the use of mentors allows the program to serve many more participants than it could if it relied on a few time-pressed faculty advisors. Our selection criteria for mentors include essential knowledge (for example, the mentor for a team doing an advanced chemistry research project should have taken physical chemistry), mentoring experience or potential, logistical availability, and having a similar demographic background as the participants. Mentors don’t need experience with the specific coding language or research topic they will work on with their team. Rather than being the expert in the room, they are expected to help team members work together to find solutions or formulate questions for the faculty advisor. 

Mentors are crucial for the success of the program and need to be paid well for their work. Each week of the program, we pay our mentors a competitive wage for 8 contact hours with their team, a 2-hour all hands lunch meeting, a 2-hour mentor meeting, and 3-4 additional hours to account for preparation. However, we realize that this summer, things may be different for many! You may find that PhD students or Master’s students who can not work in the lab (but are still paid / on a fellowship) could be excellent near-peer mentors. Just make sure that the mentors know that this is a real commitment that will eat up a significant chunk of time each week. 

3. Identify an appropriate online course for each team

We have found that when learning basic coding skills, interactive online classes to learn computer programming (for example, from Datacamp, Udacity or Coursera) motivate and engage students better than books or online texts. Yet, when working individually, most students – especially beginners and historically underrepresented students – don’t finish online classes (Ihsen et al. 2013; Jordan 2015). As a solution, we have found that in teams, where students can work together and support each other, they learn a great deal from an online class. 

Each team’s faculty advisor picks a free, clearly structured online class with videos and assignments to teach participants coding skills. We have had good experiences with Udacity’s Exploratory Data Analysis course because this class is suitable for beginners. It does a good job motivating students to think about data and learn R. In early team meetings, participants spend time quietly working on the online class with their headphones on, followed by a team discussion or collaborative problem-solving session. If students encounter difficulty with any of the material, mentors may develop mini-lectures or create their own exercises to facilitate learning. Note, the students’ goal is not necessarily to finish the online course, but to learn enough to perform their research project. 

3B. Suggested classes:

Udacity Exploratory Data Analysis with R https://www.udacity.com/course/data-analysis-with-r–ud651

CodeHS https://codehs.com/ (the faculty mentor or the near-peer-mentor needs to create a section on Code HS, we use the introduction to python (rainforest).  

Coursera https://www.coursera.org/learn/r-programming (this one is a tip from our UCSF colleague Dr Kala Mehta)

4. Assign each team a simple and engaging research project 

Learning to code without a specific application in mind can feel boring and irrelevant, sometimes leading students to abandon the effort. In our summer program, teams carry out a research project to motivate them to learn coding skills, improve their sense of belonging in science (Jones, Barlow, and Villarejo 2010) and cultivate their team work and time/project management skills. Faculty advisors assign each team a research project early in the program. These projects should answer real questions so that participants feel their work is valuable (Woodin, Carter, and Fletcher 2017). The projects should also be relatively simple. Small and self contained projects that can be completed within a three week time frame are ideal to ensure completion and make participants feel that their efforts have been successful. For example, past research projects in our program, which reflect the interests of faculty advisors and the students, include writing computer simulations to model the evolution of gene expression, analyzing bee observations from a large citizen science project, examining trends in google search term data with respect to teen birth outcomes, and building an app for finding parking spots on or near campus. 

For 2020, we’d like to encourage you to pick a project that appears extremely simple if you normally use R or Python to make your plots / do stats, but that would be quite challenging if you’re new to coding. We also suggest that – unless the students are already quite advanced – you don’t give them a project that you want to publish on quickly. Nobody needs more pressure this summer.  

Here are some suggestions for simple research projects

1. Let students plot the number of COVID19 cases in their county over time using R. Let them plot the number of cases in 5 different counties on the same figure. Add an arrow for when a stay-at-home order was implemented or terminated. Easy to download data are here: https://github.com/nytimes/covid-19-data 
2. Let students keep track of how many steps they take each day for 10 days using their phone or watch. Let them plot the number of steps per day using R. Let them add a line for the mean. Collect data from 6 people and create a pdf with 6 plots in different colors. 
3. If you have any data from your lab, let the students plot those data. Try making 4 different plots with the same data (scatter, box, histogram, etc). 
4. Let students recreate an existing plot from a publication when the data are available. 
5. Let students analyze (anonymized) data from your class. How strong is the correlation between midterm grades and final exam grades? Do students who hand in homework regularly do better on the test? 

* reference: Pleuni Pennings, Mayra M. Banuelos, Francisca L. Catalan, Victoria R. Caudill, Bozhidar Chakalov, Selena Hernandez, Jeanice Jones, Chinomnso Okorie, Sepideh Modrek, Rori Rohlfs, Nicole Adelstein Ten simple rules for an inclusive summer coding program for non-CS undergraduates, accepted for publication in Plos Computational Biology.

Meet Francisca Catalan, SFSU PINC alum and research associate at UCSF (spotlight)

Francisca Catalan, SFSU PINC alum and research associate at UCSF

1. How did you get into coding? 

I took a regular CS class my second year at SF state. I thought it would be a good skill to have as an aspiring researcher and saw that it fulfilled one of my major requirements. It was a PowerPoint-heavy 8 am class three times a week. I didn’t talk to anyone else in the class and by the end of the semester I found it very difficult to show up. I passed the class but was really devastated about my experience. I thought I could never learn to program, though I never gave up completely. A couple semesters went by and I saw a friendly flier announcing PINC, SFSU’s program that promotes inclusivity in computing for biologist and other non-computer science majors. I eagerly signed up and started the “Intro to Python” class soon after. Then, with some more programming under my belt, I joined Dr. Rohlfs’ lab and began doing research in the dry lab for the remainder of my undergraduate career.

2. What kind of work do you do now? 

I currently work at UCSF as a dry lab research associate. Our lab focuses on an aggressive form of brain cancer, glioblastoma. We try to find gene targets for new drug treatments and research the cell type of these cancerous cells in order to fight drug resistance. My main duties now include creating pipelines for our single cell, RNA-Seq, and Whole Genome Sequencing data. You can read about our lab’s latest study in our new publication on cancer discovery! DOI: 10.1158/2159-8290.

https://cancerdiscovery.aacrjournals.org/content/candisc/early/2019/09/25/2159-8290.CD-19-0329.full.pdf

3. How did learning coding skills impact your career?

Coding has opened so many pathways for me. I was able to find a great job at UCSF soon after graduating with my Bachelor’s of Science in cell and molecular biology and minor in Computing Applications. It has also given be a giant boost of confidence! As a woman of color in STEM, I often felt underrepresented and out of place, but those feelings now quickly subside when I can help my colleagues answer coding questions! It’s motivating to feel like a necessary component of your community when often time you feel pushed out. It’s also impacted my career choices! I know now I want to be a professor in the future, I want to provide access to programming to others in hopes it will open pathways like it did for me!

4. Do you have any advice for students who are just starting? 

Yes! Don’t give up! It can be really difficult to learn coding, but know that it’s not you, talking to a computer can just be hard sometimes! Continue practicing and ask questions, google your heart out. Take breaks when necessary, remember to breathe, and keep in mind all the amazing science you will be able to do once you have these skills under your belt!

The ridiculous order of the streets in the Excelsior (SF)

I live in the Excelsior neighborhood in San Francisco. My street is Athens Street. If I walk westwards from my home, I come to Vienna Street and then Naples, Edinburgh and Madrid. If you have any knowledge of map of Europe, you realize that the order makes no sense!

(Also, why is there Naples, but not Rome, and why Munich, but not Berlin? And why oh why, is there no Amsterdam Street? So many questions!)

Last week, I asked the students in the CoDE lab to create a map to show the ridiculous order of the streets in the Excelsior. They had fun figuring out how to make a map in R, so I thought I share their work here. Several students were involved, but my graduate student Olivia Pham did most of the work.

The code is here: http://rpubs.com/pleunipennings/212840

The surprising order of street names in the Excelsior neighborhood in San Francisco. We connected the cities in the order of the streets. London Street is the first city-name street if you enter the neighborhood from Mission Street, just east of London Street is Paris Street, then Lisbon Street etc. The last city-name street is Dublin Street which is closest to McLaren Park.

A map of part of the Excelsior neighborhood showing the order of the city-name streets.

How to get started with R

I often get asked how to get started with learning R if there is not currently a class offered. Here is what I recommend:

1. Start with a free online Code School tutorial

First of all, check out this (free) online course: https://www.codeschool.com/courses/try-r
No need to install anything, no need to pay. Students in my bioinformatics class liked this online Code School course a lot. It will not make you a master of R, but it’s a nice starting point.

2. Install R, Rstudio and swirl on your computer

Next, it is time to install R and Rstudio on your computer. Once you have that, install the swirl package. Instructions for installing R, Rstudio and swirl can be found here: http://swirlstats.com/students.html
swirl is an R package that helps you learn R while you are in the Rstudio environment. I highly recommend using the Rstudio environment! The swirl tutorials teach you the basics of vectors, matrices, logical expressions, base graphics, apply functions and many other topics. Kind words included (“Almost! Try again. Or, type info() for more options.”)

3. Dive in with great Udacity class …

If you are ready to really dive in (and have some time to invest), try out this great Udacity class: https://www.udacity.com/course/data-analysis-with-r–ud651 (no need to pay for it, you can do the free version). This class is taught by people from the Facebook data science team. They do a great job guiding you through a lot of R coding. Importantly, they always take the time to explain why you’d want to do something before they let you do it. A large part of the course is focused on using the ggplot2 package.

… or start reading The R Book

The R Book is a book by biologist and R hero Michael Crawley. The pdf of the book is available from many websites (for example: ftp://ftp.tuebingen.mpg.de/pub/kyb/bresciani/Crawley%20-%20The%20R%20Book.pdf). Make sure you also download the example data that come with the book (http://www.bio.ic.ac.uk/research/mjcraw/therbook/).

The R Book is a great resource and very clearly written. The students in my lab enjoy reading from it and trying out the code. If you are a biologist, it’ll be fun to work with the biology examples in the R book.

4. Find others who are using R or learning R.

Learning R is hard. You will get frustrated sometimes. If you know someone who is learning with you or who could help you when you are stuck, things will be easier! If there is no one near you, try to find R minded people on Twitter or elsewhere online. Also, check out the R forum on Stack Overflow (http://stackoverflow.com/questions/tagged/r) for many questions and answers on R.

Good luck!

 

Reading in the lab

The winter break is a great opportunity to spend time in the lab with my students. One of the things we do, is read papers. Last week, we spent a morning reading the following paper:

Triple-Antiretroviral Prophylaxis to Prevent Mother-To-Child HIV Transmission through Breastfeeding—The Kisumu Breastfeeding Study, Kenya: A Clinical Trial. PLoS Medicine, 2011. Thomas , Masaba, Borkowf, et al. 

The paper shows that antiretroviral drugs taken by an HIV-infected mother help prevent transmission to the baby through breastfeeding. The reported rates of HIV infection of the infants during breastfeeding were less than half the previously reported rates from untreated women.

After everyone read the paper, and we all discussed it together, two students worked together to write an abstract and three students worked together to draw an abstract. Here are the results:

Abstract (by Kadie and Melissa)

The Kisumu Breastfeeding Study was a single-arm trial conducted with 522 HIV–infected pregnant women who took a triple antiretroviral regimen from 34 weeks of pregnancy to 6 months after delivery. The triple-ARV regimen consisted of zidovudine and lamivudine and either nevirapine or the protease inhibitor nelfinavir. The purpose of the study was to investigate how various ARV regimens given to mother and/or their infants affect mother to child transmission of HIV.

Data collected showed that between 0 and 24 months, the cumulative HIV transmission rate rose from 2.5% to 7.0%. The cumulative HIV transmission or death rate was 15.7%. Three percent of babies born to mothers with a low viral load were HIV-positive compared to 8.7% of babies born to mothers with a high viral load. Similarly, 8.4% of babies born to mothers with low baseline CD4 cell counts were HIV positive compared to 4.1% of babies born to mothers with high baseline CD4 cell counts. Although these findings are limited by the single-arm design, this study supports the idea that a simple triple-ARV regimen given to HIV-positive pregnant women regardless of their baseline CD4 cell count can reduce MTCT during pregnancy and breastfeeding in a resource-limited setting.

Graphical abstract (by Olivia, Patricia and Dasha)

 

End of summer poster session

Today was the last day that the summer students were in the lab (although some of them will be back next week when the semester starts). I asked each of them to make a poster with a figure they made this summer. They are learning to program in R, and making figures is a big part of what they’ve worked on. I took snap shots of some of the students with their posters. They did a great job!

 Pedro Zorzanelli da Vitoria from Brasil

 Brendan Kusuma (SFSU, undergrad)

 Julia Pyko (SFSU post bac) and Patricia Kabeja (SFSU undergrad)

 

 Dasha Fedorova (SFSU undergrad) made her poster together with Sidra Tufon (not in the picture).

 

Dwayne Evans (SFSU Master’s student)

 

A reading seminar where every student reads, writes and contributes to the discussion in class

I remember reading seminars as follows: one student spends the entire week preparing for a powerpoint presentation, which often turns out to be stressful for the student and somewhat boring and uninformative for the audience. The other students only glanced over the paper and so any discussion quickly falls flat. I therefore decided to have multiple short presentations without powerpoint (less preparation, more fun to listen to, plus repetition is good for learning a skill). I also decided to use short writing assignments as homework to make sure that all students were prepared to contribute to the discussion in class. At the same time, I wanted to keep things manageable for everyone.

1. Learning to present: every student does multiple short presentations without powerpoint.

No powerpoint: I didn’t want students to spend too much time preparing a presentation. I believe that often, when students spend a lot of time preparing presentations, they focus too much on making powerpoint slides and not enough on informing the audience and telling a story.

Short presentations: Doing an engaging 45 minute presentation is extremely difficult, and a skill that most postdoc don’t have, so why do we use 45 minute presentations in our graduate seminars? I decided in stead to let each student do three 10 minute presentations.

Feedback: After each presentation the presenters got feedback (from the other students and myself), so that they could improve their presentation skills during the semester.

Easy listening: An added benefit of 10 minute presentations is that it is much easier for the audience. Each week started with three student presentations, one on the background and main question of the paper, one on the data and the results of the paper, and one on the conclusion and implications of the paper.

2. Practice writing: every student does a different writing assignment every week.

Graded homework each week: A paper discussion can only work if people have read the paper. If students don’t read, they may spend most of their energy to try to hide that they didn’t read (I know I was in that situation!). So even though I understand that life and research get in the way of reading, I really wanted to make sure that the students were prepared for the seminar. To do that, I made every student do a written assignment every week that would count towards their grade (unless they were presenting that week).

A different assignment for each student: I had a long list of assignments so that each week, many different assignments were done AND so that over the course of the semester each student did many different assignments. This guaranteed that the students read the paper, but each with a different question in mind.

There were several types of written assignments. Descriptive: 1. Describe the background and main question of the paper, 2. describe the data and the results, 3. describe the conclusions, 4. describe which virus the paper is about. Critical: 5. What is your opinion of the paper? 6. What do you think the authors should have done differently? 7. Play the devil’s advocate: why should the paper not have been published? Summaries: 8. Summarize the paper in your own words, as if writing to a friend, 9. summarize the paper using only the most common 1000 words of the English language, 10. summarize the paper in a graphical abstract, 11. summarize the paper in a tweet. Meta: 12. Who are the authors of the paper? 13. How often is the paper cited, do you think it is influential?

Short! Each written assignment could not be more than 150 words, to keep the workload manageable for me and for the students.

Surprisingly hard: Some of the assignments were harder than the others. Summarizing the paper using only the 1000 most common words from the English language turned out to be very hard, but some of the students did a great job (see here and here). The graphical abstract was also hard for some students, but others liked it just because it was so different from their usual work (see here and here). The ”devil’s advocate” writing assignment was always very interesting to read.

Easy: Grading the written assignments was quite easy. I simply gave a plus or minus for 5 categories (answered the question, scientific accuracy, clarity, grammar and word count).

Revisions allowed: After a request from a student, I decided that the students could redo any assignment where they had gotten less than 100% because I believe that feedback is most useful when it can be applied to a revision.

3. Promoting equity: thanks to the written assignments, every student could contribute to every class.

Everyone contributes: One of the nice things about the homework schedule with different assignments for everyone is that in class, I could ask each student about their homework. This way, each student contributed to the class, promoting equity, and the brief discussions of the homework assignments always let to questions from other students. Even if I didn’t ask, some students would volunteer to share information they found while they researched for their homework. For example, I remember someone remarking at the end of a presentation: “In your presentation, you said this result may be very important, but I found that the paper hardly has any citations even though it was published ten years ago, so I think it may not have been picked up by anyone.”

Sharing homework: I also encouraged the students to share their written assignments on the online forum we had for the class, so that the other students (and not just me) could read them. Sometimes they led to interesting forum threads. I also published some of the written assignments on my blog, after asking the students for permission. This way even more people could enjoy them.

Heb B study graphical abstract using paper and pens

One of the most fun things about teaching a grad seminar last semester was reading the homework assignments. Seriously!

Before I move on to the next semester (teaching genetics for undergrads), I wanted to share one more homework assignment. This one by Emily Chang, a graduate student in Scott Roy’s lab. The paper about viral quasispecies in Hep B was one of the harder ones for the students, but this graphical abstract very neatly sums up the main results. I also love that Emily used old fashioned paper and pens to make the abstract, knowing that using fancy drawing software isn’t needed to communicate science.

Graphical abstract by Emily Chang