how would you like computer science classes to be taught?

Question

hello

I am a graduate student now, and hopefully someday I will teach. my interests are C++, Python, embedded languages, and scientific computing. Meanwhile I daydream about how I would teach. I was not quite happy with my undergraduate university as I found many computer science classes lacking.

so I would like to ask you, if you were a student, how would you like your computer science classes to be taught? I understand it is a very subjective question, but nevertheless I think it's important to know what people want.

Some specific points I am interested in:

• should computer languages be taught explicitly, or should students be required to pick up language on their own?

• what is better for learning, tests, projects, some sort of take-home exam?

• how do you think classtime should be used? theory, introduction, explanations, etc.?

• do you think the group projects are important?

• how much about computer architecture do you want to learn in computer science class, not necessarily assembler class.

• should particular operating system/editor be mandated or encouraged?

Thanks

thank you for your comments. Question has been closed because it is a discussion question rather than Q&A. If you know appropriate website for discussions of such sort with low noise ratio, please let me know.

Answer 1

Teaching people to RTFM/"help them help themselves" should be more common than it is today.

I see I got a downvote already, so let me explain. A lot of students get information served to them, and they're expected to pick it up. Very few actually do; most people learn by repetition, and in programming that means actually programming. And in programming, being able to read the manual is a required skill. No project is ever the same, and nobody is expected to remember everything. Learning to find what you want, quickly, is part of what separates the advanced programmers from the experts.

And a lot of newbies ask questions that they should have been able to find themselves. Teaching them to look stuff up instead of wasting other people's time gives them nice habits. Not that helping anyone is a waste, but it's distracting from what YOU'RE doing.

And the sentence "If you can't find what you need in the manual, google it! Chances are that you're not the first one wondering about that particular feature. Maybe the language requires a different solution than the one you had in mind?" should be repeated every week for the first year of any CS course. When I did my CS course, some people expected the language to have a fix_my_problem() function, while others didn't even know how to attack the problem. I don't know which is the most googleable of those two, but I bet both are pretty suitable for googleification.

Answer 2

Functional programming.

Answer 3

should computer languages be taught explicitly, or should students be required to pick up language on their own? There should be a first-year course for teaching a language, e.g. java, that gives them the concepts of programming; classes, methods, procedures, compiling, running things. Running through basics with sample programs then building up to a end-semester project of a simple functional program given specs, delivered in the right way, should give a decent overview of coding basics, and a slight glazing over the fundamentals of programming, that can be extrapolated on later.

what is better for learning, tests, projects, some sort of take-home exam? Specifically with programming, you learn best by doing. You're going to get naught out of copying syntax from a board, but being able to type your own stuff into a compiler with the aid of looking up the API as part of tutorial sessions is a great way to feel your way around the basics of the language. Projects are also good, given sufficient feedback at points of the project, so that the entire time isn't spent in the wrong direction.

how do you think classtime should be used? theory, introduction, explanations, etc.? Lectures: given that if you ask a group of students to skim over a chapter before the lecture is going to mean no-one has even looked at the content, time should be taken to overview the fundementals in tutorial time. I found that going over theory in lectures and practicing stuff in the tutes was ok, but was better for learning if the tutes delved into the murky waters of the next week's lecture (e.g. methods in java, then the tute master mentioning the 'public static void' stuff and what it actually means, with the theory being explained in the coming lecture)

do you think the group projects are important? Group projects are important for giving the basis of how a group of programmers can function effectively, but it should be mentioned that this can be a recipe for disaster. One of the major group projects I had was part of the actual Project Management course, but it was so poorly organised that we had no idea what we were supposed to be doing until near the end of the course, as the content and the basis of the project was based on stuff that wouldn't be fully covered until the week before the project was due.

