St. Hacktrick’s Day
Last Saturday, I drove too many hours to Keane University for St. Hacktrick’s Day, the first (?) EDU+GoogleAppScript focused hackathon. It seems like a simple formula; coders + teachers + pizza = new tools for Google Apps. Its now three days later, and I feel like if I don’t blog through my memories and reflections now, the important stuff will vanish into the haze of History of the World in 100 Objects podcasts. Because, dude, I listened to a LOT of those in the car.
Unlike StartUp Weekend, which focused on bringing developers and entrepreneurs together with teachers and EDU ideas, the coders for St Hatrick’s Day were primarily undergrad CS students from local-ish schools. Educators were invited to submit project ideas when they registered, which were then vetted and selected by coding teams. This amounts to serious labor from Andrew Stillman (organizer, coder/edu hybrid, author of Doctopus), but it was the critical effort allowed anything moderately functional to emerge from the “short” 8 hour session. A few groups formed up as the day started, and the gap between their demo product and the teams who started meeting and planning through G+ Hangouts earlier in the week was striking.
The other feature that sped up the usual hackathon research-write-fail-fix cycle was the presence of Arun Nagarjan from the Google Apps team. There was a line three coders deep waiting to ask questions about specific GAS behavior, best practices, or hidden resources. Having an authoritative voice about the coding platform in-house reduced the number of StackOverflow searches by a factor of 10, at least. Especially for GoogleAppsScript, which is an evolving Google product*, which means that even good advice has a distinct shelf life. I’d bet that a quick word from Arun saved each team a few hours of work down less productive paths. It only took him 30 seconds to look at my outstanding problems with the Learning Center Reports and devise that the proper solution is to rewrite the entire UI in HTML Service. That was one of several factors that left me hankering to sit down and code for a few hours at the end of the event, which is probably a good sign for hackathon style events.
While the undergrads were coding away, there were two breakout sessions designed for educators. Andrew Stillman ran the first one as a tour of how to install and use mature scripts from the GAS Library as classroom tools. Even using Doctopus as a model, which has a well-structured and specific installation process, it was clear that this wasn’t going to be a quick process for teachers. The big hurdle is that GAS scripts all depend on particular data structures**, manifest in the Google Apps environment as spreadsheets and folders and all identified by UID. Specifically, the process of manually gathering all of the UIDs from the Google Apps URL scheme seemed really daunting to teachers, and adding another tool (GClassFolders) to manage that process didn’t improve matters much.
A bit later in the afternoon, I took my best shot at an AppScript 101 lesson for teachers. My GAS code is way, way uglier than Andrew Stillman’s, and this presentation was definitely a Rudy Huxatable maneuver. I started too deep in existing code, but after some great (and very direct!) audience feedback, we rolled back to a blank form and wrote a simple email script up from scratch.
Yeah, ok nerds, I recognize that this is deeply in “I made a pizza using only $20 and a cell phone” territory, but that doesn’t diminish it’s worth for educators. Imagine living in a world full of pizza delivery and mobile phones without that basic skill! Twenty years ago, there was a flourishing culture of school specific software, written by interested teachers or staff to solve problems unique to their environment. That was followed by decades of cruft, as either the software became completely intertwined with the individual who maintained it or it atrophied into non-existence. What can make these AppsScript tools different is a broader base of educators with enough computational literacy to ask questions, request features, and help shape the tool rather than molding their practice to it’s strange demands. Events like St. Hacktrick’s Day are essential for that vision of an engaged and literate teaching population. Most teachers won’t learn to code because codeacademy sounds cool, but they’ll learn what it takes to make their classrooms better. For that reason alone, I’m ready to start planning for a Hack4ed event in the DC area this fall.
At the end of the day, groups presented their demos to the room and there was a flurry of voting and prizes. I appreciate Google’s willingness to support the event by providing these prizes, but I’m still enough of a Kohn-head to wince a bit when rewards come out and winners are separated from losers. For an EDU focused event, one designed to create new tools not new companies, I’d really prefer an end-of-day event that pushed all of the code bases into a publicly accessible repo. None of the tools created were in a useable state, and I worry that the finality of winners and losers (combined with undergrad priorities) lowers the chance of anything from St. Hacktrick’s day growing into successful classroom tools.
The end of the event was also difficult to watch as a progressive educator. In a room full of bright kids and dedicated educators (Saturday, remember?) building tools that sort, group and monitor students by simple numeric grades. I recognize that it’s totally unfair to compare these demos to the richness of educator designed tools like BlueHarvest or ActiveGrade, but they weren’t even pointed in compatible directions. It reminded me how much the culture of our schools matter, and how long the shadow of those dehumanizing, reductive routines follows even our “successful” students. One demo product build a simple NFC reading android app, and pitched it as a way to improve the accuracy of classroom attendance systems. Here’s a tool that would allow students to signal their presence from literally anywhere with signal***, and the best use seems like making who sits in what desk more ironclad? If we wind up in a NFC-infused world in a year or so, I’m going to take a system like that to bust kids out of the classroom, let them check in every few hours from the FabLab, the blackbox theater or deep in the watershed. Educators have a role in these events that’s beyond simply making the grisly mandatory tasks of school more efficient. We need to harness those tools to eliminate those systems of control, use the efficiencies to return choice and agency directly to students.
Undergrads can design tools to speed up the schools they remember, but we need educators to design for schools we’re still dreaming up.
* It was the weekend after Reader’s announced demise, so read that how you’d like.
** (The PLT/Racket/Scheme folks would remind us here that all programming stands on a data model, and these hassles are intrinsic to any attempt to backport a given program onto a pre-existing data pile. The proper way to go about this is to carefully build the data structure and then design the program to fit it like a glove. Sigh. So remember to feel bad about yourself when you’re trying to make things actually work in your classroom. )
*** NFC tags are as mobile as a sheet of paper and require no power.