Lessons from the College Days
I have two degrees (Bachelor’s and Master’s) in computer science, so it’s probably no surprise that I place a fairly high degree of value on the background that all of this course work provided. That being said, my experience was that you learn some pretty unfortunate ‘lessons’ in CS degree programs. To name some that I learned (and later had to unlearn):
- Writing readable code is for weaklings. Writing your entire loop logic inside the loop guard condition FTW!
- You get partial credit for non-running (or even non-compiling) code if you add a lot of vacuous comments.
- All programming projects can be wrapped up in a month or, in extreme cases, a semester.
- Source control is an important thing, theoretically, but it doesn’t solve any actual problem you have.
- There are no consequences to making an enormous mess of your code in the hour before your deadline as long as it hits the predefined benchmarks because you’ll never look at it again in your life.
- Performance and accuracy of results are all that matter.
- Staying up for 36 hours straight to wheeze across the finish line is how heroes get it done.
- All you need to deliver is a bunch of source code files that compile.
First of all, I’d like to point out that these aren’t things that a professor sat me down and said at any point and, in fact, if shown this list, they’d probably say, “those things aren’t good lessons.” But these were the lessons I learned by virtue of the incentives to which I was exposed and how I was rewarded or penalized for my actions. There’s a lot of room for improvement, but I’ll come back to that later.
The common theme that drives this list of less-than-awesome lessons learned is that the academic environment and the theory that it tends to teach lend themselves to non-representative situations, contrived for the purpose of teaching a specific lesson, such as how to implement Alpha-Beta pruning or how state machines work. The best ways to drive these points of instruction home don’t correspond with workaday dev concerns like “write me a web service that triggers a database update and keep it relevant when I change my mind every month or so.”
But one lesson that I did take away that has served me very well is, “do what’s necessary to get a D instead of an F, save that off for reference, and once that’s secured, go for the C, save, etc.” In a lot of classes, we’d submit coding assignments that would run against some kind of benchmark, and it was something like, “if you satisfy 60 of the 100 conditions you get a D, 70 of 100 and you get a C, etc.” And I learned that you mitigated a lot of risk by making it your top priority not to fail or get a 0, and then improving from there. This way, if the time ran out, you’d be less like an action hero trying to defuse a bomb before the timer goes off and more like a fussy dog show entrant trying to put a few last minute touches on your dog that would improve its chances of being judged better than the other dogs, whatever that entails.
This early lesson to which I was first exposed as an undergrad, around the time the Agile Manifesto was being written, was really the precursor to concepts like iterative development and thin-sliced, end-to-end goals for software. It taught me, through real, meaningful incentives, to make sure that I secured at least some value before chasing unicorns like an A+ off into the sunset. If there were 2 minutes left to submit the assignment, I wanted the backup plan to be an A- rather than a zero.
So what does any of this matter to you grizzled software veterans a decade or however long into your careers? Well, bear in mind that there’s always an A- (or B or C or whatever) out there when a bunch of work gets thrown your way. That web service you’re tasked with writing isn’t all or nothing. Not even a phone app that shows you the time is all or nothing (if push comes to shove, and app that tells you whether it’s AM or PM is better than nothing). Things can always be pared down and scope can always be adjusted, assuming you design towards modularity.
The overriding message of this post is that you should always, always, always look at the beginning for ways that you can secure yourself intermediate grades between 0 and A+ on the way to calling your software done; it’s the only reasonable way that you can manage expectations and adjust on the fly with a software project, apart from getting your customer to agree to indefinite delays. But, for a bit of fun, I’ll leave you with a series of ideas for how college CS curricula might better prepare students for actual development gigs. These might make you laugh to think about, but they’re actually things that could add some value:
- One assignment in every programming class starts you off not from scratch or from professor-written template code, but from whatever pile of mess some students turned in last semester (teaches you what an unkindness it is to make a mess in code)
- Every assignment requires students to update a single, shared text file whenever they’re testing against the benchmark and they get dinged if it gets out of sync (teaching about file contention and merge conflicts)
- There are one or more assignments during the course of the curriculum that simply cannot be totally completed (teaches students to prioritize while working against unrealistic parameters)
- There is some code that you carry over semester to semester and thus have to live with for years and/or there is a class where each assignment builds on the code of the last one but requires refactoring (teaches writing code with the idea of maintaining it)
- Lock kids out of the computer lab between 1 and 6 AM. (Teaches you that you’re going to work at places where juvenile heroics simply aren’t feasible for reasons ranging from the fact that this is a bad idea to the fact that the facility may be locked down at night)
- All homework/project submissions are real-world deliverables along the lines of an actual phone app, web app or MSI installer (teaches that there’s more to delivering software than writing code)
Deny students access to alcohol and other recreational substances from Monday to Friday. Give students an automatic deduction from their grade when they fail a random drug test that shows they over indulged on the previous Sunday.
I think the first part would be pretty hard, logistically, and the second part pretty expensive. But, it would definitely be more realistic, at least for students destined for large orgs rather than, say, startups.
Nice! How about also having at least one assignment where the specification changes midway between assigning it and the due date? Or a series of assignments where you have to complete the assignment but are told in advance that the next assignment will be the same but with some specification changes (which you won’t find out until the second assignment starts)?
Yeah, that’s definitely true — nothing in school prepares you for the “moving target” paradigm of being a developer in the work force.
And have only 10% of the time to do the second assignment, because you designed everything perfectly to accommodate those changes, right?
Nice, love it…
You didn’t really talk about teamwork. Of course that is hard in a class environment. My idea is that you (the teacher) secretly split the class into 2 to 4 groups. You give everybody the same assignment, but give each group different additional information. I can’t tell you how many times I find out the requirements for a project from my co-workers. Of course all of this extra information is verbal so there is no tracking any of it. This would be evil but a good lesson of things to come.
I like it. The discovered/emergent requirements thing is definitely something you encounter.
I like one one about having to live with your code for a few semesters, it would teach a lot about why you should comment your code and have clear names if nothing else. If you’re lucky, you can also get to upgrade your project to the latest and greatest version of your framework after a year or two, which breaks everything of course.
Exactly. Changing techs, long elapsed time periods, etc, are the kinds of headaches that are hidden by assignments 1-4 weeks in length.
How about forget college all together? Its great for people whose parents pick up the tab. For the rest of us starting our careers deeply in debt is not so great. I am seriously proposing a combination of online tutorials, stackoverflow, codereview.stackexchange, meetup coding groups, pair programming, internships, conferences etc. Could this replace a full CS degree? I am not the one to make that call. What I can say for sure is it is better than the web development degree at my local community college. One professor with 60 students can not provide the level of feedback you get… Read more »
I think that if any profession is ripe for breaking out of the “college as table stakes” mold, it’s programming. It’s already not strictly necessary to have a CS degree to get a lot of programming jobs and as tuition prices continue to soar, that seems likely to expand. But the other key factor is that there isn’t any kind of certification as a barrier to entry. Med students or law students can’t just skip college and go on to do what they do, but there’s no similar force stopping aspiring programmers. I’m not sure what exactly the replacement for… Read more »