The End of Computer Science Education
This is the first in a series of entries regarding the future of computer science education. This is something I care about deeply, and I’ve been spurred by conversations with colleagues across the nation. The NSF is concerned about the we are educating future computer scientists, and they have been holding town hall meetings nationwide and more informal meetings whenever they gather, e.g., at PI meetings and panel reviews.
As a professor, I can provide some easy answers to computer science education:
- Students should learn mostly the same courses I learned as an undergraduate, with a little updating to make them more relevant.
- Students should learn about my research area!
- Students should learn skills that are valued by industry.
- Students should learn skills that will get them into graduate school.
The first answer is by far the easiest. We form our notions of importance by the way we learn. I know, for example, that writing console applications is important, because I spent a great deal of time learning how to write them. When graphical applications became the norm, I learned how to write those, too. But to be honest, I’m not as comfortable writing GUI applications as I am writing textual applications–partly because I have no visual abilities. Besides, writing GUI applications is harder. It requires a different way of thinking, because it puts the user in control of the event ordering and it requires working with multiple threads to provide a responsive UI. These are obviously advanced computer science issues, so from a pedagogic standpoint, it makes sense that we wait to teach this until students are ready for such concepts, maybe when they’re seniors. Of course, this line of reasoning ignores the fact that many programmers, even non-computer scientists, can write perfectly good GUIs with tools such as Visual Basic, Flash, etc. Other questions arise. For example, should we teach numerical analysis or not? How about compilers? Graphics? Operating systems? Architecture? Artificial intelligence? Discrete simulation? Many of us professors took such courses are undergraduates, and we value the experience we gained from them. It follows that we want our students to derive the same benefit. But will they? We accept that learning about mainframes is no longer a valuable skill, despite the fact that many of us were trained on such machines. By the same token, maybe learning about operating systems is useless now.
The second answer is easy to dismiss. On the other hand, it is also very seductive. When a professor says something along these lines, it is easy to question their motive. Perhaps, one could say, they simply want to teach a course in their field of interest instead of something that is more useful to the students. Such a motive, of course, is inexcusable. But that may not be the real story. Just as very few actors believe that a movie can be improved by having less of them on screen, few professors believe that learning about their research area will harm their undergraduate students. For example, I do research on automated theorem proving. While I question whether undergraduates will benefit significantly from learning about mechanical theorem proving, it is obvious to me that they should become proficient in formal logic. That many students graduate and pursue wonderful careers in computer science without acquiring even rudimentary knowledge of formal logic does not deter me from my convictions.
These first two responses put the cart before the horse. Like artists who define art as “whatever it is that artists do,” those who take either of the first two approaches are avoiding the need to think deeply about the problem. The problem with these approaches is that they are ad hoc, lacking a basic structure or story that helps to define how we should think about the problems. It leaves us without guidance when we ponder whether calculus or discrete mathematics is more important. True, we all had to learn calculus when we went to school. But true, we haven’t used it much since, whereas discrete math is something we use every day.
I propose that before we can answer any issues regarding education, we have to answer the question of the end of education. Neil Postman makes this point in several of his books, most notably in The End of Education, which inspired this entry’s title. What is the point of computer science education? What is the end to which a computer science degree is the means?
From a student’s standpoint, the answer is probably one of the last two answers above: to get a job, or to go to grad school. In a perfect world, these would be the same answer. However, many skills that may be desirable to employers are irrelevant to graduate schools and vice versa. For example, 40% of the questions in the GRE Computer Science Subject Test are in the area of computer science theory–which is largely insignificant to computer science professionals.
That the requirements for grad schools and industry are potentially different is not, by itself, catastrophic. It may be reasonable, for example, to prepare students to meet both goals in a single degree, e.g., by offering a course in theory to all students. In the worst case, we can do what other departments do, and let students customize their degree according to their individual goals. For example, mathematics majors have a wide selection of courses they can take as upper-division electives, and the math department offers clear guidance based on the types of career choices the students may want to make.
So the real questions are these:
- What prepares students for industry?
- What prepares students for graduate work?
The second question is, perhaps, easier to answer–mostly because all professors have been to grad school. The first step, of course, is to be accepted into grad school. So our degree program should offer courses that match the requirements of the GRE Computer Science Subject Test. The second step is to succeed in grad school after you get there. Grad school is about independent thinking, creativity, and problem solving–what we call research. So giving students undergraduate research experience, which is to say experience solving hard problems by themselves or in small teams, is extremely valuable. In many ways, I think the traditional undergraduate curriculum works well here: programming, data structures, algorithms, programming languages, formal languages, compilers, databases, networks, computer architecture, operating systems. The research experience can come from REU grants, aligned with an individual professor’s interests, or capstone courses, which can be tailored to the individual student’s interest’s instead.
What prepares students for industry? There’s a hard question! Just as with grad school, there are two issues to consider: getting a job, and succeeding in industry. One of the problems is that the answers to these questions are not necessarily the same. Many employers (foolishly) look for specific technology skills, like knowledge of specific languages and toolsets. But these languages and toolsets change rapidly, so the key to success in industry must involve something else.
One way to puzzle this out is to consider the kinds of companies that will employ students. A recent survey suggests that 80% of jobs for graduating computer science majors are in Fortune 1000 companies. That immediately implies that students need to have superlative communication skills, both oral, interpersonal, and written. They will be working with large codebases and sophisticated tools. So they must be able to read a large amount of existing code and understand it–quickly. They must also be able to understand how those large programs interact with others to solve the organization’s problems, i.e., software architecture. And, of course, they must learn how to understand the organization’s problems in the first place, so that they can develop solutions for them. This suggests an entirely different kind of undergraduate curriculum than the one we offer. Students need courses in programming, writing, communications, programming languages, databases, networks, computer architecture, software architecture, software engineering, usability, and systems engineering.
Systems engineering is especially important, because large software projects are usually part of larger projects, so-called “software-intensive systems”. Working on these systems brings up subtle issues of control and feedback, eloquently described by Weiner in the field of cybernetics. Surprisingly–at least to those who cherish a computer science based on discrete math–this involves advanced mathematics, such as optimization theory, control theory, Markov chains, and statistics. This is the province of continuous mathematics, and calculus, multivariate calculus to be precise, is its foundation.
What will it take to move the curriculum in this direction? Is this even the right direction? I don’t know yet. But asking the questions is a start. I’m starting a journey that will lead me towards a vision for computer science education, a vision I may or may not have the opportunity to develop. This and the other entries in this series are the record of that journey.