What Is Missing From CS Education
We are currently onboarding fresh college grads and that got me thinking about what the good and bad about an education in CS or ECE is. Based on my learnings from my own education, my work as a TA, and in shepherding many engineers in their career.
Large Persistent Codebases
One of the most important learnings as a software developer that we don’t get enough of in school is working with large persistent codebases. For me it was a handful of courses that had persistent code. Usually this was with large projects. Credit given to my Data Structures professor for having us work with my first persistent code base in writing an adventure game. But as anyone that codes knows you’re a different person when you’re coding and a week after that when you’re reviewing your code. In school they teach about the virtues of commenting and writing clear code but you can’t appreciate this until you’ve had to reuse your code multiple times.
This has some implications for students. It does increase the difficulty of the work they have to do. But just like how we would expect an English literature paper to have correct spelling we should expect programming assignments to have good code. And the longevity of the code is one of the best metrics for what is good code. Another issue is it takes away a student’s ability to catch up if they fall behind. I remember my Compilers professor releasing solved code after the assignments so students can pick back up after a setback. Finally the complexity of the code does add more work for the student when the learning goal may have been different. And that brings us to my next point.
Real Developer Workflows
As code complexity increases your complexity increases. In the professional world we maintain control over this complexity by using good developer practices and workflows. The first of these is using source code management. And while I would like to claim this was more excusable in my day but now with the distributed nature of git and the accessibility of GitHub there is no defense for not using git. It does impose a few extra commands that beginners would have to learn but we want students to feel uncomfortable when they are writing code that is not under SCM. Also keep in mind this current generation of students has been living under version controlled Google Docs. So they expect the ability to lookup old versions of what they are writing.
But that’s just the tip of the iceberg. Why not have students make submissions through pull requests and have them see their submission be subjected to CI/CD pipelines. Provide test harnesses for test cases and instead of having them test their codes force them to include test cases in the provided test harness. The test cases themselves can also be graded in beginner classes.
One bonus of using pull requests and submitting history is it can be used as a second anti-cheat mechanism. If an assignment is suspicious you can check if the history makes sense for what you would expect from a student to naturally have versus from copying.
See Different Language Paradigms
Most programmers know that the number of programming languages you know is nothing to write home about. Yes, it sounds impressive until people know you can learn another in a week. But I believe something has to be said about learning . This one might be more of a case for people that took an ECE route like myself than CS majors. And with time many programs have replaced Java in their curricula with Python. The different paradigm and the flexibility of higher level languages allows different ways of thinking. For example, with Python having hash tables as a basic types makes you a lot more comfortable with understanding when to use them. Similarly list comprehensions, map, and reduce really allowed me to think more in parallel.
On this note there are other paradigms to make yourself familiar with. Moving away from imperative languages to functional or declarative languages. The different ways of thinking follow us through in different languages.
Get Comfortable With The CLI
I became more comfortable with the CLI with time. And as I did I realized more and more how powerful the CLI is for doing work. Nowadays I don’t do much programming but many times I find myself having to go to the CLI if I need to do a complex search, or make a large number of changes to files. But there is something even more powerful to having mastery over the CLI. The CLI is how you interface with your machine. When you obtain mastery over the CLI you are redefining your relationship with the machine. You are not someone that can program on it. Programming becomes the way you interface with machines.
Read The Docs
The phrase “Stand on the shoulders of giants” maybe more true about computing than other fields. To get anything done you need to use libraries, find the right tools for the job, see other people’s solutions. This aspect is somewhat contrary to the goal of college which is to teach a strong theoretical foundation. So I can understand why colleges make you implement a lot more things than you need to. But there is a very practical aspect of becoming comfortable reading technical docs. Learning how to design use-cases from specifications. Finding the right tool for the job.
One class I remember doing this a lot with was computer graphics. We had been taught the theory in class and we needed to implement it. And so we spent a lot of time reading OpenGL documentation. And looking back at my first C course, I have to wonder if we really learned anything by not being exposed to having to figure out how to use libraries.
So that’s a lot of complaining about how colleges teach. But I wanted to celebrate some of the more creative courses I’ve seen.
Linux Only Labs
In Illinois the engineering labs were Linux only. It definitely placed an extra learning curve on the freshmen. But by your four years in college you got comfortable with the command line.
Test Driven Design
This wasn’t in a class I took but was something one of the professors I really respect did in his data structures class. The projects were to be done in groups of 2. But he required one of the team members to be the designated developer and the other to be the tester. The tester had to provide a test plan and create the automated test suite the project would be run against.
Full-Class Project
This was a grad class that I had been told about. In it the whole class worked on a single processor design. It is something that would probably not have worked at the undergrad level or in a very large class. But it is an excellent way to familiarize yourself with all aspects of working together.
Solving A Real Problem
I took a class in GPGPU when Nvidia was first introducing CUDA. For our final project we solved problems that various research groups were interested in parallelizing. In fact we were fortunate enough to have Nvidia’s chief scientist a David Kirk co-teach that class. And I like to tell myself our presentation had some influence on Nvidia adding atomic increment to CUDA.
If you noticed a theme in this post it is very similar to my post “Should Education Be A Layered Cake”. Trying to balance the theoretical knowledge with practical knowledge. Now I understand that the goal of a CS education is not to make programmers. It is to build a solid theoretical understanding to advance the field. In this way a CS education differs from a programming bootcamp or most self-taught programmers. But I don’t see increasing the practical aspects a distraction from the goal. I see it as developing a deeper connection with your toolbox. Because the work we do is hard. The only way to execute well on it is if your toolbox is an extension of your creativity and not adding challenges of its own.
