Category

Blog

Category

The weight of Stereotypes in CS: 

Learning Computer Science, just like about anything I would guess, is not easy. In the case of Computer Science, a lot of “folk tales” are going around: “CS is not for women”; “CS is heavy in math”; “CS is hard”; “Wow, you must be super smart if you are in CS”, and I could go on and on and on… These statements are all false and unfounded. However, hearing (or having heard) these does not help when you are a student who might be second-guessing his or her choice of major, his or her fitness to the studying this field.

The weight of Expectations in CS2: 

Over the last semesters, I have taught CS2, which is the second course in the 3-course CS introductory sequence. Coming to CS2, CS students have already taken an Introduction to Computer Science course (or equivalent). We usually expect them to have been acquainted to programming in Java (in our case; possibly other languages for other institutions), to the notion of algorithm, to solving problems, and to the details of control structures that implement conditionals, repetitions, etc. This is a heavy expectation: some students may have taken the intro course several semesters or years ago, or even just a summer ago, and have forgotten a lot of it; they may have barely passed the intro course; etc. All sorts of reason that make them not fit exactly the profile we expect. And sometimes, it is just about perceptions and fears: students may know all they should know, but undermine themselves by thinking they are not good enough. This brings us back to the power of negative statements like those that I outlined earlier.

Regardless: Whatever the reason, whatever how confident or not my students feel about their skills coming to my class, I believe that we can work this out and support all students to succeed.

So how do we achieve this?

First: my disclaimer. Let’s be clear, I do not do magic… a.k.a., nothing I am going to suggest will work for a student who cannot commit. And to be sure I am not misunderstood, I understand that students may not be able to commit. A lot of our students work outside of campus, some are essential financial support for their families, some support their parents, others their children, some both, some are homeless, and I am sure that there are other circumstances I did not list that are as trying if not worse. So, I am very thankful to have my students in class every day of class and I understand that they might not have a lot of time outside of class to do what ideally they would.

However, in order for me to help a student (all students) be successful, I need their cooperation, that is, commitment. And commitment is not all consuming either, rather reasonable.

This being said, here we go. I have a few observations / recommendations on what to focus on.

Committing to what?

Computer Science is like running. I could teach you all I want about running: how to pace your effort, how to develop your endurance, etc. If you did not run, it would be useless, and by the end of the semester, you would not be able to finish the race.

I expect the same in Computer Science. Practice is required. The beauty of CS is that you can answer most of your questions by programming them: does the java instruction System.out.println(myArray) print the content of myArray or something else? Go code it and see it for yourself. This is a great power you have! I said something in class that you are not sure about: go and code it to check it for yourself. You do not need to stay confused: you now see it for yourself. Etc. Etc.

So the commitment I am expecting of my students is simply this: PRACTICE, CHECK things for yourself (yes, of course you can do it!), and PRACTICE some more… regularly, not just before a deadline or at the end of the semester.

Unless you exercise your CS muscle, I cannot promise you can be successful. Just like a running coach would not tell you that you could win or even finish the race if you did not (or only seldom) practice.

Now that we agree on the need for regular practice, let’s see how you need to practice, what exactly you need to do.

Give yourself credit:

However unfit, unprepared, or lost you may feel as you come to my class, I need you to agree to give yourself credit. You bring to the class and to your study of CS a lot more than you think you do. Most if not all of what we study in CS2 has a direct equivalent in real life. As a person, you have a lot to bring to what we are going to do: you know how to sort playing cards, you know how to look for stuff in your house, you know how to go from point A to point B without hitting walls or people, etc. You know a lot more than that. You may be working already, be taking care of your parents, your children. You may speak another language, another culture. You have time management skills that you often underplay. Bring them to class and use them. Be confident, know that your experiences are valued and useful in my class.

This belief is broadly shared in the UTEP community. The UTEP EDGE philosophy is spreading on campus. Check out the Bienvenidos campaign!

Focus on the real problem to be solved and give yourself credit (you can do it):

There are multiple questions that need to be addressed when approaching a programming question/lab. The obvious two that are usually at the center of our students’ work are What? and How? The “ultimate How?” will lead to a Java program that addresses the problem at hand. However, it is the last step, possibly the most “terrifying” to my students, but in fact, the easiest one if the earlier steps are taken properly.

So what are these earlier steps. They are the steps that consist in answering the following questions: 1/ “What?” and 2/ “How does that work in real life?” questions.

The “What?” question:

Before to rush into writing code that solves a problem, the most important thing to do is to make sure that you know “WHAT” needs to be done. Strategies that help at this stage of solving your problem include:

  • Asking questions (to your instructor, members of your instructional team); and
  • Rephrasing the problem in your own words (and checking with your instructor, members of your instructional team that you have it right).
The “How does that work in real life?” question:

At this stage in the CS curriculum, most problems can be illustrated by a real-life activity (sorting algorithms can be tried on playing cards, linked lists can be worked out with physical props like beads on a necklace or little-people toys). I have observed that 1/ recognizing how what is asked in a lab is similar to real-life situations, and then 2/ figuring out how we would approach this problem in real life are essential steps that contribute to developing problem solving skills.

As a result, any problem posed as a programming lab assignment should first be addressed as a real-life one. We should be able to come up with a no-jargon solution / solving strategy that can then be translated into Java (or any other language).

This step requires honesty: do not lay out a strategy to solving a problem that you would not use in real life. Ask yourself if that makes sense, if you could explain it to someone (a living one, not a computer). Until you can clearly explain how to proceed, in clear human terms, you are not ready to write any code.

Tip:as soon as you find yourself speaking in “create this loop”, and then “you have a nested loop”, and “call this method”, etc., you have strayed away from the path to solution.

Please take a look at the IDEAL problem-solving framework (resource 1 and resource 2), where:

  • I means Identify
  • D means Define
  • E means Explore
  • A means take Action
  • L means Look back

Persist:

Okay, let’s fast-forward a little. You are now done with the previous step and you are ready to code your algorithm / solution. What could go wrong, right? Well, although you are ready to code, many things could still go wrong: you do not remember the name of a given Java method, you tend to leave typos in your code, you forget semi-columns, etc. This is your last challenge before success. You cannot give up!

That’s the point: persist! Do not give up! The last muscle that needs to be exercised is the “debugging muscle”. This can be daunting if you get a lot of errors, but by exercising this muscle, you will soon develop an eye for errors: you will see them and know where they are coming from, making fixing them much easier. But to get there, you need not to give up and practice.  To help here, use an IDE that you are comfortable with. It makes coding and debugging much easier.

Finally, this phase is also one in which testing will come in handy (not just because it is a part of your lab requirements, but just because it is useful to making sure your code does what it is supposed to do: important, no?). Practice your Unit Testing skills: you will soon appreciate how useful and easy they will have become to you. It is well worth the learning curve.

In a nutshell:

It all comes down to: Practice, Practice, Practice… and focus your time and efforts where they need to be: the two fundamental questions as well as debugging/testing.

 

 

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.