Brian Kernighan is one of the founding fathers of modern programming. He was a member of the technical staff at Bell Laboratories at the time UNIX and C were developed, and co-authored the book The C Programming Language with C’s inventor, Dennis Ritchie. Another among his eight books is the classic The Elements of Programming Style. But since 2000, Kernighan has taken on a different role, that of master teacher, mentor, and at times friendly critic of students at Princeton University.

That transition from researcher to professor began at another Ivy League school. In September 1995, AT&T, which owned Bell Labs, broke into three separate companies?and the changes prompted even long-time Bell Labs staffers to think about alternatives. For Kernighan, opportunity came knocking in the form of a call from Margo Seltzer, a professor of computer science at Harvard University, who was going on sabbatical. Would Kernighan like to take over her class for a semester? Kernighan figured he wouldn’t have too many other chances to teach at one of the world’s most prestigious universities. And besides, how hard could it be?

The answer: very hard, especially for a rookie. Kernighan still remembers the exact number of students he had, 457, as well as the 31 “⁠teaching fellows⁠”?the students who helped with instruction?he oversaw. “⁠I worked my tail off,⁠”⁠ he recalls. “⁠But at the same time it was astonishing fun.⁠”⁠ Kernighan looks back at the experience as a kind of professorial boot camp. Having gotten through the mechanics of teaching, exam preparation, grading, and all the personnel problems that come with teaching, it could only get easier. And when a full-time teaching opportunity came up at Princeton, Kernighan changed career paths. The researcher has become a tenured professor.

One striking thing about Kernighan’s post-Bell Labs career is that he teaches only at the undergraduate level, and not just computer science majors, but students studying non-technical subjects. That has meant teaching more students and dealing more with the fundamentals of computer science. Not every researcher-turned-professor would make that choice. But the undergraduate level seems to fit Kernighan’s personality. His classes mirror what students will find in the real world, and his students, because of their broad interests, have gone on to do all kinds of things, programming being only one of them.

What do your students want to do in life?

In the technical course I teach every spring, those people mostly see themselves going off into the technical world: to pursue a graduate degree in computer science, to do programming in industry and perhaps ultimately run a business or manage a programming team. They think they will, if not change the world, at least contribute technology that the world will find useful. Some will move up the management chain, some will launch companies, and some will come back to the university and teach. In the short time I’ve been teaching, I’ve had students who have traveled each of these routes.

The other class I teach every fall is a sort of “⁠computers for poets⁠”⁠ course. Almost everybody is non-technical, majoring in comparative literature, history, economics, political science, anthropology or the like. More than half of the students are women, which is unheard of in a computer science department. [U.S. Supreme Court nominee] Sonia Sotomayor was a Princeton grad, and I can imagine that if she were at Princeton today, she would show up in my class. I think a lot of the students hope that they too will change the world, but in a very different way. They will be journalists, lawyers and politicians, run big organizations, and volunteer for Teach for America. They will learn some useful technology from the course?almost every year someone tells me how helpful it was to be able to make a Web page?but the main thing they should take away is an understanding of how technological systems work, how to reason about them, and how to be intelligently skeptical about such systems.

What do you tell your technical class about their plans and dreams?and about the field?

I point out that most of the things we have talked about over the course of the semester are the work of just one or two people. The field is still so young that they themselves could assume that role for their generation. I think there’s a reasonable chance that some kid in that class could create something as significant as UNIX or C or C++ or Java or Google or Yahoo! or Amazon. All these were fundamentally the idea of just one or two people.

What skills do you want them learn?

I would like them to have a repertoire of tools at their disposal, including different ways of thinking about how to attack a programming problem. I want them to think about all of the potential tradeoffs they will encounter, to understand that you never get something for free: if you push really hard in one direction, other directions are going to suffer. I work hard on getting them to do things that will always be important, like testing their programs. I want them to consider building special-purpose tools or languages that will help them automate some process, to use the machine to do more of the work for them. And I want them not only to build systems, but be able to talk and write about them, informally and in formal presentations. That’s pretty important regardless of what they are doing.

In my course in the spring, I give individual assignments in the first half that cover a variety of programming tasks. I tell them that this is a simulation of the real world. We’re trying to do things that they will encounter, but at a smaller scale. Assignments include mechanically testing programs, ensuring interoperability, coding to a standard, being dropped into the middle of a big unfamiliar program and asked to change it. But the bulk of the course is a group project. They get together in groups of three, four or five and build something significant. They can do whatever they want to do, using whatever tools they choose. They have 10 weeks to do it. At the end of it, they give a presentation and provide written documentation about what they did. And I’m going to do my best to break their code, so it had better work.

