How Can I Make My Programming Class More Interesting?

Question

I already found a similar question here on SO, but almost all of the answers were more philosophical, rather than practical.

I'd like some PRACTICAL ideas about how to make my programming course more interesting. It doesn't matter how much effort it takes.

I thought about asking my students to pick a topic in the beginning of the course and to work on it as some kind of a real, small, startup project that they could financially exploit once it's finished. But I'm afraid that most of them will not take the project to its completion, and that it could become very boring.

Also I thought about involving them in Torcs, but I'm afraid most of them wouldn't be up to the task. Btw, Torcs is Car Racing Simulation, but there's an API for developers so they can develop their own AI for the driver, and then race their car against other programmers' AIs.

I'm not asking here for problem examples, as I asked a separate question about that. I need ideas about making my lectures more interesting and fun.

Answer 1

I had a very nice professor. He never presented slides or something like that: he started the lecture with a question (like: "How can I make an algorithm to define what coins should I use to give your change back?") and lead the class get to an algorithm. As we advanced, he explained some concepts we were "meeting" along our path.

But one thing is VERY important: he wasn't only explaining, he was doing that with passion: he was running around, making jokes, "suffering", jumping. You could see that he liked what he was doing and he was challenging you to solve the problem he was proposing. You felt: 1- if you don't do it, he won't give you the answer. 2- If the class get stuck, he would help. 3- he was "really there" working with you, he was also "struggling" against the problem to create our own solution.

This was a very hard lecture, but I couldn't miss any of them. If I could, I would still visit it :)

Answer 2

Have your students team up into pairs for a project and then have other teams do code reviews of their completed project. This will allow for simulation of a real work environment and probably lead to discussion/debate about the students chosen implementation of the project. I would say to be sure to pick the teams yourself so you can pair a strong students with a weak student and then chose how the teams will swap so that a potentially weaker team doesn't get too stomped by a stronger team. Either way good debate is always fun. Also autonomy is always more fun than a truly defined project so I'd try to leave the parameters that define the project as open as you can so that students have to be creative and have some investment in their project.

Just a thought.

If you're just looking to spice up your lectures then check out the http://thedailywtf.com/ for examples of bad code and tear some of those code examples to sheds in the meeting.

Answer 3

One of the most boring (and dangerous - you end up with students who metaphorically use a hammer when a screwdriver is the right tool) things about current programming courses is that the techniques are taught without the context of "When would I need to use this?"

So here is what I did when I taught, I made a list of all the techniques I wanted to cover in the course and then determined where I would actually use them in real life to solve an actual programming problem. Then I used those problems in my lectures.

If possible, keep at least the most basic stuff in one project example, so the students can see how there things relate to what was done before. Some of the advanced techniques may not easily fit into your basic project, so you can use a different one for those, but it is critical to ensure they know when to use techniques and, perhaps more importantly, when to not use the technique.

I virtually never lectured for more than 10-15 minutes (just to introduce radically new concepts) but used the Socratic method to get the students to find the answers to my questions in the textbook and used lots of exercises to re-enforce the learning.

I also gave a project in each course and left the last 4 or 5 sessions for working solely on the project (so I could see them work on it in front of me which cut down amazingly on the cheating and i coudl provide advice in real time not just at grading time). Sneakily (is that a word?), I did not tell them what they needed to have in the project to get a A but what they needed to do to get a B. Then I said, "You need to do something beyond this to get an A." The students went way beyond my wildest expectations when I did this. I would require students to do their projects in source control and having the second to last session as a code review (last session for fixing what the code review found and final tweaking) appeals to me although I didn't do it back then.

Answer 4

