Brian - July 16th, 2010 - Practical Computer Science
Computer Science programs generally don't train software engineers; they train a mix of quasi-mathematicians/engineers who happen to know programming languages. This is fine - there are skills learned here that software developers need to know to be effective and to really grok software systems, but there are a ton of essential points that are left as exercises for the student. As a result, a lot of graduates are left at a disadvantage.
I've thought about what is missing in regard to education, and I think a lot of it could be tackled by one focused course. I've talked about this topic before, but I stumbled on a blog post by ex-Emergent TD Shaun Kime that has me thinking about it again. I honestly only glossed over his post, so some of what I write here may be an inferior version of what he's already written, but I wanted to think it through originally without inadvertently yanking his ideas.
Anyway, here are some of the topics I think need coverage that don't get nearly enough:
(1) Debugging
Would you believe I didn't use a debugger competently until my last year of undergrad? Would you believe that I was actually lucky here - that a lot of my colleagues had graduated without ever properly using one? Would you believe it wasn't until working at Emergent some three years later that I learned of some of the more powerful features like data breakpoints and conditional breakpoints? I don't want to think about how many hours I wasted hunting down bugs through careful placement of print statements, and this could have been alleviated with an hour's introduction. Plus debuggers integrated into IDEs are the most useful tools in a developer's toolkit. Which leads me to my next item.
(2) IDEs
Too many universities stick strictly to a Linux command-line. Which is interesting, since I've never once been in a job where I worked primarily with the command-line. Visual Studio is one of the grandest developer tools in existence, and there wasn't a single WVU professor that talked about it. Or Eclipse. Or XCode. Or Codeblocks. Or anything. If I didn't develop heavily outside of school, I would've thought emacs was the only environment out there. And I would never get hired.
(3) Revision Control
Every project I write goes into a revision control repository of some kind - SVN or Perforce or whatever. Revision control tools are tools that every competent software company uses. And they aren't entirely trivial - there are topics like merging and branching and forking that generally require a little bit of hand-holding the first few times. They help more with larger projects, but I'm of the opinion every developer should adopt them for solo projects as well.
(4) Feature/Bug Tracking
Real companies don't have giant TODO lists scribbled on paper somewhere. They have databases that keeps track of too many things to fit on a tree's worth of paper - features that must be implemented, features that are on a wish list, bugs, burn rates, time estimates, etc, etc. These databases typically aren't hard to use, but they can be hard to setup and administer properly. At any rate, students should at least have an idea of what's out there.
(5) Profilers
This is where we start wandering outside the realm of "absolutely necessary" and into "you may go a while without touching this, but knowing about it would be very good." Profilers allow you to benchmark your system - to monitor your memory or CPU usage or allocation frequency or various other statistics - so you can find out where your code sucks and then fix it. They're used a lot during the development of real-time systems like, say, games. Or operating systems. Or user tools.
(6) Build Systems
When you wander outside the happy world of single-platform development, you start running into nightmares. How do you keep every platform up-to-date? How do you ensure that some series of tests fires every night to verify that your system is stable across each platform? How do you reconcile the differences between building for Linux or Windows or Mac? Well, there are tools out there to help.
(7) Basic Web Development
Everyone should know enough HTML and CSS to make a serviceable web page. Everyone should also know how to get web hosting, grab a domain, set up blogging system of some sort. Run some simple commands on a database (everyone need not be an SQL guru), install a Wiki. In a big company you may never use these skills, but if you decide to go solo you won't survive without them.
(8) Basic Scripting
One of the first things I learned in Tim Menzies's Open Source class - gawk is pretty awesome. One of the first things I witnessed at EA and Emergent - scripting languages find their way into a whoollleeee lotta stuff. One of the second things I witnessed - batch scripting systems can quickly become a nightmare. It comes down to this - scripting can save a lot of time (for tasks that it is well suited to). It can also become a tangled mess that, as a junior programmer, companies will love throwing your way. In both cases, it behooves you to actually know what you're doing.
(9) Team Communication Techniques
I nearly left this off the list. Things like message boards and wikis and mailing lists and Skype are second nature to most software people, so much so that setting them up is often instinctively the first thing we do for projects. But CS students aren't necessarily software people - not yet, anyway - and frequently students aren't used to working in groups larger than 4. Best to cover this base just in case.
Those last two statements are the primary impetus for a course like this. It's about exposing people to a wide variety of industry-utilized stuff; it's not about making people experts in anything but instead facilitating them to know where to look to solve problems and become experts as necessary.
The actual format of such a class is a topic for another post, but it would almost certainly be project based. Menzies's Open Source Software class (a graduate level class, mind you) hammered on almost everything in that list and required utilization via a term project, which worked fairly well, though it suffered some growing pains.
Hopped up on sugar and another post planned.
