One Week on the Quill Development Team
I’ve just started my summer internship with Quill’s development team, but I’ve already been exposed to a wide range of the development process; I’ve watched and learned as our team prototypes new ideas, manages a complex development pipeline, and rebuilds old infrastructure. Also, we often have a live feed of walruses or puffins playing on our TV. What’s not to love?
So far, I’ve primarily been following along as we build a pipeline to deliver students better feedback for their short answer responses. From data collection to classification, this task poses some difficult questions. How can we initially gather responses to our prompts? How should we classify those resulting responses? How can we turn those classifications into effective feedback for students? In classifying these sentences and building feedback, we’re exploring some novel language processing techniques, such as vector representations of words and recurrent neural networks. At the end of the day, our goal is to offer students effective feedback. Exploring technical solutions to that problem is a fascinating path to go down.
The team has also been using Jenkins, a development tool to automate builds and tests, to help automate the deployment pipeline for our various apps. Watching the Jenkins integration has taught me a lot about the development process, and it’s shed light on how much work it takes to maintain a robust, efficient, and well-tested code base. This work also ties into how our team manages servers, environments, hosting, and other backend infrastructure; the more I see of this, the more I’m amazed by how many moving parts it takes to keep a website like Quill up and running.
We’ve also been restructuring how we suggest activity packs to students. After a student takes a Quill diagnostic, we typically recommend one or more activity packs for the student to practice grammar concepts the student struggles with. As we plan to scale up the number of diagnostics and activity packs Quill offers, we’re refactoring our code to more easily recommend new activity packs. Watching this refactoring has helped me understand that software projects are more alive than static — they demand constant evolution and pruning to grow.
Most afternoons, I hone my knowledge by studying the frameworks and tools we use at Quill. I’ve spent some quality time learning Ruby on Rails (the very popular, tried-and-true web framework) and GraphQL (an efficient query language for APIs). I’m also planning on diving into more tutorials for TensorFlow as we work on classifying student text.
Thankfully, I’ve been given some time to learn all these frameworks by getting my hands dirty with a personal project. In the words of Ruby guru Richard Schneeman (a.k.a. “Schneems”), “find something you want to build . . . build it, and by the end you’ll know how to program.” With that in mind, I’m learning Rails by building my own web app on top of the Goodreads API. Goodreads is a (lovely) site where users can catalog what they’re reading; I’m building an interface for Goodreads users to visualize where they’re reading, by pinning their favorite authors’ hometowns to a map of the world.
Between all these projects (and the occasional urgent bug to patch), there’s never a dull moment in the office. After all, there are millions of students out there, and only a dozen of us.