It is not really necessary to be a "funny professor" (but of course it won't hurt). What is more important is to get your students involved.

So build the course around a realistic and cool application.

Emphasize the way that the stuff you teach helps creating tangible and cool things. Also, don't be too democratic in picking the application. Normally students (especially at schools) are extremely passive at the beginning of any course.

Answer 5

As a student who hopes to someday teach, here is my perspective:

In my introductory programming course, we started out with pseudocode, then graduated to Alice programs (the environment is a pain sometimes, but the resultant "programs" were often quite amusing and fun), and as our final project of the semester, we were split into teams and tasked with programming some Lego Mindstorms robots for a simple race. Pretty awesome introduction to programming, IMO.

In Java 1 & 2 (same professor), we were usually rotated in 2-4 person teams for programming assignments out of our textbook to learn the material. We would always do a "presentation" of our code -- and we were required to "speak the language", using all the technical terms like method, constructor, accessor/mutator, etc. -- so we could see what our peers had done and learn from one another's code. The Java 2 course wrapped up with a larger project (a golf handicap tracking application) which the professor rounded up several industry professionals to judge (which helped us make contacts at local tech companies).

I hope to teach someday, and I do plan to implement some of the above methods. However, I think it would be pretty awesome to secretly (or not) build a game or web app other fun, interesting, and relevant application during the course of a semester by doling out potentially "boring" assignments that teach the students the fundamentals but apply to the overall project, and then spring the completed program on them at the end of the semester for a big "Surprise! -- You built this!" and show them where their code fit in. I think it would be a good "real world" experience for the students. I haven't quite worked out the details of how it could be pulled off, though. :)

I think it's imperative to inspire the students by keeping things interesting and relevant to what's trending in the field while still building the foundation they will need to be good programmers. You may want to check out MIT's online course material from years past to get some ideas -- they do a good job of keeping it interesting and relevant (ie. One of their software engineering courses gives the choice of building a game or an RSS reader and encourages the use of 3rd party libraries and APIs).

I hope this helps.

Answer 6

Presentations that had some audience participation can be useful. Are there ways to make the lectures involve asking the class a question and seeing if someone knows the answer? Granted this presumes a small class. Another thought would be to split up the class and have groups work on little assignments in class but this too carries the challenge of not being practical in a class of 200. Another line here is to try to accommodate different learning styles with the way the lecture is done. Is the material presented in text, picture, or some other format?

Answer 7

First: Motivation. Pose a real (and solvable) problem, maybe in the form of a question: "How many times will I have to attend this course until I get my grades?".

Work with your students to get from this fuzzy requirement to a finished product, and explain along the way ("We have now found out what we need to do, and we have defined the criteria that need to be met. This is called requirements engineering, and if microsoft asked us to write this software for them, they would compare our result to the specification.", or "ok, now we know the formula to calculate the number of mondays up to a specific date. We have an algorithm. Let's translate this from words to Java.").

Do not be tempted to explain something out of context first and expect them to understand, remember and be able to use it later. Always present new knowledge as a tool to solve a problem at hand.

Implementation: Make sure there are constant small successes, and make sure these successes are visual and concrete. Do not make them program command-line software; in their mind, a computer program has windows (or it's a game).

I think the hardest part is to find a project that is both easy enough yet still not as useless and boring as "Hello, world!". Asking the students to find a project that meets these criteria is asking too much of them. The freedom of total choice can be a burden.

Answer 8

Your students will probably have the best ideas for different types of programs that they would find fun to write. You could ask them to make you a list of software programs that they have wanted to build, thought were really cool to use, or needed at some point in their lives.

The best class that I ever took was one where the instructor brought in a user and questioned him. Then we each had to write a requirements document for the project that he described. The instructor also wrote one up for the project. Her requirements document was then the basic class syllabus for the semester. Every piece of development that we did after that was related to bringing the software to a more advanced stage of development. She had us also doing some basic technical writing on the project where we had to write up a help file for it. All assignments had to be written as business documents or technical documents.

She used the same format for her beginning level classes as well as her advanced software engineering class. For the basic class she was more lenient about quality of the work provided at the different stages. In her advanced class she split us into groups of 4 or 5 and we had to design and develop the software from beginning to end using more advanced skills.

Answer 9

I would start with asking them for an example of a program \ exercise they believe they did well, or one in which they believe they had problems (if it's a class, and they have several different solutions \ approaches for the same problem it's even better) - and use this as a case study for the subjects you want to teach.

You can also give them such an exercise in the beginning of the class, and use it for a case study for the rest of the course.