Today I got to be a judge at StuyHacks VIII. This isn't the first time I've been a judge there, I've been doing it for a few years now. I've also been lucky enought to have been asked to judge a handful of other local hackathons over the years.

StuyHacks is a high school hackathon organized and run by students at Stuyvesant High School. Since it's run by students, the cast of organizers regularly changes. They run two events a year. One is a morning to night hackathon hosted at the school and the other is an overnight hackathon hosted externally. Recently Gakko has been gracious enough to host.

While the largest group of participants are from Stuyvesant, the event draws from all over NYC, Long Island and New Jersey. Most of the participants are high schoolers but there are always enough younger students to make it a comfortable event for middle schoolers as well.

As usual, the participants did some great work. The winning project was a medical diagnosis application and second place was a contraption to sort garbage into recyclables and non recyclables. Both reminded me of academic research that a friend of mine was doing around a decade ago. It struck me that with current tools, libraries, and APIs, something that was a really hard problem 10 years ago can at least be explored by young programmers in a short period of time.

There were also some very interesting games and a variety of neat projects.

I also started to think about the difficulty in judging projects. Over the years I've worked with a large cadre of judges. All were involved in tech but many weren't programmers and many hadn't had any familiarity with the technologies used at a typical High School or College Hackathon. There were a lot of very cool projects but while a great idea well implemented does indeed make a great project it doesn't necessarily make one that shows great programming or software architecture skills. I remember a few hackathons ago where a judge was incredibly impressed with the implementation of a project where it was merely glue and a little tweaking of example code.

A few years ago when I saw a project that used a machine learning or AI technique it meant the group coded it. The kids implemented a classifier from scratch, coded up a regression, a clustering algorithm, or whatever. Now, they don't have to know anything about ML or AI - merely how to use the IBM or Google APIs. It doesn't mean they don't know these things but rather that they don't have to. It also means that since man students can now leverage other peoples tools quickly and easily they'll get much better results.

Today I saw a project that was pretty neat - it did a bunch of real time image processing. It made extensive use of libraries and it was indeed a very nice project. I saw a simpler similar project a few years ago where those libraries weren't available so the group had to code simpler versions of the functionality by hand. It was also a cool project but since it was all home grown it did less and was much less polished. Which one was better? Who's to say. Of course this makes things hard when comparing projects - some kids know more about tools and libraries than others.

None of this is to either add or take away from what hackathon participatns can and do accomplish. I loved the projects from hackathons past and I loved what I saw today. It's just interesting to see how things are evolving.

In any event, if you have a chance to go to a local High School hackathon either as a judge, a mentor, or just as someone to look at some youngsters projects and give some words of encouragement I highly recommend doing so.

StuyHacks VIII was a great event and I hope the organizers give me the opportunity to continue to be part of it in the future.