how much about computer architecture do you want to learn in computer science class, not necessarily assembler class. By the start of second year, half the cohort remained from by Bach. IT group. This is mostly, I believe, to the first-year course that focussed mostly on Assembly language. That shit scared a lot of people off into marketing and business, I kid you not. But I felt it was one of the best courses I did, because now I appreciate how programming used to be, and how complex it is just to do a getFile. As for computer architecture, there was an optional final-year course on Operating Systems, and that was a very intense ride. Sure, there was a first-year 'Foundations of Computing' course, but that was only brushing over Turing and Babbage, and not getting into the gritty. It depends on the flavour of degree. Info. Tech. is what I did, Computer Science not really offered in the colonies, at it was more focussed on the technology person -> client world, as opposed to technology person -> computer interaction.

Answer 4

I did several computing courses at uni involving Haskell (yuk!), C, Assembler and Java

The Java course was the last one I took and the one that turned me from someone who hated programming into a full-time coder. It had nothing to do with Java (though I do like Java) and everything to do with how the course was taught.

In all the other courses I took, assignments were set with a "Do X using Y" where Y was a concept we'd learnt that week in lectures. If you didnt use the concept or you misused it you were heavily penalised.

I believe that coding is as much a creative excercise as a technical skill and this just didn't gel with me. My Java course on the other hand had weekly assignments which went like this: "This is your problem. Solve it. You can use any method, library or technique you want"

I loved this course as you were able to really be creative with the solutions. Yes, you didn't always have the most efficient or most secure solution but this is about LEARNING. As long as you solved the problem you got full marks with bonus marks for an elegant solution and you'd always get good advice on the "right" technique to use after the assignments were submitted.

The part I loved the most was that I had a couple of friends in the class and every week we'd compare our solutions to find 3 completely different ways of solving the problem. (which I think was 3 times the value of everyone just trying to do it the same way)

The moral of the story: Allow your students to be creative in coding!

Answer 5

I would want to learn by way of actually creating something useful or fun--a game or something else innovative, preferably chosen by the student and not the instructor. The instructor would be on hand to facilitate each step of the process and show how a programmer would do it (e.g. looking up resources online and self-teaching, following examples where available). Not the way it's commonly taught today as a sterile subject quite apart from the practice of it.

Answer 6

I think the two biggest jumps from writing code in university to writing professionally were

1. Learning to integrate multiple technologies into a cohesive project and
2. Learning to maintain the work of others.

I had a twisted idea for how to teach both of these things, while making for a great lesson on all the -ilitys of software engineering.

Give the students a moderately complex problem such as writing a two player checkers program with board display and two human players. Put a tight deadline on the project to add some pressure. When the project is turned in, redistribute each student's code base to another student and tell them to finish what the other student did not, and then add networking support. Then repeat the project again, forcing the students to add a gui, or an AI.

When it's all over, have the students give a grade for the work they inherited, comparing the previous work to the work they did. Forcing students to see, fix, and maintain the work of others will hopefully instill a sense of craftsmanship in their code.

Repeat the project again, this time telling them the format ahead of time. See if code quality improves.

Answer 7

I teach an introductory computer programming course as a TA at my local University. There are a few things which I think are highly critical for teaching Computer Science and programming in general.

1. Never assume too much about how much students should already know about the topic. It is better to assume they know less than they do than to assume too much. If you explain the basics which everyone knows once again no harm is done with the repetition, but if you skip them then those that do not know will be lost.
2. Starting with a basic course on how to program is mandatory. Pick a language, and go with it. When picking a language you should take into account how widely used it is and how easy it is to learn. Great starting languages would be Java, C++, C#, and Python. Later courses which use similar languages can introduce them to the language, and be reasonably confident students can learn it with self study.
3. Students learn by doing. Structure your assessment and classes around actually doing the problems. This mean labs or tutorials with teaching staff instructing them how to code as they go. Assignments SHOULD be challenging and time consuming, since they will learn a lot more from it so long as they do not leave it to the last minute.
4. Make learning accessible to students. If after each lecture you point the students to a new textbook vaguely related to the material from that class, then students are very unlikely to read every single one. If a good textbook exists which covers your course material quite thorughly, prescribe it as a text, and tell students from week to week which sections they should be reading/studying. If no such text exists, then write your own course book with all the material in it.
5. Students typically do as much work and study as they believe is required of them to get an okay grade. If they underestimate the amount they think they should be doing, then they fall behind and fail. Don't let them- Let them know that they will have a hard time passing unless they do x amount of work a week to pass.
6. Students do not naturally spread out their work and study over a course like they should. They work to deadlines- they'll do the vast bulk of the work when they see an assignment or test is coming up, and can easily get overwhelmed if several things are happening at once. Introducing some light weekly assessment will encourage them to do work more consistently throughout the semester, and will make them better prepared for the larger assignments and tests.

