Teaching Students How to be Hackers

Borja Sotomayor ran a session talking about how we can teach college students to be hackers. Borja has taught a number of CS courses at the University of Chicago and is also a Teaching Consultant at the unversity's Center for Teaching and Learning.

Borja jumpstarted the discussion by talking about his own experiences teaching students how to be hackers. This involved not just incorporating some typical "hacking skills" (scripting, working collaboratively, code versioning systems, reading code not written by you, various specific technologies, etc.) in a course but also transmitting a series of core hacker values, specially that students should find a sense of fun and play in your work and that they should be encouraged to experiment on their own. Borja described his experiences teaching the lab sections of an intro programming course, where students did exercises that involved collaborative development, code reviews, etc. and in a databases course where students wrote a Relational Database Management System from the ground up collaboratively in groups of four (with some of the code being shared by the entire class).

Throughout the session, and in a couple side-discussions between sessions, we discussed the following:

• Collaborative exercises shouldn't be done because you expect magic to happen when two or more students and placed in a group. These exercises should involve the type of collaborations that arise in the real world: writing code collaboratively, doing code reviews, etc. However, they shouldn't be mandated "just because". The goal is for students to see how having these skills is useful, not just an academic exercise. Borja described how he's experimented with some of this, and Britt suggested that incorporating agile programming might be worth looking into.

• The best type of exercise or project would be one where the student are incentivated by more than just "if I hand this in, it will be graded by an anonymous TA and my grade will affect my GPA". There should be goals that go beyond just getting a grade. Borja mentioned how he partially addresses this by using code reviews (your code is going to be reviewed by your peers, which gives you an incentive to write better and cleaner code) and by using "cool" exercises (e.g., implementing a DB system from scratch in plain C is something you can brag about later, specially to prospective employers who want to see proof that you can implement a complex system, not just toy homework exercises).
• Cool idea that some schools (Stanford, etc.) are already doing: encourage students to develop real projects that can be released into the wild, and provide a prize (a few $1000's) that can be used by students with the best projects to incubate their project. Nowadays, Facebook apps, IPhone apps, etc. make it easier to develop a real application that can be released to a wide audience and that can benefit from even a small injection of capital.
• We have to teach students to teach themselves.

• Dan Sinker: "Classes need less requirements, more experimentation"

• There shouldn't be so much emphasis on succeeding on the first try. In real life, you go through several try-fail-try-fail-... iterations before you get something right. "Failure is an option"