Yesterday I was one of the judges at StuyHacks. A one day hackathon at Stuyvesant run by and organized by the students. I don't have attendee stats but there were kids from all over the city and at least one team from New Jersey. The youngest student that I met was in sixth grade and the oldest were high school seniors. The judging was at the end but I decided to stop by earlier to see how the hackers were doing.

There was an incredible variety of projects using a wide array of tools. There were projects built with:

• Java
• Processing
• C#
• Scratch
• A-Frame
• Python / Flask
• HTML/CSS/JS
• and more

A personal highlight for me was running into Sophie - the daughter of two of my students from #Stuy95. Well, both a highlight and a reminder that I'm getting old.

The StuyHacks team did a terrific job running things and at the end I told them I'd love to help with future events.

I did notice a couple of things at the hackathon that echo things I've learned as a teacher over the years and I thought they were worth sharing.

The first was the a number of the beginner groups needed more direction. This didn't seem to be related to grade level or age as much as CS experience. This isn't a hackathon only issue. It exists in all learning environments. If as teachers we're too prescriptive students end up with a single formula to follow. Sure, that'll get them through a standardized exam like APCS-A but too much of it can hinder them in becoming creative problem solvers.

On the other hand, not enough structure will leave many kids staring at a blank page. I remember I gave a quiz years ago. It had one problem: "You have 20 minutes to prove to me that you learned something about the past unit on Cellular Autmata" or something like that. Some kids absolutely loved it but many hated it. Stuy kids are trained test takers. They're prepared for structure. This threw many for a loop.

I noticed this issue with some of the hackers at StuyHacks. Some beginners really had a hard time figuring out what they could do and what they should do.

A hackathon isn't a classroom so I think the problem is pretty easily remedied. Groups that were able to latch on to a good mentor seemed to get the guidance they needed. A beginners hackathon should make sure they have not only plenty of mentors but they should make sure that the mentors are prepped with a number of project ideas in a number of the standard beginner platforms. A hackathon could also provide an assortment of ideas in a list.

The second thing I noticed was at the end of the day as I was judging. It started with one particular group. They were pretty apologetic about their project. Basically because it wasn't finished. Personally, I thought what they accomplished in essentially 7 hours was pretty impressive. What became clear as we talked is that this group was deathly afraid of failure. Their deepest fear at that moment was that I was going to give them high marks and they might have to show off their incomplete (yet rather impressive) project to a room full of strangers.

This fear of failure was prevalent in groups that ultimately didn't submit their projects for judging and it seemed to be common among students from high performing, high expectation schools where frequently one associates a test score or grade with ones value. I'm not happy to say that Stuy has always had this problem.

This isn't really a problem that a hackathon can or should be able to address. It's just something I noticed. It's a problem for schools and also for a society that's test obsessed.

I hope nobody reads too much into these observations. The day was a tremendous success. A whole bunch of kids had a great day working together to build cool things with technology. Congratulations to the StuyHacks team. They did a terrific job putting it all together. If you're a middle or high school student or know one, keep an eye on the StuyHacks web page and make sure to attend their next event.