How to motivate students for a programming section?

Question

Last year I tried establishing a programming section at my alma mater. We started with a clear document detailing our plans and goals and a solid attendance (around 20 students). I ran into following problems:

• I found it hard to manage such a large team
• the majority of students had little or no programming experience other than C starting courses

I tried splitting the section into 4 teams of approximately 5 students each, with more experienced programmers at the head of each team. We defined some real world problems to solve to make it more interesting for students and got to work.

However, with upcoming exams attendance dwindled and then finally stopped.

At the time I felt that the students were not willing to put in the effort to learn something new. Later, I believe that they felt the task was too hard for them, and motivation suffered as a result.

My question is therefore: how would you motivate students?

Answer 1

The trick would be keeping student Motivation high during the classes. That would be the Key to success or achieve the course goal! The course plan/agenda needs to be adopted to the average student level in the class.

Well, how to achieve it? There are few important to mention:

• extrinsic – the motivation comes from some external source, probably an expected future reward (usually financial).

• intrinsic – the key is an interest in the subject itself.

• social – the main motivator is a desire to please some third party whose opinion is valid (family, sponsor, teacher).

• achievement – the motivation comes from the sense of "doing well" academically, and possibly the satisfaction of doing better than peers (this is sometimes called "competitive" motivation).

• null – there is no clear motivation (the student may have simply "drifted into" a programme of study, and may have no clear idea of why they did this).

Some more references that might be good for further readings

• How to teach programming - a slide
• Diversity and Motivation in Introductory Programming
• TEACHING PROGRAMMING SKILLS USING GAME MAKING, BLOGS AND WIKIS
• Teaching Programming – A Journey from Teacher to Motivator
• Teaching Programming To A Highly Motivated Beginner

Answer 2

I think that pacing is key. The thing I love more than anything else about programming is building cool things that do stuff (even for trivial values of stuff). An ideal programming course would be spaced out so that every week or so (don't know your exact schedule) the students learn some new thing about programming.

A good way to set this up would be to propose a problem (How do you store a set of things easily?), let the students come up with some ideas on how it could be done (in groups, if you've already got that set up) and then teach them the implementation (arrays, sets, lists, etc).

Bringing something new to the table every time you meet will help keep interest high and you could even have students design their own implementation, if they're up for it. Allow the groups to compete, and keep track of who has the fastest/best implementation.

Answer 3

I have also tried to organize a programming course, on small scale (my son and some classmates want to go to an IT class in secondary school). I have to admit that I planned more, but I think having most of the attention of some 14 years kids for like ten occasions (and between them when "working for me") is not that bad. So, you might find something usable in what I tried to show them.

I talked to them about programming in general: the basic concepts of separate components, responsibilities, communication. I used the analogy of some crabby dwarfs: all software are build from them, they want to know one and only one thing, but do it well. They are happy if they don't have to talk too much, and don't want to be instructed in details: clear orders, clear responses, no intrusion into their worlds. (OOP at its best, without the magic words). I also talked about the computers and the "world" existing in the running programs, but this was not that important.

And here is the trick: after explaining the dwarfs, I immediately asked them to choose a task, solve it by creating the proper dwarfs: imagine them, explain what they know and what they do for the others (added some hints like separate the "display dwarfs" from the "workers"). The result was quite good: like a properly segmented stopper / timer / clock, and a text-to-speech app design. We then discussed the structures, analyzed and corrected the mistakes together.

Then I asked them to find a task that is interesting to them enough to work hard with it together and for a long time as a team, because this will be tough. They have chosen the poker game. We totally skipped the display part, started with the workers (card, player, location, round, game, ...) and their communication. I forced them to create sharp statements this time, nouns are data, verbs are services, each noun and verb must have its detailed explanation somewhere inside a dwarf. They did not like it too much, but worked well under pressure. The game finally got its shape, we talked a lot about data structures, single and collection instances, constant and mutable information, "where" to store pieces of information and why there, when instructing others, what to send with the order, and what should be there at the executor side (core OOP again). We eventually touched the problems of caching as well... I played with switching dwarfs between the kids, to motivate team working and clear, explainable descriptions. They even started using gliffy.com to design the structure.

When the result was clear enough, I asked them to design the user interface: what to see where, how the game should look like and run. We could also talk a little about ergonomics here: what I want to see, what I don't, what I have place for, what I don't, how can I see the state of the game, how to show that I am not able to do something now, etc.

As you can see, I have not talked about actual coding at all (and of course they have zero previous knowledge), because I think the majority of programming is clear thinking and design, that must work fine without an IDE, and before writing anything. I also think that what they did was real programming (more than typing and running sources from a text book), they really worked hard and learned a lot from it.

In this way, I will write the first program to show how I translate the ideas into Java code, how it becomes an actual running game. So they can see a clear code (and not a "hello world" spaghetti), but they will also understand the structure of the source because they have designed it, and learn the actual tools (files, classes, services, etc.) by watching how I use them to make their ideas work.

If it continues at all, I will ask them to find new tasks - some related, to see the reusability of the dwarfs: another game (player, round, evaluation), another card game (cards, desk, etc.), and some totally different; and slowly moving to writing their own sources (but strictly keep the rule: think first). I think we will use github from the beginning, just to get used to it.

My experience is that 14 years old kids can easily understand the most important concepts of programming - but it is very hard to keep them focused on the task, each and every time I had to repeat: "the computer is stupid, will not understand an order just because you use the right word, you have to exactly define how it should execute it!" It is not easy to keep them motivated in this way, even though they have chosen a game that they like (poker was a perfect choice by complexity as well), and I always praised them for good questions and answers, and added that "bad" answers have their important part too, and analyzed them as well. We had hard moments, but all in all had a lot of fun too (I synchronized the angry dwarfs...). This is why I thought showing their game in action would be a break through: I as an experienced programmer know how very important and great what they did each time, but they of course don't see the progress, what they expect to be "a computer doing something according to what they type" (and of course it should be a real-time FPS :-) )

And please don't miss the greatest mentor, Randy Pausch...

Answer 4

You cannot force anyone to be motivated. Motivation comes from within. Why would anyone take on any work? Money? You don't pay them. Prestige? Is there any honorific that you supply? A title? "Grand PooBah of Perl"? Duty? That worked for the US military after 9-11, but now their recruits are signing up because there are so few jobs for young people. Career advancement? Do you have any hooks into companies that would see this effort as a foot in the door to employment?

You should look at your approach as volunteerism mixed with personal growth. The former attracts those who want to help the less advantaged. Does your project provide any such help? The latter takes us back to my first point.

Maybe you are on the wrong track. Perhaps you should advertise as "the most difficult intellectual challenge you will likely ever face", which is true for most of your victims, er, students.

Answer 5

Gamify! Split them into teams and ask them to write algorithms that would compete with each other. Add points for using good programming techniques: use of design patterns, code clarity, commenting, testing, etc.