Answer 8

I always started with figuring out what was the real underlying goal of the class (which is NOT to cover chapters 1-15 in the textbook.) In other words, in the real world why would someone need to know this information.

For instance in teaching an operating systems course to a group who are specializing in networking, the real goal might be to have the students be able to research and troubleshoot operating systems issues. This is very different than being able to tell you the difference between Windows and Macintosh and Linus operating systems (which seems to be the goal of most textbooks!).

In a database course designed for people who are specializing in information systems, the real goal is to understand how to query a database and especially in enough complexity to produce reports. But if the students are computer science students, they need to not only query the database but understand how to design one. (Incidentally all the database textbooks I ever read started with database design and work out to queries at the end and I always reversed this, students who don't understand how to query aren't ready to understand how to design. Do it in the order of the texts and you'll lose half the students the first week. Think about this in what ever texts you are using, is the information in the logical order for understanding it?)

Once you really understand what the student should be able to do when the course is finished, it is easier to design the course. I always think of what real world examples I can find to get the material across. Textbooks have notoriously bad examples and leave the students wondering why they would ever want to do whatever the task was. I try ot supplement with examples that will make sense to the students as to why they would want to do ...

I rarely taught a course without a final project. Further, I allowed at least two weeks at the end of the course where they worked on the project in class in front of me. By wandering around the classroom, I could see who was having trouble and who was probably going to try to steal an answer off the Internet and give it to me without understanding. I never let students work on a project completely in off-class time. Further I made my class projects such that they were relatively hard to steal by varying them every semester. I also was sneaky because I only told them the elements they had to have in the final project to get a B. To get an A they had to do things not described in the project handout. Once I started doing this the quality of the work I got went up drastically as students had no idea how much extra they had to do to get an A and went all out. The other instructors at the school where I taught (a technical college) were so impressed with the projects my students did vice what theirs did that several of them also adopted this approach.

In day-to-day teaching, I usually did as little lecture as possible. Often instead of lecturing, I asked the students questions to cover the same material in a way that would make them more likely to learn it than a lecture (Lecture is hands down the least successful and most used training technique because it is easiest for the teacher to prepare). I averaged 10% lecture when I taught and the rest was hands on and group discussions. When I did lecture, I made it interesting, no reading straight from the text or slides. If a student seemed to not be paying attention or falling asleep, he or she immediately got asked a question.

I also prepped extra exercises for the smart students who finished earlier than everyone else. No one permitted to sit around looking bored in my class. I also got some of the students who grasped the material best to work individually with some of those who didn't. That gave the least proficient more attention and helped keep the most proficient from being bored, plus explaining to someone else helped cement their learning process.

Don't give out exercises to do and then leave the room. Move around the room and give people individual attention. Let them ask questions to you personally that they might not be brave enough to ask in front of the whole class. Make sure you see what they are doing with the exercises and give pointers when they are stuck by asking leading questions. When you see a pattern inthe problems several people are having, stop the exercise and explain somethign further if need be.

In class discussion, force everyone to participate. It is your job to make sure they all get the material, not just the few smarest who answer first.

If the class is clearly not getting something, try a differnt method to get it across. It is more important that they understand the material you do cover than the total number of chapters covered. If that means that you have to repeat a particular difficult section of the course 4 times using four different techniques, then do it. This is especially true of critical skills or concepts.

You are preparing students in a field where research skills and problem solving ability are important. Include exercises that use those in every class. Make sure they have things to do where right answer can't just be looked up in the back of the text. Make them find three differnt ways to solve a problem for instance. Then ask them to tell you the pros and cons of each way.

I'm not fond of group projects until the students are very advanced. The more advanced students will do the group work to get the A and the less advanced will do little or nothing and thus no learning occurs for them. Core concepts need to be learned individually. When you do a group project, I never let the students choose the groups either. You have to work with whoever else works at your workplace not just your friends, learn to deal with people you aren't fond of at school.

In teaching you get what you expect - so expect more than you think they can give you. You'll be pleasantly surprised at how much more they can do.

Answer 9

I think this is a great question.

I taught programming in Fortran as a TA, and then later as a professor in a liberal-arts college (Basic, Pascal, Lisp). Frankly, the only programming course I ever took, I hated, and any more probably would have discouraged me. What got me into the field was projects, specifically engineering projects (mechanical, civil, electrical).

In college teaching, I got to make some mistakes until I settled on a pattern that seemed to work. I would start having students use a simulator for a very simple decimal computer, to put in place the basic framework of memory, addresses, loops, instructions executed in sequence, and the idea that the basic building blocks are very limited. Then we would introduce Basic and build up a variety of tools (loops, arrays, files, basic algorithms), just enough to get the students able to tackle a project of their own choosing. I would give them lots of suggestions of possible projects, and they would take it from there. I asked for reports / code along the way so they would pace themselves, and made sure I was available to help if they got stuck.

Unlike some other professors, I always made sure that the student could tell if something was "correct". If you are doing a project for yourself, there is no judge but yourself. Programming is not religion, it is engineering, and I scorned the notion of "commandments" and the "right way". Students (especially non-engineering students) would often ask me what was the "right way" when there was a choice, and I would gently admonish them not to look to authority. Wherever there are generally accepted good ways to do things, it is not because some prestigious person says so, or because it will affect your grade, but because there is a valid reason, which might apply some of the time, and not at other times.

For upper-division courses, we would get into data structures, compilers (i.e. write a simple one), Lisp and A.I. (my field), and operating systems. What would have been good, but we didn't get a chance to do at that level, was formal stuff like automata theory, although I taught that later in night school, which was very enjoyable.

Now there are more languages to learn, and more bandwagons (OOP, functional programming). These bandwagons are both good and bad. The good part is programmers should know what they are and how to use them. The bad part is they are treated as "the next big thing", rather than being analyzed for their strengths and weaknesses. It's as if medical doctors were trained on a new class of drugs and were told to use it for everything.

If you choose to go into teaching, I wish you the best.

Answer 10

About the group programming: I think classes should cover programming in groups. However, the focus should not be entirely on the programming. There should be a lot of attention put on group psychology.

How should the team deal with a member who does not contribute? One who writes crappy code and makes more work for everyone else? Someone who refuses to follow the work process and instead of merging their code, overwrites everyone else's code in the VCS?

Or on the other hand, how to deal with the one group member who is much much better than everyone else, is arrogant about it and spends time making the other programmers feel like idiots? Or even dealing with a not-arrogant superior programmer who makes everyone feel slow: there can be great temptation to slack off and let him take the load, which in real life ends with him leaving you to work for Google or something. :)

This stuff isn't really about the programming, its about group psychology, leadership and management. Every programmer working in the real world will need to know how to deal with this stuff.

Everyone should also learn project management and architecture. How to take a software design and divide it into tasks and assign it to individuals is an important skill. So is keeping those individuals on track.

Answer 11

My first computer science course as an undergraduate focused a lot on object-oriented design concepts. This is important for any computer scientist, but they also had this course as a requirement for other scientists (biologists, geneticists, chemists, etc). There were something like 10 coding projects in the class. By the fourth or fifth project, students were already expected to write Java GUIs and do event-based programming, whereas most of them still didn't know how to design and write a program from scratch.

As useful as object-oriented design is, there are some more basic fundamentals outside of OO that in my opinion should be covered first. Computer scientists will eventually pick this up just because of extended exposure, but for other scientists who may only get 1 semester of exposure, we cannot assume they know how to write and run a program.