Tech Guy Makes Good: More Substance, Less Tedium in Data Analysis
By David Manuel Torres | September 18, 2017
Research Assistant, ETR
I have always been really interested in technology. In elementary school, I looked forward to “computer lab” days where the class would spend an hour at the school’s small, modular classroom by the lunch area. We got to play computer games meant to develop our typing skills. After one of these computer lab days, the instructor pulled me aside and told me that she wanted me to help her install new mice on all the classroom computers in the school.
I was filled with pride. In the days following, I eagerly knocked on each classroom door and went in to unplug the old mechanical mice and install fancy new optical laser ones.
Tech Guy
My love for technology quickly grew after that. I became the unofficial “tech guy” for my family and spent many holidays fixing their phones and laptops. When I went to college, I decided to take this interest and apply it towards a more challenging obstacle: learning how to program. As a cognitive science major at the University of California, Santa Cruz, I learned that much of research relies on processing and analyzing a lot of data. Naturally, I felt that learning a programming language that can handle that task would be most useful, especially if I was going to ever be involved in research.
I took an Intro to Python course and loved it. I then took a Python for Cognitive Science course and grew to appreciate it even more. I learned how to write up programs that tested reaction time, drew graphics on the screen, and crawled through web pages for URLs.
I enjoyed every new lesson in my programming courses, but I couldn’t help wonder whether I would actually use these skills in my life. Sure, I might need to measure reaction time for a study at some point, but software capable of doing that already existed. Why would I spend hours writing code that can sort a list of names in alphanumerical order when Microsoft Excel can do that with a simple sort command?
Turning Towards Social Science Research
As I progressed through my undergraduate career, I shifted my focus away from computer programming and towards social science research. I worked as an undergraduate research assistant in a few labs on campus. Eventually, I landed a part-time job at ETR as a research assistant. I was hired to code video footage from a study being done on pair programming in middle school children (see here and here for more about this study).
This required me to watch and code student interactions in 10-minute segments of footage of children working to create a game using Alice (a block-based educational programming environment that makes it easy to create interactive 3D games). The goal of our analyses was to describe what “pair programming” looked like for each pair. To do this, the project team was going to look at specific types of interactions: working on the game, working on something else, or not interacting. We would then figure out how long each individual interaction was, add up the total time for each type of interaction, and calculate what proportion of time every pair spent on each of them.
Coding Weekend
This gave me an idea. That weekend, I wrote up a program that did exactly what we needed. This program, which I named “EventDurationParser,” calculated the event time and generated an output of this analysis into an Excel spreadsheet. It then used an API provided by Plotly (that is, an Application Programming Interface, or programming package, that lets coders write programs that can interact with the features at a company’s website) to spit out a stacked bar chart that represented the data visually. This coding exercise took me a little over 10 hours, but I was ecstatic that it worked.
The next week, I showed the project team what EventDurationParser could do. I got an enthusiastic “Awesome!” from project leads Emily Green and Shannon Campe. And I learned from Shannon (my supervisor) that I would get paid for my time developing the program. I was in shock. Not only was my program well-received, but I was going to be paid for developing it! As the feeling of joy washed over me, I couldn’t help but think back to that day in elementary school when I was asked to upgrade the computer mice. I knew that I had value on this team.
Micro Coding
For the next few weeks, we focused on finishing up the video coding of the files. We then had to do another round of video coding, this time looking more closely at the interactions and giving them more detailed tags (a process referred to as “micro” coding).
The value of my program really made an impression when it came time to analyze these micro codes in the same way as the prior “macro” codes. Without the program, a research assistant (most likely myself) would have had to spend many monotonous hours going through the lines of each micro-coded document and calculating the time difference, either manually or through excel, not only for the macro codes but for this new batch of micro codes as well. Furthermore, when reliability checks were done and the team decided that the coding for a segment of time needed to be revised, these calculations would have to be done again.
Spending that weekend writing up the program saved us from working on these tedious, repetitive tasks and allowed us to focus on the substance of the project.
At the time of this writing, the Pair Programming project is still in motion. The EventDurationParser has been used multiple times and will soon be used again for analyzing the next set of video codes. Though I’m proud that my curiosity and programming knowledge created this program, I would be foolish to not acknowledge how important support from mentors has been for me. If it wasn’t for support such as that of my computer lab teacher in elementary school, or the encouragement and praise from my ETR teammates Emily and Shannon (“Awesome!”), I might not have had the confidence and drive that I have today.
David Manuel Torres is a Research Assistant at ETR. He can be reached at david.torres@etr.org.
