Let's Help Computer-Science Students Crack the Code

Having recently become the head of a computer-science department at a leading university, I think it's great that student enrollments in the field are growing, there's tremendous demand in hiring, and the need for graduates who can handle "big data" is being felt across business, academic research, and government. What concerns me, however, is that despite the huge changes in the field of computing over the past couple of decades, the way we teach it is not changing fast enough.

The basic skill of the computer-science field is, not surprisingly, computer programming. Just as a biologist or chemist will not get too far without some laboratory skills, it's a rare computer scientist who can make it in the working world without being, or at least having been, a strong programmer. So you would think we would teach our students the right ways to do this, wouldn't you?

I spend some of my time on advisory boards or as a consultant to start-up companies, generally those doing bleeding-edge Web work. When it comes to making their systems work, successful firms generally have the following practices:

Share. A best practice is not to let anyone code alone. One reason for this is because people programming in pairs or teams tend to catch each other's errors. It is also important because the company shouldn't be dependent on one programmer who might get hit by a bus or, perhaps even worse, leave for another job. Someone needs to know how the code works, or the company is out of business. Small companies usually do this informally, while bigger ones use a code review system, but either way—people share code.

Present. Good companies make sure their programmers present to everyone in the group, not just other programmers. The marketing folks, the user-experience gurus, and especially the management all need some shared knowledge of what is happening under the hood. This doesn't mean line-by-line code presentation, but it does mean that programmers can explain what is happening in a way these others can understand.

Reuse. Agility has become a primary aspect of market survival and eventual success. Smart companies have stopped developing their programs from scratch; it's easier to grab the great libraries full of useful code available on the Web and tailor them to their needs. That way they get something up fast and start the business sooner. Then, as their companies grow, programmers refactor the code—that is, they make the pieces more efficient incrementally while the rest of the code continues to work.

But here's the thing: In typical computer-programming courses we don't do any of these things. If a student looks at another's code, it's cheating. Programs are turned in to teaching assistants for grading; they are not discussed. And to download code from the Web and use it in an assignment is considered plagiarism—a university-level honors violation. How crazy is that?

Here's what some of my colleagues and I have started doing in our classes to try to change the culture.

Set up a code library. Start the students from good code that can help them get up to speed fast. Even better, let students publish into this library, and give them credit for this. Give them even more points when their code is used by others. Reward sharing, don't punish it.

Have students work in teams and present their work together to the rest of the class. Students learn how to explain their approaches, and they should be graded on it. Students listening to others hear about multiple ways to solve problems, not just the ones they've hit on themselves. It's win-win. This does require more open-ended assignments than are typical in early classes, but that's a good thing in itself; it inspires the students to be more creative.

Have students critique one another's code, approaches, and presentations. Learning how to think critically about other people's work is a key to improving one's own, and it's a crucial team-performance skill.

In short, we should design means that reward students for doing the right things early in their education. Teach them to share, to reuse, to present, and to work in teams. They shouldn't wait to learn this on the job. It's got to be part of the core curriculum.

Here at Rensselaer Polytechnic Institute, and at other leading schools in the field, we've begun revamping our curricula to put more of these ideas into practice—and it's time the practices started spreading much more widely, including to the high-school level. After all, students coming through these programs are some of the most sought-after in the field. That's a good thing for them, and for the future of our country. These kids can be some of the key innovators in the new economy; let's give them the right tools to make that happen.