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.
