Category

Blog

Category

Some context.

I have taught the intro to computer science course at UTEP every regular semester since spring 2015. A lot of what I aim to teach the students in this course is how much computer science is about problem solving. In this respect, when I get to meet them, I believe that students are already pretty skilled in solving problems. They have solved and continue to solve problems daily (without realizing it: that’s the catch). By the time I get to meet them in their first CS semester at UTEP, most of my students have already been juggling jobs and school and commute for several semesters. This is serious problem solving! Nevertheless, they do not realize that and the main challenge I face in “teaching” my students problem solving is to get them to up their self-confidence in this area.

So, early on, as I started to teach the intro to CS course, I informally put together a so-called problem solving and programming club, meeting once a week. It had very limited success, although growing over the semesters when I held it (until fall 2016). The goal of this club was to bring students together around riddles and other problems that we would solve together during one hour a week. Sometimes, we would implement (program) solutions to problems, program ideas to test them, bend problems definitions while programming to push further and explore other ways of programming, etc. The ultimate goal was to create a fun environment in which students would regain confidence in their problem solving abilities. I did not conduct any study to formally assess the impact of this initiative. However, I noticed that students were developing a knack for riddles and other problems. The fear was vanishing. That was worth the effort, even if for few students only.

I then decided to try it as a full 3-credit-hour course. In summer 2016, over a month (4 weeks, a little over 2 hours daily), I taught a special topic on Problem Solving and Algorithms, to a class of about 15 students (a mix of junior/senior undergrads and graduate students). Since, all of a sudden, I could take advantage of 45 hours of meeting time with students on this topic, I was able to do even more, to structure my teaching around different elements of problem solving, different types of problems, even have graduate students do some research of specific problems. I used two books: first, a pretty friendly book of riddles and problems: Problem Solving Through Recreational Mathematics, by Averbach & Chein, Dover; and then The Power of Algorithms: Inspiration and Examples in Everyday Life, by Giorgio Ausiello and Rossella Petreschi, Springer. The first one provided a range of activities organized by topics, types of problems. The second one allowed us (and the graduate students mostly) to dive into specific problems, which they then researched further into and presented. Although there was again no formal assessment of the impact of this course, I collected anecdotal testimonies from students who took this course in regards to the impact of taking this course on their performance in other CS courses. I only received positive feedback. The main positive change was the newly found ability to pause before to dive into solving a problem: that is, to take the time to understand, rephrase, and model a problem before to start solving it. This sounds trivial, but it is crucial and often overlooked. A common tendency when approaching a problem is to slide through the understanding stage and to start to work… which often results in solving the wrong problem or in getting stuck at some point and unable to get out of such a deadlock.

