What we should be teaching in CS

I’m really not going to argue specifics here.  I’m not going to say, use this language or that language or start with objects or don’t start with objects.  I think valid arguments can be made for any of those things.  But I had an interesting conversation with a senior on Friday, who interned in a CS-oriented lab.  And she groused a bit about how much she didn’t know about computing.  And she meant computing writ large, not programming per se, which she ultimately sounded pretty comfortable with.

She was thrown by things like the file structure of her computer, terminal and unix commands, other IDEs besides the one we used, the idea of libraries and modules, and APIs.  I touch on all these things, but I don’t go into much detail.  I asked my student if she thought I should put some of these things in CS I or wait until CS II.  I explained how I didn’t want to overwhelm students too much.  She hemmed a bit, but we both came around to the idea that yes, these things should be included sometime in the first year of CS.

I forget that most students don’t understand what a path is, what those folders in the Finder or Explorer window really mean and don’t know at all how to interact with their computer via command line.  I had my CS I students read In the Beginning…Was the Command Line but I didn’t follow that up with any activities to show what the command line is.  I have done this with Middle School, but clearly I need to do this with older kids as well.

Computing is big.  There’s a lot to it and a lot of different directions to go in.  In my whole program, I try to cover a lot of those directions, from working at the hardware level (via Arudino) to programming robots, creating graphics, manipulating images, making games, and even web programming.  Any one of those areas can involve knowing different kinds of things.  File systems are hugely important to web development, but less so when working with Arduinos or robots.  Math is extraordinarily important with working with data, graphics, and games, but not always with web programming or robots.  And I allow a lot of flexibility for my students.  They can pursue whatever area they want through their projects.

So what’s the baseline? Where do we start and how far do we need to go? What are the basic building blocks we need to insure our students can build further?  And will those blocks change over time? One of the problems facing HS teachers is that colleges right now have no expectation that students have had CS before enrolling in an intro class.  But I suspect they do have expectations for the students they expect to succeed.  Whether this is fair or not is another question, but I suspect it’s true that professors have a baseline.  I’d guess at some of the following:

  1. The ability to install software in specific locations on your computer, even if those locations are “hidden”.
  2. The ability to use an IDE, probably multiple.
  3. The ability to use several different operating systems including a flavor of Linux.
  4. Some basic commands like ls and cd
  5. The ability to understand file name endings like .py, .js, .csv, .c
  6. To know what a path is and how to find a full path name.

There’s probably more, but basically, I’d say most CS profs expect their students to know the inner workings of their computer and perhaps the internet relatively well.  Because they’re curious about these things and they want to know more.  Otherwise, they wouldn’t be in the class.  But for many students, they might not be curious or have had any reason to be curious.  Double-clicking on an icon is just fine with them, thank you very much.

So I’m going to find a way to put this baseline into the course.  We take apart the physical computers early on.  Now, I think we need to take apart the virtual computer and find out more about how it ticks.  I think I’ve taken for granted either that students will learn these things on their own or that they already know them.  Not anymore.

Enhanced by Zemanta

