What do new CS/IT grads lack (that I can add to a CS/IT program)?
February 24, 2016 8:33 PM
I've been tasked with designing a new course for students nearing the tail end of my college's (2-year) CS and CIS/IT curriculum. The goal is to incorporate skills/experience that are otherwise lacking in a vanilla CS and IT curriculum, and which would be useful for students who are aiming for employment or internship very shortly. We already have all the standard courses in basic programming and algorithms, data structures, pre-architecture, discrete math, networking, Unix-y scripting, some security topics, etc.
Off the top of my head, I'm envisioning something like a "DevOps" course, maybe with topics in:
If you have any advice, I'd be glad to hear it.
Off the top of my head, I'm envisioning something like a "DevOps" course, maybe with topics in:
- SCM (version control, release engineering)
- Key-value stores, caching
- Cloud services (computation, content delivery)
- Preparing for interview questions
If you have any advice, I'd be glad to hear it.
Does your curriculum have a writing course? Not a creative writing course or a humanities course that requires writing, but a course specifically detailing the mechanics of informing or persuading with the written word. Most devs spend a significant amount of time, sometimes a majority of their time, writing human languages, and some of them are terrible at it.
posted by d. z. wang at 9:02 PM on February 24, 2016
posted by d. z. wang at 9:02 PM on February 24, 2016
Thanks so far.
Lyn Never: Thanks. Those are good topics, but would probably be taught outside my department.
d.z. wang: Yes, that's an issue I've heard mentioned multiple times, and definitely something I noticed in previous jobs and as a student. I think most (if not all) 4-year programs require some sort of technical writing course in addition to general ed, but probably not a rhetoric course. I guess the exposure to rhetoric is usually through the general ed literature/philosophy courses.
posted by anarch at 9:35 PM on February 24, 2016
Lyn Never: Thanks. Those are good topics, but would probably be taught outside my department.
d.z. wang: Yes, that's an issue I've heard mentioned multiple times, and definitely something I noticed in previous jobs and as a student. I think most (if not all) 4-year programs require some sort of technical writing course in addition to general ed, but probably not a rhetoric course. I guess the exposure to rhetoric is usually through the general ed literature/philosophy courses.
posted by anarch at 9:35 PM on February 24, 2016
Might be hard to do in a single course, but I think it would be super useful to go from zero to an app deployed on AWS (or even Heroku), using git, one or two simple microservices and a frontend framework. In other words, direct exposure to the stuff you need to use to actually take a project from concept to reality. The actual app could be super simple; it's not about the functionality but about combining concepts and using tools. There's such a huge gap between knowing how to implement an algorithm and being able to launch a real product.
At least, I would have found that kind of thing incredibly helpful when I were in school (if we had AWS, git, microservices, or js frameworks back in the stone ages...).
posted by primethyme at 9:36 PM on February 24, 2016
At least, I would have found that kind of thing incredibly helpful when I were in school (if we had AWS, git, microservices, or js frameworks back in the stone ages...).
posted by primethyme at 9:36 PM on February 24, 2016
Thanks primethyme, that sounds like it would be very useful, and also pretty motivational for all.
I wish I had been exposed to something like that as well, had it been feasible at the time. ;-)
posted by anarch at 9:42 PM on February 24, 2016
I wish I had been exposed to something like that as well, had it been feasible at the time. ;-)
posted by anarch at 9:42 PM on February 24, 2016
You mention version control as an example. Is that not core curriculum? The handful of recent grads that have joined my team have known it well, but perhaps that reflects the fact that we would simply not hire someone without some familiarity there.
I'm not sure how easy it is to teach as much as something you need "real-world" experience with, but an issue I've seen with newer hires is writing code that probably works well in isolation, but that would never work at scale. You write code that does a full table scan of our production database on every page load, and you understand indexes and table scans academically, but you say it worked fine on your laptop in your test environment with 4 rows and seem surprised that it's blowing up in production. To me this really isn't about understanding the academics of it: "which data structure is more memory-efficient" is very different from, "That table is 50 million rows. Don't you dare run 'SELECT *' on it, ever." Similarly, it's not problems unique to Facebook or Google; it's every company I've ever worked at that has some excessively-bloated database table, or that 40GB data file, which trips up new developers who only ever had to write SELECT * FROM table or File.open.
And a bit +1 to what primethyme just said. I'd tremendously prefer a candidate who's built stuff, even just for fun, on platforms and connected the dots end-to-end. It's a whole different set of issues, and it'll also look great on your resume. (And don't forget about the GitHub Student Pack, which is a ridiculously good deal that came out after I graduated, which I'm still a little bitter about.)
posted by fogster at 9:56 PM on February 24, 2016
I'm not sure how easy it is to teach as much as something you need "real-world" experience with, but an issue I've seen with newer hires is writing code that probably works well in isolation, but that would never work at scale. You write code that does a full table scan of our production database on every page load, and you understand indexes and table scans academically, but you say it worked fine on your laptop in your test environment with 4 rows and seem surprised that it's blowing up in production. To me this really isn't about understanding the academics of it: "which data structure is more memory-efficient" is very different from, "That table is 50 million rows. Don't you dare run 'SELECT *' on it, ever." Similarly, it's not problems unique to Facebook or Google; it's every company I've ever worked at that has some excessively-bloated database table, or that 40GB data file, which trips up new developers who only ever had to write SELECT * FROM table or File.open.
And a bit +1 to what primethyme just said. I'd tremendously prefer a candidate who's built stuff, even just for fun, on platforms and connected the dots end-to-end. It's a whole different set of issues, and it'll also look great on your resume. (And don't forget about the GitHub Student Pack, which is a ridiculously good deal that came out after I graduated, which I'm still a little bitter about.)
posted by fogster at 9:56 PM on February 24, 2016
Other items they might consider:
Refactoring code (take X, and do Y with it)
Analytics, A/B testing
UI / UX information display like Edward Tufte
As part of SCM, also doing code reviews, error analysis, core dump autopsies from stack traces.
posted by nickggully at 10:22 PM on February 24, 2016
Refactoring code (take X, and do Y with it)
Analytics, A/B testing
UI / UX information display like Edward Tufte
As part of SCM, also doing code reviews, error analysis, core dump autopsies from stack traces.
posted by nickggully at 10:22 PM on February 24, 2016
Do your students get a basic grounding in operations? I mean stuff like, how filesystems work, authN/authZ and how they differ, intro to backup and restore, why closing off unused network ports is a good idea, baremetal vs virt vs chroots vs containers and when you should (or should not) care, why backups and rollbacks are important even if you think CM is stupid or your change is tiny and unimportant, proper care and feeding of log files, how to troubleshoot complex systems you didn't build, how to handle your panic in the moment that prod broke, when to fail fast or fail safe instead of endlessly trying to handle errors? If you're talking DevOps, don't neglect the Ops part. That's the part that turns you from a code monkey into a superhero.
Added bonus: If I had a dollar for every developer I've ever had to tell that no, putting a few thousand data files in a single directory is a bad idea, then waited for thousands to grow to hundreds of thousands, then go back after things start breaking, clean it up, and say "now, will you refactor that?"... I'd give all those dollars to you if you stopped me from having to teach that lesson. Seriously, that one single thing, I am not even joking. "But modern filesystems" me no "but modern filesystems," that crappy shell script you didn't bother to put error checking into is still going to eventually break, and then I will be Captain Picard Facepalming forever.
posted by sldownard at 10:43 PM on February 24, 2016
Added bonus: If I had a dollar for every developer I've ever had to tell that no, putting a few thousand data files in a single directory is a bad idea, then waited for thousands to grow to hundreds of thousands, then go back after things start breaking, clean it up, and say "now, will you refactor that?"... I'd give all those dollars to you if you stopped me from having to teach that lesson. Seriously, that one single thing, I am not even joking. "But modern filesystems" me no "but modern filesystems," that crappy shell script you didn't bother to put error checking into is still going to eventually break, and then I will be Captain Picard Facepalming forever.
posted by sldownard at 10:43 PM on February 24, 2016
Unit tests. Please teach them how to write unit tests. What they are, how they prevent regression, line and branch coverage. Having unit tests is the difference between engineering and hacking.
posted by Mrs. Davros at 10:54 PM on February 24, 2016
posted by Mrs. Davros at 10:54 PM on February 24, 2016
A lot of good suggestions already.
For soon-to-be graduates, I think a lesson or two (and maybe a few references for additional reading) on coding style and etiquette will go a long way during interviews and be immediately useful in collaborative environments. Just practical stuff like:
- writing comment blocks for doc generation
- is this bit non-obvious? leave a comment
- variable and method names are important and useful
- conforming to a style guide (K&R, pep8, etc)
- considering the next person that has to maintain your code
posted by slagheap at 11:36 PM on February 24, 2016
For soon-to-be graduates, I think a lesson or two (and maybe a few references for additional reading) on coding style and etiquette will go a long way during interviews and be immediately useful in collaborative environments. Just practical stuff like:
- writing comment blocks for doc generation
- is this bit non-obvious? leave a comment
- variable and method names are important and useful
- conforming to a style guide (K&R, pep8, etc)
- considering the next person that has to maintain your code
posted by slagheap at 11:36 PM on February 24, 2016
Oh god yes, unit tests like Mrs. D said - also continuous integration while you're at it.
posted by Calloused_Foot at 12:25 AM on February 25, 2016
posted by Calloused_Foot at 12:25 AM on February 25, 2016
Seconding unit tests. This could easily be integrated with other lessons – basic performance test for SELECT * on a tiny table versus the same on a huge table; how to write an automated script to test their code (though it might be a bit much, since automated testing shouldn't be an automatic choice, ROI is important, but unit tests are pretty well-suited to it), version control and writing.
How do version control and writing go along with testing? Easy exercise: get students to write the unit tests for code they haven't written. Then have yet another student run the tests. Watch as epiphanies occur. Use them as teaching moments.
posted by fraula at 4:01 AM on February 25, 2016
How do version control and writing go along with testing? Easy exercise: get students to write the unit tests for code they haven't written. Then have yet another student run the tests. Watch as epiphanies occur. Use them as teaching moments.
posted by fraula at 4:01 AM on February 25, 2016
This question just came up in a discussion group I'm in. Literature review was identified as a big gap in CS education. Coders love coding, bit it's often the case that what you're doing has been done, or tried and discarded. Good lit review practice, knowing how to search for past approaches to a problem, and how to read other people's code is hugely important in professional work.
posted by migurski at 5:07 AM on February 25, 2016
posted by migurski at 5:07 AM on February 25, 2016
Product development process. Agile, for instance. What will the organization look like that they are likely to get dropped into at their first job. How does a product management team come up with requirements? How do those get converted to coding tasks, etc?
posted by chiefthe at 6:05 AM on February 25, 2016
posted by chiefthe at 6:05 AM on February 25, 2016
gotta second the chief here .. Understanding requirements and how they translate in to work. With a close follow up on unit tests : how the requirements tested ?
posted by k5.user at 6:34 AM on February 25, 2016
posted by k5.user at 6:34 AM on February 25, 2016
Add a course on problem solving and creative thinking. In my opinion too many CS grads are coming out as programmers proficient in a few languages but unable to quickly transition to other languages they have not yet learned. The best CS folks I know can switch languages like a pair of shoes. You want to actually teach the students to think like a computer scientist...they need to know the why and not just the how. Beyond this, troubleshooting, bug finding, picking up 30 year old code written in fortran all need the ability to think broadly about a problem.
This is what separates the average from the great in almost all fields and often is not taught well in an undergraduate degree...
posted by NoDef at 6:56 AM on February 25, 2016
This is what separates the average from the great in almost all fields and often is not taught well in an undergraduate degree...
posted by NoDef at 6:56 AM on February 25, 2016
I would love to see a "communication" aspect added to the IT curriculum that could cover technical writing, proper documentation practices, and also a module for practicing how to talk about complex ideas and systems with non-experts. Some of the biggest problems I've seen in IT departments are caused by IT folks (including myself) thinking and talking about technology at a level that's inappropriate for the current audience. You mentioned above that "the exposure to rhetoric is usually through the general ed literature/philosophy courses," but the kind of codeswitching that IT professionals need to be fluent in is very different than either of those things.
posted by zebra at 8:53 AM on February 25, 2016
posted by zebra at 8:53 AM on February 25, 2016
A lot of the ideas that you are getting could be packaged into a course called something like "Technology in a Business Environment". Each week cover a different topic at an overview level.
In the real world, we don't really need our new grads to be proficient at each of these topics, especially since every shop may do things slightly differently, but it would be nice if they've been exposed to the issues and have some tools in their belt that they could choose from to help resolve them.
For my shop, I would love to have more tech folks able to do presentations at the correct level for the audience, and able to write design documents that are more than just code snippets pasted into Word.
posted by CathyG at 9:15 AM on February 25, 2016
In the real world, we don't really need our new grads to be proficient at each of these topics, especially since every shop may do things slightly differently, but it would be nice if they've been exposed to the issues and have some tools in their belt that they could choose from to help resolve them.
For my shop, I would love to have more tech folks able to do presentations at the correct level for the audience, and able to write design documents that are more than just code snippets pasted into Word.
posted by CathyG at 9:15 AM on February 25, 2016
Not sure how you would teach these but here is a list of important skills grads should have:
An understanding of how important IT is to today's businesses. If a system is not working the company is losing money sometime a lot of money.
Methodical systematic troubleshooting. Don't look at your small piece of the puzzle, everything is interconnected. Because a problem is showing up in one place does not mean the cause is there.
How to interact and communicate people especially those that are not technical.
End to end quality assurance and testing
posted by tman99 at 11:04 AM on February 25, 2016
An understanding of how important IT is to today's businesses. If a system is not working the company is losing money sometime a lot of money.
Methodical systematic troubleshooting. Don't look at your small piece of the puzzle, everything is interconnected. Because a problem is showing up in one place does not mean the cause is there.
How to interact and communicate people especially those that are not technical.
End to end quality assurance and testing
posted by tman99 at 11:04 AM on February 25, 2016
Project management, business analysis, how to do requirements gathering, writing for a non-technical audence, how to run a training class.
IME, it's not uncommon for us devs to get a project with no, or no competent PM, no business analyst, and to wind up at then being told "Oh hey, I need you to give a rundown on how to use this to group X". Or for someone to blame the dev team when a feature that was never mentioned isn't in the product.
Just because it's not your job, doesn't mean you won't have to fill in the gaps.
posted by mrgoat at 11:43 AM on February 25, 2016
IME, it's not uncommon for us devs to get a project with no, or no competent PM, no business analyst, and to wind up at then being told "Oh hey, I need you to give a rundown on how to use this to group X". Or for someone to blame the dev team when a feature that was never mentioned isn't in the product.
Just because it's not your job, doesn't mean you won't have to fill in the gaps.
posted by mrgoat at 11:43 AM on February 25, 2016
i have done this as part of a comparative web application senior/grad level class with another instructor (note: both of us were in the it department and our boss was the official teacher). a couple of things that ended up being successful were having them set up the entire lamp stack on a provided virtual server, including a self-signed cert and deploying a very simple app there. we also had a recurring theme talking about software patterns. there was an explicit goal not just to describe the pattern used, but to emphasize that it was only a pattern and might be a good solution or might not. this was at the height of the ruby on rails craze, and we thought some inoculation against cargo cult thinking would be helpful. i later spoke with some of the students and they mentioned both of these activities as being useful when they started real world interviews.
there were several that had not used version control. also the nature of the class allowed for some interesting tooling discussions as eclipse, visual studio, and vim were all used.
posted by lescour at 2:16 PM on February 25, 2016
there were several that had not used version control. also the nature of the class allowed for some interesting tooling discussions as eclipse, visual studio, and vim were all used.
posted by lescour at 2:16 PM on February 25, 2016
I'd spend at least some time getting them comfortable with open source.
Also, seconding the suggestions of version control, unit tests, project management. And adding: Do they know how to use a debugger?
posted by vasi at 8:32 PM on February 25, 2016
- Where should they look for tools/libraries that may already exist, instead of re-inventing the wheel? In school they often had to implement everything themselves to prove they know how, but they shouldn't keep that up.
- Once they find something, how can they install it? The existence of package managers would be a great start (apt-get, rubygems, NuGet).
- As a follow-up, what if they have to build software? At least a practical introduction to how build systems work.
- When can they use a library they find? Basic familiarity with licenses, so nobody gets in trouble with legal.
- What if something doesn't work the way they want? Filing good bug reports is important, and surprisingly difficult.
- How can they participate in an open source project? The more technical parts (version control, writing docs, writing code, writing tests), but also the more interpersonal ones (what's a style guide? where do I discuss things? where do I submit contributions? how do I do this without pissing people off?)
Also, seconding the suggestions of version control, unit tests, project management. And adding: Do they know how to use a debugger?
posted by vasi at 8:32 PM on February 25, 2016
How to contribute to a free software project. You might've heard of classes that assign students to edit Wikipedia. Think the software version of that.
posted by brett at 8:37 PM on February 25, 2016
- How to diagnose a bug or other unexpected behavior ("OK, I got this error message, now what?")—more generally, giving them the opportunity to read and make sense of other people's code
- How to write a bug report
- How to submit a patch—yes, the details of where and how to send it vary a lot, but some basic principles are almost universal: make sure your patch applies to recent code, strive to make your patch as small as possible, include rationale and discuss any trade-offs in your code, etc.
- Throughout this, demonstrate how a VCS helps: logs and annotations can help explain when and why an apparently buggy change was made, and that information can help make a more compelling bug report. It can help you make your patch, review it, and maybe even submit it.
posted by brett at 8:37 PM on February 25, 2016
This thread is closed to new comments.
posted by Lyn Never at 8:54 PM on February 24, 2016