How to teach computer science? [closed]

Question

I am just starting to teach computer science. It's just the basic level. I'm finding that I sometimes don't know how to approach topics in a way that lets students easily understand.

I've found that the best thing is to use analogies. A terrible one, that worked well, was presenting recursion by using the process of eating a burger. (You eat one bite, then you eat the rest). Interesting real world examples do wonders here.

I'd like to know the techniques you have used for teaching, or teachers you've had have used that proved particularly effective. I'd also like to know your best analogies and examples for topics in CS101, especially for those harder to grasp topics.

I'm teaching the class in Java (as required).

Answer 1

So this is my 2 cents. I used to teach at a private institute but I was pretty young then. Although I had great success.

I got most of my ideas from this book: Accelerated C++

Why is it different? It focuses on why you do stuff. Instead of saying:

"Loops : Its this thing in programming to repeat control-flow..blah blah"

it says

"oh hey, we need to print this line a 100 times, what do we do? Oh we use this thing called loops"

So you go from problem to solution, people figure out why you're doing what you're doing.

It becomes very useful while understanding OOP too, I had students write a procedural, console app in C (a student grade management program) and then slowly convert/port it into C# with object oriented programming. Again, this way they learnt Why you need OOP. Why is it useful.

Other than that I second Chris, like math you need practice.

What I would do is make it as real world as possible, so for a Microsoft Frontpage class I taught, I walked my students through making a simple website of their choice. Over the week each student created something different and they were pretty excited because I told them I would host it online once its done.

Lastly I just generally think you have to love CS to really understand it, its a difficult life being a programmer, code you write is never correct the first time, you debug 80% of the time, the playground keeps changing with technologies evolving like crazy (Moores Law) Unless you LOVE it, you won't do to well.

(I generally started a class with that speech)

NOTE: I never taught any hardcore college level CS. I basically taught programming languages like C,C++\ C#, asp.net etc. And Applied Object Oriented Programming.

Answer 2

You are dealing with two completely different disciplines here: Computer science, which you have sufficient expertise in to be asked to teach it, and Teaching which is another matter entirely.

Assuming you're working in a university environment, why not ask your favourite lecturers how they approach teaching. Not in terms of what they teach, but how they design and structure a lecture, what they do to engage the students attention and so on. Most people will be happy to take a little time out to talk this through with you if you're interested and wanting to do a good job.

There is a lot of science on how people learn and remember. By studying that you can gain a lot of ideas for ways of making sure your students get what they need from your course. If your university has a department that actually covers education ( I don't know how other countries work but here in the UK a lot of universities also offer postgraduate teaching qualifications ) then you may be able to find someone who can recommend some current state of the science reading but even without that there are probably useful things you can find with a bit of research.

Here are a few things I found really helped me when I was a student, I guess they wouldn't be the same for everyone but...

• Use jokes and anecdotes - if you can tell a relevant story people will remember things better.
• Ask questions of your students during lectures. Get them to put forward suggestions. Be careful that you don't do anything to put people off answering so unless someone gives a deliberately flippant answer, listen and if there are problems with the suggested solution see if you can lead the student to find those problems themselves. If they do give a flippant answer then great! They are probably enjoying the class and feel relaxed and involved enough to do that. That is a good sign.
• If something is necessarily dry, double check that students have followed it. Make a point of asking people to ask if they don't understand something. If necessary even threaten people "I'm going to ask you some questions on this in a moment so if you don't understand it, let me know now and we'll make sure you're clear on it..."
• If you have homework assignments or projects be really firm about students keeping to deadlines. There will probably be a deparment rule on this anyways, but if you are in doubt err on the side of firmness. When I was a student I found hard deadlines really helped me to get work done on time. If there was a way they could slip I would slip them then suddenly have five large projects to do at once and then I had a real problem. Now I know that is just an admission that I was a bad student, but loads of students are bad students.

Another thought I would have about this type of teaching would be to think of ways of making it a bit silly but also memorable. So if I was teaching something like sorting algorithms, I might want to do the lecture outside and actually line up a chunk of the class and get them to sort themselves by name, then to go through some of the classic sorting algorithms to show how they work and which ones would hold. It would be a very unusual lecture but I would put money on that information being retained by the students. You couldn't do this for everything, but look for places where you could make it different and involving.

Also you will know what you need to cover in the next lecture, so why not set a relevant quiz or problem at the end of a lecture to see what students come up with at the start of the next lecture. Ideally a non-computing problem that leads to a programming solution.

Answer 3

I think it depends on the subject, each subject has a better way to be exposed. I would give you some hints as a student (I still preparing myself to teach): 1- Make the students participate the class, ask, give their opinions, presents their solution (before you say how it is done, ask them how they would do), make them feel they are constructing the class with you 2- Make jokes, make them laugh. This will make your class "lighter" and a pleasure experience. 3- As you have already said, use analogies/metaphors. But look for strange/unpredictable ones. Surprising the student with an unexpected (but still meaningful) metaphor will make the content "glue" better in their minds. They will remember the metaphor because it was surprising, and with the metaphor they will remember the message you are trying to pass to them :)