14 Replies to “What we should be teaching in CS”

  1. Fascinating. I have been coming at some of these questions from a different point of view. My 8th grade history class does presentations on the 1950s, 1960s, 1970s, and 1980s, and this year I had them include a short section on computer technology of the decade. I realized, reading their drafts, and listening to their presentations, that they did not have a vocabulary to talk about the history of technological change generally, and computer history more specifically. That is one of the things I want to re-think this summer. I will be adding a history of tools generally to the course, which I hope will help scaffold some computer history for the end of the year. And some of the things you are talking about as essential for CS are also essential for computer history. Much to think about.

  2. I have to teach some of this stuff now in my stats classes… they need to be able to find files, decide where to save files, and to use the command-line interface for STATA.

  3. Heather, I do a history of computing at the beginning, and I think I thought they were learning some of these things through that. And the vocabulary is kind of important, too. I think I’m going to include more on my quizzes and exams.

  4. This is largely why we purposely don’t use IDEs in CS1 or CS2—we use a text editor + the command line. We want them to get used to the command line, to a basic understanding of file and directory structure, etc. This has its pros and cons—students don’t use an IDE until Software Design, for instance.

  5. This is largely why we purposely don’t use IDEs in CS1 or CS2—we use a text editor + the command line. We want them to get used to the command line, to a basic understanding of file and directory structure, etc.

    I wish more CS classes had that attitude. Last year, I found that half my class of senior engineering students didn’t know how to get to a command line on their computers (despite having had programming classes). They had never run any program except by clicking on it.

  6. I really think that we need to do a revisit on CS standards for K12. The CSTA has a document which is a start but I think it could be improved. Having been on the ACM/IEEE CS 2013 task force that looked at undergraduate CS curriculum I think that is a model we could look at for developing K12 standards. It’s something I want to suggest to the CSTA board at some point. Like this summer.

  7. Amy, I use an IDE designed specifically for teaching and there are a lot of modules included that make it possible for students to do some great things. But I do think I need to step back at some point and let them see the bigger picture and get under the hood more.

    Alfred, I’m with you on that. I’ve relied on CSTA’s curriculum materials a lot, but I’m finding that students are coming in with different skills. They really need to understand computing as an interconnected system, which means they need to know its working parts.

  8. There is just so much “stuff” to teach with computers. I dabble with hardware in my programming classes. How to make patch cables, how to build a little network with switches, what a router is and IP addresses and odds and ends like that so they have a little info on non-software topics that might be useful in real life.

    As for IDE vs cmd line. If I use cmd line then the kids do not learn an IDE, if I use an IDE then they do not learn cmd line. I do think the kids need to learn to use the cmd line but it is like a whole lot of CS topics out there, only so much time.

    File structure is definitely getting left out in the cold. As the IT guy I have kids coming into my office all the time asking me to find a file they saved. “Where did you save it”, I ask. “I hit the save button” they reply with absolutely no idea what the save button does. There are a lot of things like this we assume they know that they do not have a clue about. We almost need a course titled “Here is how your gadget works”.

    Finding that baseline is going to be interesting.

  9. Garth, and “real world” uses differ depending on where you end up. Software engineering uses a variety of tools, some of them proprietary. Web development also has a variety of setups, but that’s where I’ve used linux commands the most, but that’s because I’ve always worked in LAMP environments. And then there’s things like GIT. We don’t teach calculus in 1st grade, so we can’t teach everything. And who knows what tools will be around in the years to come.

  10. On the topic of save buttons: ‘I have kids coming into my office all the time asking me to find a file they saved. “Where did you save it”, I ask. “I hit the save button” they reply with absolutely no idea what the save button does.’

    I often have to do a search after having done a “save”, because the program has remembered some directory I was using weeks ago, which has nothing to do with the project I’m currently working on. Persistent memory in modern applications has probably cost me more time than it has saved—I long for the days when I could start a program and know that I was starting with a clean slate, not a pre-wedged program.

  11. I think that teaching students the command line is more important than teaching them to use card readers but not by a lot. At least in K8 I don’t see any value. In high school maybe in a systems or networking course but not for programming.

  12. To comment on the cmd line programming I would have to see it in action. The few times I have done it, it was easier to learn and teach with an IDE. Cmd line just seems a bit antiquated for programming. I would definitely want the kids to know it exists for programming but it would be more of a show and tell. Again, I would have to see it in use to really understand why to use it.

    This thread is very interesting. What should kids know about tech/computers/programming/networking/etc when they come out of high school? Could a list be made? Is it possible to make a K-12 list and get it broken down by years or blocks of years? Computer tech changes so rapidly could a list be made with any life span? At the head of any list I would make would be “1. Know how to use Google.” Linux? I can spell Linux but that is about it. Google can educate me about it and show me how to build a Linux computer.

  13. I would say that I wouldn’t teach much command line stuff except maybe navigation via command line, copying, unzipping, and changing permissions (chmod is one of my very favorite things!). But perhaps use a text editor like emacs or pico to write programs just to get a feel for it. At an advanced level, I think it’s good to at least expose students to different programming environments, just so they know that what they’re using in school might not be the be-all, end-all.

    CSTA does have such lists. The problem, of course, is much of the lower level stuff we’re talking about: where files go, file extensions, ip addresses, etc. are placed prior to 9th grade (as I recall). If your school doesn’t start CS until 9th grade (or later), cramming in some of those things may not be what you want to do, especially if you want to get to the programming stuff–the fun stuff. So, catch-22 in a way.

  14. One of the important things about the command line (and general tools vs an IDE) is that it teaches a different way of thinking about problem solving.

    We expose our kids to basic Linux commands and while we use IDEs in our intro class (for NetLogo and Racket) once we get to the AP class, they’re in the shell and using emacs. By the time they’re in the senior classes, we try to emphasize the idea of really knowing how to leverage your tool set – be it emacs, vim, the shell or whatever.

    I don’t force the kids to do much with the shell, but I try to model what you can do — I find myself using sed, grep, regular expressions and the like all the time to scratch an itch that would be much harder than without using the shell as glue. Likewise with emacs.

    Over time, the kids see what can be done and some of them, when they have an itch think about scratching it with a few lines in the shell or an editor macro or whatever.

Comments are closed.