Working together in teams of four to six, students deliver pieces of the project at key milestones:
- Milestone 0: Generate ideas and select a product
- Milestone 1: Present a proof of concept
- Milestone 2: Release a live demo
- Milestone 3: Launch public beta with user feedback integrated
He ties the course to the software industry by inviting experienced mentors from local startups to evaluate student work. Alexey says:
While the end-products are terrific, the larger goal is understanding the process of collaborative software development. Students learn how to listen to users and incorporate their feedback in a thoughtful way.
After students ship a working prototype, the next milestone requires user testing with their target audience. And of all the challenges over the semester, students wrestle the most with addressing user feedback:
The most frequent point of failure is not understanding their users. And they wouldn’t see where they’ve failed until they try to get people to use their product.
But being able to listen to feedback, and implement it as part of the design process, is quite important. First, to learn, but also to get a job, because it’s not about writing code but actually understanding what needs to be built and how. One student now works at Amazon. Two or three work at Microsoft. One has gone on to become a UX designer. So many students really benefitted from this approach.”
You’d be surprised how often students get stuck and never ask for help
So occasionally he pops into student repositories to see what’s going on, test the code himself, and spot mistakes before it’s too late.
Next, he works with the team to think about potential solutions:
One team wasn’t sure which metrics they should track using Mixpanel. I suggested they track certain metrics at the prototyping, release, and iteration phases of their project. I gave them some perspective on how to prioritize and implement.
From another student group, who made a borrowing and lending application called Bümerang.
In an Agile classroom, the goal is not the right answer to the problem, but knowing which problem to take on first, and how to solve it in the right increments.
This course isn’t about assessing a final product and saying, ‘You did that wrong.’ Our in-progress ‘checks’ show the students we care about their work; it’s not just some assignment they need to submit for a grade. The way we care makes them more motivated in turn.”
Alexey’s research focuses on how to use industry tools to build software together, to help his students develop the social ties, trust and curiosity to sustain a successful software career.
So he uses GitHub to enable discovery, design, and collaboration:
It’s about changing the way people work: students and educators, students among themselves, and education’s relationship to industry.
I am working from the hypothesis that software built collaboratively, with many voices and opinions, will improve the collective good of future software, period.
Alexey documents all of his course designs and publishes the results of his research on student experiences with GitHub, Slack, Stack Overflow and other real-world tools.
Here’s a recent talk on his course design that discusses the benefits (and drawbacks) of using social tools in the classroom:
This is a post in our “Teacher Spotlight” series, where we share the different ways teachers use GitHub in their classrooms. Check out the other posts:
- Invest in tools students can grow with: GitHub and RStudio for data science at Duke University, featuring Mine Çetinkaya-Rundel
- How CS50 at Harvard uses GitHub to teach computer science, featuring David Malan
- GitHub Classroom for AP Computer Science at Naperville North High School, featuring Geoff Schmit
- Real-time feedback for students using continuous integration tools, featuring Omar Shaikh
Join this week’s discussion in the community forum: How do you use issues in your class?