One popular topic in Computer Science (among other disciplines) is whether professors are out-of-touch with “real world” programming. Those who argue for less academics in CS education claim that university degrees prepare students poorly for industrial roles. Plagued by an environment in which theory and research are preferred over practical skills for daily software development, these students enter the workforce ill-equipped to write professional software.
This article will not take a strong position about CS education. Rather, it will describe the advantages and disadvantages for education taught by academics and professional programmers. I will also discuss some challenges of enlisting non-educators to lecture in the classroom and why universities structure their staff the way they do.
In this article, we divide the world of programming into two schools: the academics and the professionals. The true nature of our discipline is much more nuanced: even within the ranks of software engineers, some write code purely to fulfill business purposes while others write code that makes programming easier, solves some computational problem in a satisfying way, or explores new frontiers for frameworks and tool sets. The academic side has a similar spectrum of variability between the theoretical and practical. But for the purposes of our discussion, we'll purposefully oversimplify.
I. The Academics
At nearly every university in the world, CS problems are solved by chalk and ink before they’re translated to code and bytes. Many problems will never even make it from pen and paper into a program. They exist purely in thought-stuff. That probably sounds backward for a discipline whose main responsibility is to engineer working programs, but it’s the way computers have been taught for decades.
The Academics are the purists, the theorists, the old guard. Many of their ranks prefer languages like C or FORTRAN. That is, if their programs ever make it into a computer at all. The prototypical Academic would rather tinker with algorithm run-times and finite state diagrams than ever prepare a program for commercial use. Most of their ideas end as prototypes and scraps on the lab floor, ever pushing toward the next journal publication or the next big advance.
Of course, the Academics are truly brilliant computer scientists. While any old programmer may understand how to write a loop, the Academic could give an hour long lecture on disassembly, program run-state, and registers. The Professional knows that ++i makes his program run faster, but the Academic feels spiritual satisfaction in using proper auto increment operations.
Is there merit to the claim that an Academic is woefully unqualified to teach programmers? There are certainly disadvantages:
- Academics are less concerned with software engineering issues than they are with theoretical/mathematical ones. Maintainability, quality testing, and design patterns are liable to fall by the wayside in favor of algorithms and data structures.
- For Academics whose research area is not strictly theoretical/mathematical, their area of expertise still centers around research and publication. Students are therefore trained to approach programming as a researched-based field.
And yet there are also certain advantages to having Academics teach computer science. Consider the following quote, a perennial citation for the teaching of theory in programming:
“[Computer science] is not really about computers — and it’s not about computers in the same sense that physics is not really about particle accelerators…Now the reason that we think computer science is about computers is pretty much the same reason that the Egyptians thought geometry was about surveying instruments: when some field is just getting started and you don’t really understand it very well, it’s very easy to confuse the essence of what you’re doing with the tools that you use.” – Hal Abelson (1986)
Abelson makes a good point in that Computer Science is really less about day-to-day tools than it is about core theory. And if teaching core theory is really the fundamental goal of a programming education, then there are several distinct advantages to keeping the Academics around.
- Programming languages and modern practices change freely, but core ideas stay the same over time. Academics master these core ideas beyond their implementation so that they can continue teaching them, no matter the language or architecture currently in vogue. To extend Abelson’s quote above, a good physicist would have little problem adapting to whatever technology replaces a telescope because the underlying ideas never change.
- Most practical daily skills of programming are experiential whereas theoretical knowledge can be taught in lecture.
- Correct, functional programs can still lead to disastrous results if the underlying models and functionality are not well understood. Programs won’t scale up and subtle bugs will stay hidden for longer times.
- Correct, functional programs may not be good enough to survive in a competitive market. Programs may work correctly, but use poor choices in data structures and algorithms that cause slowdowns or force users to work around undesired behavior. Programmers with strong theoretical backgrounds tend to detect these issues early on and can prevent/mitigate them.
Before moving on, it's important to point out that many professors who teach programming are not lifelong academics. Many have worked in the industry for several years either as researchers or engineers. Nowadays it's becoming difficult for universities to retain their brightest professors as they're lured away by Silicon Valley companies with deep pockets and an interest in advanced theoretical skills.
II. The Professionals
In the real world, nobody cares whether you know the run-time complexity of your program. They care whether it works properly and fast. Programmers work long hours, converting whiteboard diagrams and caffeine into programs and applications that are to be released into the wild (cautiously, in case it breaks).
The Professionals are engineers, pragmatic about their practice to the point of near pessimism. They expect their programs to fail and actively prepare mitigation for these failures. A Professional might prefer to improve the web app’s color schema rather than optimize runtime performance as long as that makes the customer happy. They learn the newest language and frameworks, eager to abstract and automate away the non-essentials of their craft. They build prototypes, yes, but also version 2.0 and version 3.0 and soon Version 95 and 97. They know how to build products that last.
Those who claim the Professionals are better suited to teaching programming have several strong points in their favor:
- Most theoretical knowledge without practical use tends to be filtered by years of industrial experience. Seasoned professionals have a better intuition of what is necessary learning material and what is not.
- Professionals are far more likely to know languages, frameworks, and techniques which will immediately transfer to on-the-job skills for graduates.
- CS students are far more likely to become software engineers than researchers.The skills that the Professionals lack are unlikely to be important for students post-graduation.
- Professionals have a better overall sense of how programming works in practice and can better simulate true experiences for fledgling coders – focusing on project management, debugging, development life cycles, code maintenance, etc.
And yet for all their advantages, the Professionals approach coding with a fundamentally different paradigm. This is contextualized with the following quote:
“We are all shaped by the tools we use, in particular: the formalisms we use shape our thinking habits, for better or for worse, and that means that we have to be very careful in the choice of what we learn and teach, for unlearning is not really possible.” – Edsger Dijkstra, 2000
Is it possible that the pragmatism of the Professionals can actually be detrimental to long-term development of students? Because their paradigm values speed and viability of implementation, there are disadvantages to having Professionals in the classroom.
- Surface-level understanding of deep fundamentals leads to subtle bugs and poor design.
- Pragmatic programming discourages reading original documentation and understanding true behavior of programs, preferring instead to search StackOverflow answers and quickly debug until all test cases pass and customers quit complaining.
- The culture of quick development and quick fixes encourages high-level abstractions that are limited in scope and self-sustaining. These abstractions often mask design deficiencies to extend the lifetime of some existing technology beyond its natural usefulness (see: most web front-end frameworks, Visual Basic for Applications, etc.).
It's not uncommon to hear comments like: "I learned more about programming in my first year working than I did in four years learning at school." While that may be true, equally important is the question, "How would that learning have been different without a four-year background?" Most of what we learn during our first year on the job absorbs so quickly because it's contextualized with knowledge of design patterns, data structures and other fundamental theory we learned at school.
III. Why do Academics teach?
So far I’ve touched on some basic advantages and disadvantages for both the academic and industrial side dominating the teaching experience. At this point in the discussion, it’s a fair point to ask about balance. Should universities employ both Academics and Professionals in the classroom?
In practice, this already happens at a large scale. Go to the CS faculty page of any major university and click through a few profiles. Chances are, more than 20% of professors either worked in the industry for 5+ years or continue to work for companies outside the school.
But is this the right balance? While it may be common to employ Academics with Professional backgrounds, it’s rare to see the opposite on full-time university staff. There are several reasons for this:
- For historic reasons, nearly all universities and colleges require a PhD of job applicants. It is extremely uncommon for schools to make exceptions to this requirement, and PhD students rarely pursue this degree with an intention to abandon research/academia thereafter.
- University departments gain funding both through tuition/donations of students, but also by way of science grants. Employing the very brightest lecturers is not a viable economic strategy, because it forfeits research dollars and costs the school academic prestige.
- Bright professional software engineers have little financial incentive to join university faculty. Their skills are more profitable in producing software than in teaching. This practice has recently flooded over into academia, leading to Silicon Valley corporations poaching staff from universities.
This article began by asking whether universities were adequately preparing students for jobs after graduation because they prefer Academics over Professionals. We have provided evidence that neither extreme is most beneficial. But is the current balance the correct one?
This question cannot be answered given the current incentives of universities. Until their primary financial motivator is the education of students and not the accumulation of research prestige/dollars, we cannot implement an optimal solution.