In Summer 2017, as our CS department, led by Dr. Ann Gates, had just been awarded an NSF RED grant, among other things, the faculty revisited the UG curriculum and we proposed to add 1-credit hour courses to the curriculum to scaffold the early semesters of our CS UG students with complementing courses. Among the proposed courses was a course on problem solving, which turned into a series of three 1-credit-hour courses on problem solving: they are currently being developed, in consultation with Google, by UTEP (#1 in the series), California State at Dominguez Hill (#2 in the series), and NMSU (#3 in the series), which are CAHSI institutions. I developed the first course in the series, which is a variation of what I did before in my club and in my summer course, and I taught it twice during Fall 2017. The whole course was recorded and analyzed in the context of our NSF RED project. Findings have not been shared yet. However, after teaching this course twice, in addition to my prior experience, I wanted to share some of the elements of this course and why I think it is working.

Essential Elements for Problem Solving.

No Programming. It is important to mention that there was no programming/implementation involved in this course. It focused solely on developing the students’ ability to lie out a plan of action for solving a problem. So the emphasis throughout the semester was that “the solution does not matter; the journey towards it does”.

A Problem-Solving Framework. The biggest change (improvement?) from my previous experiences to the last two times I taught problem solving was that I had my students study and use a given problem-solving framework, namely the IDEAL framework: Identify, Define, Explore, take Action, Look back. There exist many problem-solving frameworks out there. Sharing one with my students did not mean to limit them to one way. However, I felt that they could use the comfort of one consistent approach (at mid-semester though, I shared another framework with them so that they could compare, contrast, and reflect on them). My goal was that, strong of this new tool (the framework), my students would feel empowered to take on any problem, even outside of their domain of expertise. This did work, at least as far as I could tell on the problems we covered in class. Each of the two times I taught this course, we had an invited speaker, from a domain outside CS, who came and presented a problem of his/her area, for my students to tackle. The two engineers at Google, who advised us on the creation of this course, also contributed a problem, which turned into a final presentation of the students’ work. Their problems were never CS problems per se.

Rephrasing and Pointing Out the Challenge. “I” and “D” are usually rushed or even merged, skipped when one is not skilled enough at problem solving. The risk is to end up solving a problem that is different from the presented one. A large part of the semester was spent practicing the rephrasing and defining stages of problem solving. An essential element of doing it right lay in the students’ ability to ask questions. They were expected to ask questions of all problems that were presented to them, even of the simplest riddles, for practice. Once students were gaining confidence in “I” and “D”, they had to practice clearly identifying the Challenge in the proposed problems. Indeed, there is no problem solving strategy if there is no challenge, if the problem has a trivial solution. And pointing out a challenge or challenges helps set the Exploration (“E”) phase of the problem-solving approach.

No Action, but a lot of Assessment and Long-term Monitoring. As mentioned earlier, this course was not concerned with implementing solutions, but rather with laying out an action plan. As a result, the “A” part of I.D.E.A.L. – taking Action, was fairly limited. This did not prevent us from discussing what should follow “A”, namely “L” – Looking back. Students learned how to plan assessment metrics and devise plans for adjustment, sustainability, once an action would have been tested or even deployed.

Concretely, how did this work? I believe that this course should be fun, rewarding, and gradually build a sense a confidence in one’s problem-solving abilities. Students should be challenged but gradually, and be on the edge of their sense of mastery. To achieve this, throughout the semester, we had a mix of riddles and larger problems, leading to much larger and complex and out-of-their-domain-of-expertise problems. But to get there, the mix consisted of riddles only at the start of the semester and larger (and much larger) problems were added little by little. Students enjoyed riddles and kept asking for them at times when we were doing less of them, later in the semester. Why riddles? Although I always emphasized that solution to problems are not important, in order to build a sense of confidence and mastery in my students and to maintain the fun aspect of the class, I felt that students had to get a sense of reward and in this respect, the more riddles proved to be the better. Here is why I like riddles: Riddles are understood very quick, so we can go through many: this allows for more practice. Although usually not representative of clear real-life situations, riddles can be very representative of common pitfalls in problem solving. I would often give riddles intended to trap my students, so that we can then have a conversation about why this happened, how to avoid the trap next time it presents itself, what such a similar trap would look like in a real-life scenario, and expand the riddle trick to an actual real-life meaningful problem. Although short, riddles lend themselves well to retrospection and analysis of the problem-solving approach: this allows, on small bites, to have students wording out their approaches and understand them better. It also allows them to practice on the IDEAL framework.

Attitude. I found essential to (1) encourage students to be creative, to word their ideas uncensored, to (2) validate their contributions and to explain how their ideas fit in the IDEAL framework, how their different viewpoints would nicely contribute to innovation in a diverse team, and to (3) gently push them to question the problems posed to them, as well as to challenge their own and their classmate’s ideas.

In closing, I am a strong believer that our students are strong problem solvers. However, until they have observed themselves often enough performing well in non-daily problem solving, they tend to fret, panic, and underperform in problem solving. A course like the one put together as a concerted effort with CAHSI institutions and Google has a tremendously positive effect on the students who took it. From the start of the 15-hour course to its end, students appeared transformed and they all delivered excellent work as their final presentation. I cannot wait to hear about and observe the longer-term effects.

 

 

 

In fall 2014, as two colleagues and I were readying ourselves to teach CS1 (in spring 2015), we decided to revamp the course, in the aim to reduce attrition (a long-standing problem in this intro course). Since then, I have revisited it several times: once funded by Google, and since spring 2017, funded by UTEP’s STEM Accelerator initiative. Often, I am asked what I did in this course. In this document, I leave out the details of all changes (I may address this in another document) to focus on the major changes I put in place.