When I’m writing code, I usually learn the most when something goes wrong. It’s great to read through articles and tutorials about a technology or platform, but a surefire way to learn the subtleties and be forced to dive into the concepts behind something is to troubleshoot it. I recently had the opportunity to troubleshoot a memory issue on a Wordpress site. I’ve been developing Wordpress plugins and themes for 2 years now, but I’ve never had to actually learn what the autoload column of the wp_options table does until last week. I’m sure that every developer has had a similar experience when it comes to gaining a deeper understanding of a system through troubleshooting.
The problem with programming classes at large universities is that they’re often taught in classes of 50 students or more. This is great if all students are going to do is listen to the professor lecture - but just how valuable are lectures on CS topics today? I can pick any given programming language or platform, and in most cases after a quick google search I can be watching a lecture or screencast by the person who created it. Or at the very least, a leading expert. The value of a higher-education programing course is not delivered through lectures.
So what is the value in taking a programming course in college? Troubleshooting. More specifically, programming courses are valuable because they allow you to learn how to troubleshoot well. See, the cool thing about troubleshooting is that when you do it well, it teaches you not only how to get your program working - it actually can teach you how to program well in the first place. When you think about it, troubleshooting is really a term for problem solving. Well, programming is also just a special case of problem solving. If you learn to do one well, you’ll get better at the other too.
At Lewis & Clark, the small liberal arts school where I’m studying computer science now, programming class sizes are about 10-20 students. This means that when I run into a difficult problem with some code, I ask the professor for help. By doing this, I get to see not only the solution that my prof comes up with, but also the process that they use to arrive at that solution. That’s way more valuable than just googling the error message or problem and getting a few lines of code accompanied by a brief explanation of what they do - seeing the process involved in finding a solution allows me to identify where I went wrong in my original thinking, and adjust the way that I program to avoid that in the future. Most of the time, the prof will actually walk students through the process of fixing an error. If they’re a good programmer (which they ought to be, if they’re teaching), then this gives the whole class insight into how a skilled programmer thinks about code. This kind of interaction would be impossible in a class of 50+ students, like the ones at USC.
It’s easy to learn the mechanics of programming from screencasts and internet resources, and it’s possible to learn about the concepts and mechanics of a system by troubleshooting it on your own. But the best way to learn about the process of troubleshooting - and see a different way to think about programming - is to watch an expert do it, preferably on your code. That’s where the value lies in college courses on programming, and that’s why I’m happy to have switched from a top-level engineering school with big classes to a lesser-known liberal arts school with small ones.