It’s here where they really learn things. They anguish over what language to use, but they learn that language well. They learn about trade-offs: open source, for example, is a mixed blessing?it’s wonderful to download a package that does what you want, but then you discover that it doesn’t quite work right. They learn about make-versus-buy decisions. When they don’t get code running as quickly as they thought they would, they learn about scheduling. And they learn about working with each other. In the real world, you have to get along with people who don’t see things the same way you do, whose working habits and styles are different, who you may not even get along with.

You have written about students playing with laptops and iPhones, rather than being engaged in the class. So on one hand, you have students who program mobile phone applications. On the other hand, those same mobile phones are a big distraction.

That’s true. Technically, many students find mobile phone development a really interesting area. And it can be lucrative. One group of kids in my class made over $100,000 on an iPhone app. The downside, at Princeton and probably every university, is that kids now spend an enormous amount of time multitasking in class, so much so that the instructor is no longer their primary focus most of the time. I don’t know what to do about it. I have tried to find “⁠teachable moments,⁠”⁠ showing for example how a second, identical Google search retrieves the information faster than the first because the data is cached. Other times, I’ve run Wireshark, a packet sniffer which can eavesdrop on wireless communications. That presents some good technical lessons about radio, networking protocols, and privacy. The subliminal lesson is that you don’t know who is listening to you?it could even be the guy at the front of the room.

While your students have written iPhone applications?and love the device?you do not.

I have not been able to convince the various pieces of Apple software to actually put something on an iPhone. I can do the simulator just fine, but I can’t put a single bit on the phone itself. I’ve blown three or four days of work, plus the $100 registration fee trying. It’s really irritating.

Have you asked your students for help?

I will when school starts again, and when someone explains where I’m going wrong, I’ll be okay. But Apple provides almost zero documentation on this, and the information in online forums is not enough. For me, the device has been poisoned in some way or other, and I have no idea why or how to reset it.

How has software design changed since you were at Bell Labs?

It’s gotten incredibly more complicated, with larger systems requiring more complex tools. We now have development environments like Visual Studio, Eclipse, and Xcode?all very powerful tools for building software. But these tools also hide what’s going on under the hood, which means you can find yourself with a problem too complicated to figure out, at least in a finite time with ordinary intelligence. I grew up in an environment where if I had a good idea, I could make a prototype with a few thousand lines of code. I understood all the pieces, I could be pretty confident that the prototype would do what it should, and if it didn’t, I could figure out why. Today, I might use JavaScript to glue together client-side libraries and connect it all to other libraries sitting on a server. I might write the same amount of code, and if I got it to work, it would be enormously more sophisticated than what could have been done 30 years ago. But I would understand much less about what was actually happening, and if it didn’t work, it would be far harder to figure out why.

So your expectations for your students have increased.

The level always rises. It used to be that people would make a simple Web application with 2,000-3,000 lines of PHP. Now they use a framework like Django or Rails and make something that’s much richer and complete, with a polished administrative interface that was generated automatically. The code is about the same length, but the end result is much more systematic, robust and maintainable because it’s based on a more orderly framework. Last semester, there were five Django projects, a couple of Google Web Toolkit projects, several iPhone projects, and two Android projects.

The technology changes rapidly and continuously and that presents a teaching dilemma. I’m torn between trying to teach students the fundamentals?writing tiny self-contained programs that really work?and dealing with big frameworks that crank out a lot of code automatically but hide what they are doing. There are more of those tools all the time. Which ones are going to still be viable in five years? Which ones will matter in the real world? I certainly don’t know. The frontier of what students need to know expands all the time, so the best I can do is to expose students to ideas and give them some experience with some modern software systems, without forgetting the fundamentals of good programming practice.

At the end of your technical course, what’s your “farewell” message to students?

I usually tell them, because it’s true, that they have done amazing things. They have managed to come up with something really interesting and made it work well, while they were also enrolled in four or five other courses and doing extracurricular activities. Every year, the combination of more hardware resources and more powerful software systems raises the level of what they can build, so every year the projects are more impressive. It’s incredibly rewarding to watch this happen.