by Catherine Soriano Luna
by Jordan Tompkins
As Bryan Gerard mentioned in a previous blog post for our lab, we’ve now split our rather large research team (7 undergraduate students, 2 graduate students, and 1 professor/researcher) into three separate teams for data analysis. In this blog post, I want to talk about how we’ve navigated the process of data analysis thus far, and where we’re headed.
At the outset, each of the undergraduate students spent three weeks learning about text analysis, helping to create a codebook for the wildlife conflict project, and coding interviews and field notes. Then Jen made them go back to the original documents and recode everything they’d already coded. Why would she do this? Is she some sort of sadist who enjoys making others complete the same task multiple times?* While I can’t speak to the second question (don’t fire me, Jen!), there are several reasons to wipe the slate clean and start again: (1) anthropologists review our field notes multiple times to get a feel for different patterns that emerge from our data. Being familiar with the data is part of the job. (2) Codebooks often change during the course of data analysis. Patterns emerge, codes need to be collapsed together or separated from one another, etc. Our codebook went through multiple changes during the first phase of coding. We could have gone back and just added the new codes, but we needed to look at the data from the slightly modified direction of research. (3) Although I’m very familiar with MAXQDA, the qualitative data analysis software we use, I’ve only used it on projects where I’m the only person coding. Working as a team may seem like it’s simply an extension of a one-person project, but there are intricacies in the software that I never realized were there until we encountered problems. For instance, when the students began importing their coded documents, many of the codes were duplicated in the codebook on the program even though they had the same names. We had to figure out how to merge those codes and prevent this from being a problem in the future. Additionally, everyone had to learn about some of the more technical aspects of MAXQDA. Although I wouldn’t classify this as the fun part of data analysis, it’s absolutely essential to understand how/when/why to do things when working on a team. A small mistake made while importing a document can create a lot of unnecessary work.
Now the undergraduates have finished the second round of wildlife coding and have been assigned to analysis projects based on their interests. We’re still part of the larger team, of course, but I’m excited to work in a project with only three other people (Shout out to Bryan, Hayatt, and Rachel!). We meet on Monday to discuss aspects of socio-ecological systems theory, and how to incorporate those into our coding and analysis. Wish us luck!
* I suppose having students recode something they’ve already done might seem sadistic. Jordan pointed out 3 very good reasons. I would like to add to this. Learning new software and new analysis skills requires making mistakes, failing, and just general mucking about to see what happens when you push a button. This is a process all of us face when we learn new skills; our first product out of the box is meh but the next one is better because we learn from experience. While all of the students working in our research group are bright, this was their first time using both the software and coding text. The wildlife conflict interviews were the most concise group of interviews to work and had a set purpose. I wanted students to learn new skills and new software simultaneously, which meant that I was expecting mistakes, miscoding, etc. However, this data is important. It will be used to write a report and make recommendations about resolving human-wildlife conflict, as well as explore connectivity and elements in a complex social-ecological system. Therefore the data prepped for analysis has to be in it’s best possible form. Ergo, requesting students to recode the interviews with a set of codes once they’ve learned the skill and the software. I have faith they’ll do a good job of it and I won’t come back to a lab full of brooms sweeping up an ocean of water.
by Bryan Gerard
As the summer ended and the fall semester began, it was time to begin our research with Dr. Shaffer. The research team began to meet to discuss the direction of the study and learn what would be expected in this lab. During the first two weeks we were provided the opportunity to practice both inductive and deductive coding. However, this past Friday, 9/26, we decided to break up the research into several projects (Wildlife Conflict, Health, Indicators of Change, and Agency — also Local Mapping of the Social-Ecological System and GIS). Dr. Shaffer differentiated these projects to enable the research assistants to gain experience in fields that interest us. More importantly, the various projects, while seemingly diverse, also exemplify the interconnectedness of the challenges in an area experiencing a plethora of social and environmental changes.
However, before we focus on the varied projects, we are all coding interviews about wildlife conflict. This has become a major issue for the local population and Mozambican government as elephants from the neighboring reserve have wreaked havoc on the local community, destroying crops, homes, and in several cases killing humans. This work will then be used to write a report for the Mozambican government – which will ideally highlight where and how to make changes.