Good luck!

Answer 4

I taught CS at a state university for many years. After I retired, I realized something that I should have taken into account all those years: students learn in different ways. For example (although I didn't know it at the time) apparently I cannot learn very well by listening (using the auditory sensory channel), but I can learn effectively through reading or seeing a picture (using the visual sensory channel). Out of necessity, I developed a strategy for handling that problem - I took excellent notes. By the end of my PhD coursework, I could almost take dictation in longhand, not really remembering what the lecturer said from minute to minute, but getting it down on paper, to which I could refer later. Fellow students would often ask to copy my notes.

Despite my personal experience, I taught most of my classes by lecture, which was probably not the dominant learning modality of a good percentage of my students. Fortunately, I always generated a fairly complete set of lecture notes and made them accessible to the students. Still, I probably would have done better by trying to incorporate the use of as many learning modalities as possible. Some students learn best via social interaction, so small group work might have been an effective way for those students to learn. My youngest son evidently learned kinetically, needing to move his body to internalize the information he was processing - learning to count by using his fingers, for example. (Fortunately, his grammar school teachers recognized this and accommodated his learning style, instead of just labeling him "fidgety.")

A lot of the recommendations I have read here are good ones: getting the students to answer questions aloud in class probably helps the social learners; having the students physically act out a sorting routine probably helps the kinetic learners; and so on. I guess it all boils down to accommodating your students' diverse learning styles. I wish I had done more of this during my teaching career.

Answer 5

I taught undergraduate CS (actually just programming) for 4 years. It took me 1 or 2 semesters to get the hang of it.

The first thing I learned was that what I thought was unbelievably simple was not simple to the students, because they did not have the mental framework in place. It was my job to put that framework in place.

I don't care for analogies like sandwiches. They're cute, but they don't build the framework. Instead, I started with real simple machines:

• I had built a homebrew computer based on an Intel 8008 chip and programmed it to play a little duet on a couple speakers. I could slip one lead of a little capacitor under a wire attached to the timer chip, and when that was in place, it would run about 1000 times slower than normal. I would explain how the program was counting down a number, and then clicking a speaker, and starting over, and how if you click the speaker fast enough, it sounds like a note. Then I would run it in slow mode and you could hear the click-click-click. Then I would unhook the capacitor and it would burst forth with the tune.

I'm trying to get across the idea that computers only do simple things and one at a time. It's just their speed that makes them appear to do complicated things. This is because students tend to think since computers are so fast, they must be doing everything at once, and not only that, reading your mind in the process.

• I built a simple interpreter program for a decimal computer. It could hold 4-digit decimal numbers in addresses from 000 up to 999. It had an accumulator register and simple opcodes like load, store, add, jump, conditional jump, etc. The students could enter a simple "machine language" program into it, and single-step it, watching what it was doing. They could hold down the "enter" key and make it run "fast". I had them do very simple little programs with this - from adding some numbers up to totalling an array.

What this does is get across the ideas of what memory is, how instructions are just numbers in memory, how the contents of a memory location and its address are not the same thing, and how there is a distinction between the time at which you program the computer and the time at which it executes. This is what I mean by the mental framework. So if I say later that a variable is just a name for a memory location that can hold a number, they actually know what I mean.

Having done that for a couple weeks, then I could get into the regular programming sequence of conquering mental speedbumps. I would build enough basic skills so that they could do a reasonable project. Basically, it's a really boring subject unless you have something that you personally want to accomplish with it. So I would try to get them going on projects of their own choosing after about 6 weeks into the course.

Answer 6

Years ago when I was formally introduced to programming, a PB & J sandwich was the subject of many concepts. You can learn a lot from a sandwich! The abbreviated form...

• Planning: do I really want a PB & J sandwich? Are there enough ingredients? Am I skilled enough to build it myself, or will I need help?
• Design: White or wheat, or something less common? Is the J jam or jelly? Would a particular brand offer a better experience?
• Sequencing/Parallelism: Locate and collect peanut butter, desired J, and bread. Hold PB jar in one hand, and at the same time twist the lid off with the other. Ad nauseam.
• Unit Testing: Lick the knife or spoon after application is complete to ensure both the correct and of quality material.
• Acceptance Testing: Are bread corners aligned? Are sticky sides facing each other, towards the inside? Take a bite and compare with expected results, and is the difference within the acceptable delta range?
• Deploy: Locate an individual drinking container, and fill it with consumable fluids to have ready during and following sandwich consumption.

After a comment, I realized it wasn't clear on the intent of this post.

The point wasn't to emphasize a development lifecycle, but it is organized that way. It is an easter egg. A bonus. Rather, the purpose was to illustrate that a common subject can be modelled and mapped in surprisingly obvious ways that we take for granted. It is one thing to teach abstractions for the sake of the abstraction, but to do process analysis and algorithm design, I always found it helpful to know the subject (the interfaces, interactions, and fundamental behavior), and sandwich construction is something anyone taking a CS 101 class can readily understand.

CS and SE are certainly distinct; yet, they often go hand in hand. The bonus is that while you grow intimate with sandwich making, you also explore software engineering problems. Some of those software engineering problems just might be good candidates for cursory study in an introductory CS context.

For instance, planning dates and scheduling as the concrete subject or domain, with the underlying topical subject being temporal data handling. Temporal data handling could be a series of courses itself if you really wanted to delve deep, so pick and choose. Admittedly, much of correct temporal data handling would be beyond the scope of CS101, but in nearly any problem one faces beyond school will involve issues of correct measure (or more precisely, adaquate, when weighing factors of precision and efficiency), handling, and recording of time.

Answer 7

From my experience I believe that programming is similar to math, the more you practice the more you learn. If you want someone to learn and understand the programming language, the best way is to provide them exercises for practice. But don't forget to explain to them the small programs with useful concepts. Ex. Teach them how the switch case works then give them programs related to switch and related to other concepts too.

Answer 8

If you need to teach programming I will prefer you read "Head first Programming". It has a lot of real life examples.

Answer 9

I first learned programming from a few short (1 to 3) hour presentations. The one I learned the most from began with the instructor handing each of us a copy of a well written program which used most of the language features. He then walked us thought the program line by line explaining the purpose and function of each line (including comments.) By the end of the presentation I think we all could understand a program, and could to some extent write a program. At the end of the class we were given a cheat-sheet for the language syntax.

I don't have any Java examples that I can suggest. Looking a couple of classes of a useful program should be give a good introduction to Java. Then you can get into a variety of other issues, such as finding and using library classes, design and implementation, etc.

While it is standard, I find the hello world programs are often overly convoluted. As a result I find them a poor introduction to the language.