True Confessions of a Research Scientist: My Experience Working with Software Engineers

I’m Tara Chiatovich, Panorama Education’s Research Scientist. My work generally fits into one of three buckets:

• Thinking through opportunities to incorporate research in our product, from proposing new research-backed features to ensuring data visualizations are accurate and informative
• Using research and data science to gain insights from our data that can inform what happens in schools
• Supporting team members through research, including sharing articles and answering questions on research topics

Before joining Panorama, I had good experiences working with all kinds of people: researchers; non-researchers; tech-savvy teachers, principals, and instructional coaches; tech-phobic teachers, principals, and instructional coaches; and, of course, university professors. Notice that “software engineer” is not on that list. All of my preconceived notions of software engineers came from the one intro to computer science course I took at Stanford. I took it as a grad student, with zero prior experience programming in Java, and felt not-smart for all of it. I spent countless hours not doing any doctoral research to eventually earn an A- in the course. It still stings. And in the class, we heard stories about former students from that very same class who had sold their startups for seven figures. Software engineers in my head were something more than human. So I didn’t know what working with them would do to my self-esteem.

I’m happy to report that over a year into working at Panorama, my collaborations with our engineering team have been both fruitful and enjoyable. Although our engineers are scary smart, they themselves are not scary. Our partnership offers much that is mutually beneficial, with me giving some to engineers, me getting a lot from them, and a bunch of big wins.

What I give: Exposure to data science and R

Panorama has a very strong focus on research, and it’s not something that merely comes from the top. Everyone here has a healthy appetite for findings from our data and discussions of how we could address research questions. Engineers are particularly keen to know and to learn as much about research and data science as possible. How can I tell? All of the comments of “interesting” I get from engineers when showing scatterplots of how different statistical methods of scoring our social-emotional learning measures correlate with each other. And the nods of appreciation for my “here’s the gist” type explanations to them of how multi-level modeling or item response theory works.

And then there’s R, the statistical program I use for 99% of the numbers I crunch as Panorama’s Research Scientist. I’ve known many researchers who will complain that their bosses want them to take an R training when SAS is their statistical program of choice. Or who try to hire a grad student to write code in R when Stata-the statistical program they’re used to-has a hard time handling the ginormous data set they’re working with. But engineers apparently are of a different build than these researchers from my past. An excuse to learn a new programming language-even one geared for statistics and not for building software-is their idea of a treat. Like when I posted on Slack that I was going to a free Tidy Tuesday event on using the tidyverse set of packages in R, and an engineer gleefully joined me. And when I asked another engineer if she would be willing to review my R code, her eyes lit up (even though I know she had plenty of work to keep her busy). “I’ve been wanting to learn R!” was her enthusiastic reply. And why wouldn’t she? I’ve used R with RStudio to:

• Make interactive graphs in the Plotly package
• Use an R markdown file to create slide decks that have visualizations, code, and explanatory text with statistics embedded that update as the data change
• Build Shiny apps that function as data dashboards, with users selecting which data elements they’d like to see displayed
• Seamlessly cycle through different levels of data, getting means, counts, and the like for each school, district, and any other grouping of students in the data

A visualization from the ggplot2 package in R showing that students in full-day kindergarten tended to have slightly larger increases in literacy scores than students in half-day kindergarten. Data source: random sample from the publicly available ECLS-K 98–99.

R is an amazing tool, and it’s one that I’m happy to share with our engineers.

What I get: A new way to think about how I write code

In all of my jobs before Panorama, I wrote tons of code that no one saw. Instead, they saw the findings and data visualizations in the papers I wrote and the slides I presented at talks. Which meant that functionality was considerably more important than style for my code. When I started working at Panorama, I wanted to use engineers’ knowledge to change that. Finally, I wouldn’t be a lone coder, making my best guesses at how to write stylistically better and more efficient code.

So I asked some new engineer friends for tips on coding style. One sent me this style guide. Another recommended I use a linter. (R has packages just for this purpose, including lintr.)

Code warnings from lintr.

Wins: Rich research debates, xkcd comics, and friendship

And the learning continues with engineers reviewing the code I write. Their feedback has helped to rid me of coding style faux pas that carry a higher chance of human error and a greater time investment. Better yet, they give me this feedback in a respectful, helpful tone so that the imposter syndrome I developed in the aforementioned computer science class doesn’t make a recurrence. I’m even dipping my toe into Ruby to understand the code written by our engineers that pulls data. Thanks to all the great coaching and collaboration with engineering, I feel more and more like an engineer myself. (When I said that to an engineer friend, he asked, “And that’s a good thing?”)

Engineers at Panorama are research-minded, and that means incredible partnerships for thinking through all things research. Like the conversation I had at the lunch table with a bunch of engineers about how online ratings of businesses can better represent people with a range of opinions instead of only people with strong (love or hate) opinions. I also have more work-related discussions with engineers on when to conduct A/B testing at Panorama, prompting a share out of this xkcd comic on the dangers of hypothesis testing. Panorama engineers think a lot about research and want to share their views with me-whether they agree with mine or not. I have worked in settings where I was the “resident researcher,” and people simply asked me my opinion on research matters without expressing their own. That’s not a partnership, and it doesn’t move either party’s thinking forward the way a good debate does.

Engineering (Silas on violin) and research (Tara on cello) making beautiful music together.

Maybe no one will be surprised that all of the above-code reviews, exposure to R, xkcd comics-results in another benefit of my work with engineers: friendship. One of our core values at Panorama is to be friends with everyone on the team, and it shows in the respectful way I get feedback from engineers in code review. One of the engineers on the floor where I work exemplifies this value by walking around and inviting everyone to go with him when he makes a tea run. And when research needs help from engineering or vice versa, we’re always eager to lend a hand. I respect like my engineer colleagues. That’s why when my engineer friend asked whether it was a good thing that I was feeling more and more like an engineer, I answered, “Yes!”

Originally published at https://engineering.panoramaed.com on August 23, 2019.