One of the things I've heard for years from former students - both those looking for jobs and those looking to hire is that colleges don't really do a good job preparing students for careers in tech. Sure they teach the algorithms and the theory but ther are a lot of missing pieces, particularly on the practical end. I'm certainly not advocating turning CS programs into coding schools but there are many low cost opportunities to bring practical real world best practices in to the CS classroom. I most recently wrote about unit testing and had earlier about using GitHub as an educational tool. I've been happy with the way I introduce students to Git and how we use GitHub in my classes but I've never found a smooth way to introduce Pull Requests. A pull request is basically a mechanism by which one can suggest a change to a project even if you don't own it. The project owner can then decide to merge it in or not.

Being comfortable with the pull request work flow is an important part of contributing to open source projects. The basic process is that you make a copy of the project you want to work on by forking it, make your changes, then issue a pull request back to the project. For a beginner, there are a lot of moving parts. Instead, I teach my students branching and merging within a project. It's much easier and arguably more useful for day to day projects. I'd like my kid to learn the pull request mechanics but I haden't thought of a good way to do it.

I've also wanted to give kids more real world experiences in class and one experience they rarely get is working in other people's code bases. In school you largely write your own projects be they group or solo or work off a hopefully tried and true code base provided by the instructor. In the real world you're frequently working off of someone elses code and it's rarely in a polished state.

I finally found a way to kill both birds with one stone. A couple of weeks ago my class' lab was rather lengthy. It involved reading in a source file and reformating it in a sensible way. I knew most of the students wouldn't finish it in the allotted time and even if they did, this was an easy assignment to extend. On lab day I had students create a new repo for this lab (normally they just add a folder in a their "labs" repo) and get as much done as they could. The rule was simple - push what you've got up to GitHub at the end of class and then you can't push anything else. I also made it clear that I didn't expect a completed lab..

We continued the lab in the next class session. This time. I randomly assigned repos to students so that they would fork someone elses lab. They then had to complete the lab on the other students code base and then issue a pull request back to the original

This was the first time I've tried this so it was a little klunky. I'll do a much better job specifying the assignment and instructions next time around but even so I think the class went well. By the end of the class the students had sucesfully forked a project, issued a pull request, and merged one in to their own project. The only think I wasn't happy with was that many of the merges happened automatically. I have to figure out how to set things up so that there are merge conflicts since I want my students to experience that.

Overall, I was very happy with the way things worked out. The students were able to experience important real workd software engineering techniques without removing any of the academic CS in the class.