Last week, I wrote a post where I talked about how my training in evolutionary ecology led me to try reaction norms (that is, paired line plots) for plotting paired Likert data. I had already tried a few other options, but didn’t include them in that post, and I got some feedback on that post that gave me more ideas. There was also a request for code on how to actually generate those plots. So, this post shows four different ways of visualizing individual-level responses to paired Likert-scale questions (paired line plots, dot plots, mosaic plots, and heat maps). It does that for two different comparisons, leading me to the conclusion that the type of plot that works best will depend on your data. I’d love to hear which ones you think work best — there are polls where you can vote for your favorite! And, if you’re working on similar data and want to see code, there’s an associated Github repo, but it comes with the disclaimer that my code is good enough, but definitely not elegant.
In the past year, I’ve been working on several projects that used Likert-scale data (e.g., 1 = strongly disagree, 5 = strongly agree). And, in several instances, there were questions that it made sense to pair. As one example (which I blogged about in more detail earlier this month), for Morgan Rondinelli’s undergraduate thesis project on student mental health, we asked students whether they would think less of someone who sought mental health care and also whether they thought others would think less of someone who sought mental health care? In that case, I was curious not just about the aggregate percentages in the different categories, but also how individual views compared. So, being a good evolutionary ecologist raised on reaction norms (where genotypes are plotted in different environments, with the points for each environment connected by a line), I made a paired line plot:
This figure shows me that no students viewed themselves as more judgmental than the average: none of the lines go up. That’s not information that I could get from other ways of plotting the data (shown in my earlier post).
A different example comes from a project studying student views on climate change, which I’m working on with Susan Cheng and JW Hammond. We asked students the same questions at the beginning and end of the semester. To focus on one question, we asked students “Do you think climate change is happening” at the beginning of the semester and again at the end of the semester. The overall results were promising:
Note from Meghan: This is a guest post by Gergana Daskalova, a PhD student at the University of Edinburgh.
I recently attended the British Ecological Society Annual Meeting, one of the biggest scientific conferences in the calendar year of an ecologist. Over the course of just one day, I got asked where I am from 18 times. I counted because in just four years of attending conferences, meeting with seminar speakers and engaging in similar activities, I have been asked where I am from way too many times. When the pattern repeated itself on day one of the BES conference, I thought I could do the actual count on day two of the conference. I, like many other of my fellow conference goers, get these questions at a very high frequency probably because our looks or accents give away that “we are not from here”. Though it may seem like an innocent question – where are you from? – it leaves me feeling like my fellow ecologists are more interested in why I stand out than why I belong.
To counter the question in a productive way and to get the focus back on my science, over the last year, I have made a point of replying that I am from the academic institution where I am doing my PhD. People always follow up with “No, I meant where are you from originally?” The problem is not that I want to hide where I am from, the problem is that in a professional scientific environment, where I am from shouldn’t matter. When people make general chat at conferences with a group of PhD students, most of them get asked what they do. When the conversation makes its way to me, I get asked where I am from. Followed by comments about my country of origin. Cool! Exciting! I’ve never been to that country. Why did you come here? What a poor country. Was it hard living there? The list goes on. Only just over half of the 18 people that asked me where I am from originally then went on to ask me about my work.
Reviewing is something that brings out my imposter syndrome, and I know I’m not alone. Being asked to review implies that someone views us as having expertise in a given area, which means that, if you screw up the review, you will reveal yourself as an imposter (or so our brains tell us). And, for journals that copy reviewers on the decision letter, one way to tell if you’ve messed up and are an imposter is by comparing your review to that of the other reviewer(s). Rarely, I’ve been unable to figure out which was my review, because the reviews were so similar. (Phew, not an imposter!) But what about when the other reviewer notes things I missed? Clearly that means I’m an imposter!
For a long time, I viewed it as a failure on my part if the other reviewer caught something I missed. I felt like it indicated that I hadn’t been careful or critical enough. If we aren’t super critical, we aren’t good scientists, right? (I’m being facetious. I don’t actually believe that being harsh = being a good scientist. And it is definitely not the case that the harshest review is the best review!) But what about cases where the other reviewer raises concerns or criticisms that seem important and insightful and constructive. If I missed those, I failed as a reviewer, right?
Again, not necessarily. The reason relates to something covered in a recent blog post by Stephen Heard, where he talks about finding reviewers. In it, he says he only uses one of the reviewers suggested by the authors, and explains that is because:
When I first thought about switching to R and doing reproducible data analysis, the idea was daunting. As a grad student, I couldn’t figure out how to even get my data into R. How would I figure out that plus mixed model analyses plus how to make figures in ggplot, with version control and a beautiful github rep for all of my work?! What I eventually accepted is: it’s okay to start small. Or, as a colleague of mine suggests: for any given project, aim to do one thing in R that you couldn’t before.
I’m not sure why I set the bar so high for initially learning R. When I was first learning how to knit (actually knit, with yarn and needles, not the R version of knit), I knit a square washcloth, not a sweater. So when learning R, why was I expecting I’d be able to start out with the coding version of knitting a sweater with multiple colors, a fancy pattern, and buttons?
This is a guest blog post by ecologists Isla Myers-Smith and Gergana Daskalova from the University of Edinburgh. In case you missed it, they wrote a wonderful guest post this summer on iPads and digital data collection in the field.
Ecology is a fast-paced science, with possibly hundreds of relevant papers published every week and new techniques and quantitative skills being developed all the time. It is easy to feel very behind and overwhelmed. The quantitative skills taught in undergraduate and graduate programs in ecology often lag behind those used in the literature. As ecologists at different stages of our academic careers, who have felt (and still do sometimes) pretty behind the eight ball in terms of quantitative skills, we wanted to do something about that for our students and peers. And that is how we came up with the idea of Coding Club.
How did it all begin?
Just about two years ago we had an idea. What if we set up an informal group and a website to teach key quantitative skills that could be useful to undergrads, grad students, postdocs, profs and ecologists working outside of academia? What if that website was built in a way that anyone could contribute tutorials or help to make the existing tutorials better? What if we taught people how to learn in their own working environment and how to develop their workflow using best practices in open science like version control from the very beginning? What if this content was aimed at people who felt afraid, anxious and behind in their own quantitative skills development. This was the beginning of Coding Club.
What is Coding Club?
Coding Club combines online and in-person resources to help teach quantitative skills to ecologists at all career stages. We have focused on trying to overcome “code fear” and “statistics anxiety”. Statistics anxiety – the worry about a lack of quantitative skills – and code fear – the fear of programming – can prevent people from learning. By building a sense of community around the development of skills, we hope to overcome the fear factor of ecology involving more code and math than people sometimes expect.
Part of the Coding Club team and snapshots of some of our workshops. Check out our team page for the full list of undergraduates, postgraduates and profs that have contributed to Coding Club! Photo credit for image on left: Sam Sills
Peer-to-peer teaching helps to reduce the fear factor
In Coding Club, we focus on peer teaching and interaction rather than having “trained experts” leading workshops as we feel people engage more when they are less intimidated. All of our teaching materials are developed by people who are actively learning data science skills at the same time as teaching them. We avoid hierarchy (though we love content on hierarchical modelling!) and encourage participation across different career stages from undergrad students through to PhD students, postdocs and staff. Moving away from the professor-student model and allowing everyone to engage as teachers and learners can be a pretty powerful way to break down barriers.
Coding Club covers a growing number of different quantitative skills
The Coding Club website contains a growing list of tutorials aimed at all levels of quantitative skills useful for ecologists and beyond. We cover topics from intro to advanced R tutorials, version control, data visualization to working with large datasets. We have a lot of R content but we don’t just do R! We are currently working on developing more tutorials using Python for process-based modelling and the Google Earth Engine for remote sensing analyses. We have been using the tutorials to teach in-person workshops at the British Ecological Society conference and at universities around the UK, but the tutorials are there online for everyone to use, provide feedback on or suggest revisions through GitHub. We are always looking for people to develop new content as well!
A sample of the Coding Club tutorials, including a tutorial on how to make tutorials on GitHub. Data visualisation, mixed effects models, Stan models and more over here.
Quantitative learning should be active and not passive
We believe that the best way to teach coding and quantitative skills is through a problem-based approach that is question driven. We try to avoid approaches like ‘live coding’ as it encourages learners to be very passive with the subject matter and we believe this results in lower retention of the new material. To effectively learn a new skill, it is vitally important to know why you might want to learn that skill in the first place and to have a question that you want to answer to motivate you to learn. We also recognize that people learn in different ways and at different paces. In our in-person sessions, we encourage people to take as long or as little time as they wish to complete the tutorials. We believe this casual, non-compulsory and non-assessed nature of Coding Club also helps to reduce the fear and anxiety associated with quantitative skills.
Coding our way towards finding out how population trends vary among different taxa, with cookies along the way. Not pictured: the standard error cookie. We forgot to make one, but of course we are all for reporting the uncertainty around effect sizes!
Quantitative skills are not hard – they just take some work to learn
We believe teaching quantitative skills is all about overcoming fear and building confidence. We try to avoid labeling skills as “hard” or “easy”, because we don’t want people labeling themselves as quantitative or not, or pre-judging the limits to their own capabilities. We aim to train people to be able to answer their own questions, resolve their own coding problems and seek out new skill sets independently. We are trying to teach people to train themselves beyond the timespan of a single workshop or course. Finally, we don’t think there is only one way to teach quantitative skills and promoting a diversity of approaches will reach the most people.
Coding Club has exceeded our expectations!
As of October 2018, the Coding Club website has received over 160,000 visits from over 73,000 unique IP addresses from over 180 countries. Our tutorials have been contributed by people from multiple universities (University of Edinburgh, University of Aberdeen, McGill University, Ghent University, Aarhus University) and used for quantitative training across several institutions so far (University of Edinburgh, University of Aberdeen, University of St Andrews, Queens University Belfast, Dartmouth College, Hebrew University, Calvin College, Centre for Ecology and Hydrology and more), and we are hoping to reach out further! If we can set up a network of people at universities and research institutes around the world who can work together to develop quantitative training from the ground up, then maybe we will all feel just a little less overwhelmed by our fast-paced discipline.
The international audience of Coding Club – it’s been great to get feedback from people using our tutorials around the world!
The start of the new academic year feels like a fresh start. A chance to purchase some new office supplies, catch up on all the science missed over the summer, start a new work routine to enhance productivity and to set yourself some new challenges. Now that the term has started, maybe it is time for you to take the plunge and learn a new quantitative skill.
Are you a student or group of students wanting to increase your own quantitative skills? Are you someone who has a cool analytical technique that you want to share with your peers? Are you a prof. who wants to encourage your students and mentees academic development? Are you someone who feels like the quantitative training you got years ago is not enough for the ecological research today and want to brush up on your skills? Do you have thoughts on how we can improve quantitative training in ecology? If you answered yes to any of these questions, please comment below, check out the Coding Club website and get in touch if you are keen to join the team!
Today, we have a bit of a hybrid post. It starts with a guest post from someone who wishes to remain anonymous about things colleagues have said to her during her pregnancy. Her post definitely resonated with me – I thought of writing a similar post when I was pregnant with my third child, because I was so annoyed by some of the comments I received at work. After the guest post, I’ve added some thoughts of mine, as well as some questions that I’d love reader opinions on. My hope is that this post will encourage people to think more carefully about what they say to pregnant colleagues and create a space where people can talk about their preferences.
The guest post:
I am a postdoc who also happens to be pregnant. Around the sixth month of my pregnancy something happened. I must have become large enough that it was obvious to everyone in the department that I was indeed, pregnant. Suddenly, I began receiving comments about my body, my impending delivery, and what my life would look like after having a baby. (This is my second child; I have no delusions as to what postpartum life is like).
Here are a few of the comments I received over the span of two weeks:
“Wow, you’ve really let yourself go”.
“If a baby weighs 8 lbs then where do the other 25 lbs come from?”
Misconceptions about maternity leave:
“It will be so nice for you to have a break while you’re on maternity leave”.
“Think of all the writing you’ll get done while the baby is sleeping!”
At this year’s ESA meeting, I was part of an Inspire session organized by Nate Emery on “Students As Ecologists: Collaborating with Undergraduates from Scientific Question to Publication”. It occurred to me that my talk would be good fodder for a blog post. So, here are (some of) my thoughts on some specific strategies for working with undergraduates in the lab. This post includes information both on types of projects that we’ve had undergraduates work on, as well as things that I think are important related to working with undergraduates in the lab.
Imagine you’re sitting in a talk. It’s Thursday morning at the ESA meeting and your brain is a little fried from sitting in lots of talks all week. You momentarily zone out, then try to turn your attention back to the talk. Which of these would be most useful to see on the slide as you tune back in?
You chose option 3, right? (If you are curious about the data, you can read a preprint here.)
Maybe you aren’t always giving a talk on Thursday morning during a jam-packed meeting, but there will always be people in your audience who are tired or get distracted. Make life easier for your audience by putting your take home message for each slide at the top!
Or, to quote Stanley Dodson*: “Make your top line your bottom line!”
From Meghan: This is a guest blog post by ecologists Isla Myers-Smith and Gergana Daskalova from the University of Edinburgh. I loved their comment on my post on our new lab notebook backup system and asked them if they could turn it into a guest post. I was very happy that they agreed! Isla and Gergana are off to the Arctic this summer with the Team Shrub field crew for another year of hopefully successful digital data collection. To find out more about their research check out the Team Shrub website and blog (https://teamshrub.com/).
Two things have really changed my academic life over the past five years: the first is embracing GitHub for version control of code, data, manuscripts and my research group’s individual and combined science, and the other is switching over to digital data collection. For ecologists who haven’t made the switch from paper field books to iPads and digital data collection it is not as scary as you might think!!!
Caption: Collecting plant phenology data – the recorder sitting in the back with an iPad! (photo credit: Jeff Kerby)
The benefits of going digital
Digital data collection can be more rigorous with error checking as data are collected to prevent mistakes. Data can be better backed up. And finally, it forces us to put thought into the structure of data before we collect it (significant digits, continuous or categorical data, are the data unrestricted or constrained to a particular range or particular set of values, etc.), which helps down the road when it comes time for analysis. Digital data collection has saved days, if not months, of data entry each year for my team and has allowed us to go from ecological monitoring in the field to analysis of results within hours instead of days. Our work flows are streamlined and our iPads are waterproof, so data collection can occur under any conditions – and we work in the Arctic, so we experience it all from wet to dry, hot to cold, rain, snow, you name it.