Ryan Heathcote Engineer. Teacher. Dreamer.

The Problem with Computer Science Capstone Courses

As a recent college graduate turned (or perhaps still turning) professional software developer, I often find myself pondering my college education and how it could have been better – how it could have more effectively prepared me for the kind of things I do now.

Lately I’ve been pondering the teamwork aspect of working as a developer. It is something that was not emphasized in my education to the extent that I experience it in the organization. And I’m not calling for more group assignments, per se. I tend to have apprehensions about group assignments as they are practiced that would make for a separate post. I think group assignments are exactly not the way teams I’ve worked on have worked. The teams I work on are made of developers of different experience levels and different areas of expertise. I frequently ask my senior devs for help or advice. They review my code. But at times they will also ask me for help when working on a platform with which I am more familiar – or sometimes when they just need the act of asking a question to solve the problem. So group work isn’t exactly the same. Most students are still students – they may know a bit about different things – but you don’t get the dynamic of having a dev with ten years more experience than you telling you how you can make your code actually readable.

The other aspect that I’ve only recently been understanding is the community. A lot of problems are solved in (online) community – between open source projects (mostly) hosted on github, and finding answers to questions (mostly) on stackoverflow, a lot of the time I spend solving problems involves the programmer’s best friend, Mr Google (which takes me to one of the two aforementioned communities regularly). In other words, I gain a lot from the resources the software development community provides.

Though I haven’t contributed to an open source repo in any significant way, I know what code reviews have done for my abilities and confidence as a developer. So I know that a good open source project, with a solid set of people driving it, can provide the same kind of learning to me and others who contribute. I have recently been looking to contribute to a project I am passionate about, Aurelia, and am keen not only to be a part of that community, but to learn from people I would probably never meet on the street.

I have also more recently started interacting with the stackoverflow community. I admit initially I just wanted to boost my reputation so that I could do things. But as I started engaging with the site, I started to realize how my actions can contribute to others the value that I derive from the site – upvoting good answers (because I look at the number of upvotes when evaluating the quality of an answer…). Commenting on questions to add information that is useful. Asking questions, because others might have the same. The key thing I’ve discovered is that interacting with the community, a community that can at times be very harsh, I have learned to communicate better. I have learned to look for information and answers that are meaningful, and I have learned to share those answers in ways that are clear. I’m not saying I’ve finished learning these things – but I can see that I have improved.

Now to connect these thoughts back to capstone courses and teamwork: In a university, you might be able to get the depth of experience by having professors review student code, and encourage team assignments. But professors already don’t do enough research. And professors aren’t on the cutting edge of software development in practice like a good software shop. Or a good open source project. And finally, the capstone course that is supposed to bridge between being a mere student and a real-world developer lasts for only 1 or 2 semesters. Hardly enough time to really practice the community and team interactions that really grow developers.

What if we had students spend at least their last two years, if not longer, doing two things:

  1. Find an open source project you like, and find an easy issue – starting with that, contribute to the project. Instantly, you are able to be mentored by a good programmer, for the cost of your legwork on things that may take time away from the main contributors solving deeper problems. You learn to develop code on a team, not just for yourself. Follow conventions, make things readable, that kind of thing. And take constructive criticism. (I’ve also found with several projects I’ve worked on where I was coming in long after the project had been first deployed to prod – I started out small, doing very simple tasks that I barely understood, and over time I figured out enough to be a major contributor on those projects. Each task taught me a little bit more, and over time, that built).
  2. Find easy stackoverflow questions on things you are learning about, and answer them. The process of researching things you don’t know teaches you. And the process of interacting with people you have never met about strictly technical matters in a place where you want to look good encourages you to learn good communication.

I think that if students started these things earlier in their time in college and kept them up, they would end up being better prepared for lives in the world of software development. They would be better programmers (having been mentored by much more experienced developers), better team players (having practiced working on open source teams), better communicators, and better problem solvers. The other thing is that they would have a body of self-directed contributions (to the open source project) that would demonstrate their skills to potential employers. It is not uncommon for potential employers to ask for links to github and stackoverflow profiles. These places demonstrate skills in a more measurable way than almost any interview process ever could. Why not get students building those before they graduate?