Category

Blog

Category

In previous blogs, I shared my philosophy of teaching and assessing my students. Namely, my assessing approach is not focused on an accumulation of grades but rather on the growth of my students, on the skills they develop and demonstrate throughout the semester, which empowers all my students to fail and recuperate from failure. Basically, I ask myself two main questions:

  • How can I best support my students (ahead and behind) growing and learning?
  • By the end of the semester, what skills have my students demonstrated?
How does that work exactly?

My approach is focused on outcomes rather than on performance on every single assessment. Students are allowed to fail repeatedly until they demonstrate their proficiency in the outcomes they have to meet to be ready for the next class in sequence.

What that requires is to give students plenty of opportunities to demonstrate these skills. If they are allowed to fail, they should be allowed to persist and eventually make up. So, similar skills need to come up in a variety of assessments throughout the semester. It is harder in some courses than in others, but harder does not mean impossible. It is important to keep our students’ growth in mind and allow them to demonstrate it.

Example 1 – Fundamental Course in Computer Science

Since 2015, I have always taught one of our 3 introductory courses in Computer Science (i.e., the incoming CS students course (CS1) or the next in sequence CS2). These courses (CS1, CS2, and CS3) are called the fundamental courses in the Computer Science curriculum. A lot of what is learned is cumulative: what is learned at the start of the semester will be used throughout the semester, even if later on, it may not be the focus of a more traditional way of assessing students. This makes it very easy to observe if a particular skill has been acquired, even if much later than when it was the original focus of the course. As a result, fundamental courses are particularly well suited for an assessment based on skills, not grades.

Particularly, it has happened several times that students in these courses passed with my way of assessing them, while they would have failed the class otherwise. More so, some passed with A’s while even with removing lowest grades assuming they would pass, they would not have obtained better than a B. This poses the question of what letter grades mean too. But this is a topic for another blog piece.

Example 2 – Graduate Course in Computer Science

I recently taught a graduate course on a more theoretical topic. The topics of the course were seemingly not cumulative. However, there was a common thread throughout all semester’s topics, and I made it the overarching theme that the students then got a chance to practice and practice again, in multiple settings, failing at first for the most part, but then making progress and “getting it”. That required a lot of planning, a lot of assessments, and time working with and supporting students outside of class, but the feedback I received was well worth it and along the lines of “Her teaching style is very original and effective. I know for sure that I won’t forget what she taught us this semester”, or “Sometimes it was difficult to keep up with the pace of the class, but Dr. Ceberio was very flexible and understanding that she trust in us to let us catch up later at our pace”.

In summary, it requires planning. However, anything good does. It is just a different type of planning. I am happy to connect with anyone interested in trying this out to guide them in the process.

How about work ethics?

This is a sticky point of my approach. It is true that my approach can be seen as a stark change from what students have been used to. I do not “threaten” them with grades (not that I mean to say others do, but rather that grades kind of threaten students into working – note that I do not say learning). Instead, I offer my help, I offer for us to work together and make students succeed. If students do not buy into this new approach, if they need someone to “lead with a stick”, well, this is not me and they may simply drift for a semester and fail. I am fully aware of the risk and a lot of what my instructional team does throughout the semester (my TAs and I) is to reach out to our students, to establish report so we can help them best. Clearly, my approach is not perfect. It is simply the least imperfect in my view, for the sake of my students’ development. The alternative to my approach comes with the risk that my students will not learn, that they will drop – even – when convinced failure defines them because this is what their grades tell them, and that they will not develop work ethics based on finding the joy of learning (and instead remain stuck on working for grades only, not for long-term learning).

There are multiple ways to implement this philosophy. This piece was to share a few ideas about how I go about it.

Where has the fun of learning gone? Where is the enthusiasm, the hunger for learning? The curiosity? All of these should be part of the process of learning. They are gone for the most part it seems. At least for now. I keep asking myself why? Why would someone who wants to study a given field not be excited about learning about it? Growing into the professional they want to become? What’s holding them back?

I have taught Computer Science for many years now and when interacting with students, their main conversation topic is grades. How am I doing in your course? How can I still pass your course even though I did very badly on this exam / quiz / lab / homework assignment? Rarely is the conversation motivated by their need for help on a side project, by their interest in discussing different ways to solve a given problem, ways beyond what we learn that would be more efficient, etc. It feels like most of my students’ focus is on grades, not on what they learn. The product of taking a class is a grade, not learning. My point here is not to blame my students for that trend. Rather, I want to share what I think may be an enthusiasm deterrent and propose a way to change things so we can refocus our attention onto teaching and learning.

Ever since students started to receive grades, but even more so since high school when students are graded left and right multiple times a week, each grade compounds (in different proportions depending on the subject) to make a final grade, which goes into the GPA calculation, itself playing into school ranking. Except for the fact that, in high school, students undergo many evaluations (and we could argue that each grade ends up not weighing enormously), each grade still plays into the holy grails that are the student’s GPA and class ranking. How, then, not to be afraid of a misstep, one that potentially compromises your GPA and makes you lose ranking. I do not teach in high school, so I can only speculate. However, I teach at the university level, where grades are not as frequent, and therefore a lot higher stakes. Each grade has the potential to make a difference between 2 letter grades (a big 1-point difference in terms of GPA). How to have fun in class when you feel under the pressure to always perform, on every single assessment? How to learn when the assessment of your learning and how it compounds into your final grade do not leave you space to fail?

In addition, let me bring into focus the mission of the institution where I teach: historically Access and Excellence, and now Access to Excellent higher education. Many of our students, because of our open-access policy, come to us under-prepared. They may not have had access to quality secondary education. Most importantly, they may not have had access to the kind of opportunities that provide purpose and drive to other students. Often, they have not had access to role models, and they may be the first ones in their family to pursue a higher education. Because or sometimes in addition to these, most of our students do need to work outside of school, to support their family (their children, but also, often, their parents and/or siblings). Nevertheless, at my institution, we believe that talent is everywhere and that despite their possible lack of preparation, their different backgrounds are assets, not weaknesses, and we have a passion for nurturing our students’ growth into whatever they have set their minds to, regardless of their prior academic path or experience. This mission is what has kept me at my current institution for almost 19 years now. I believe access and support are the right thing to do as they contribute to making society a better and more visibly diverse place.

Now, you can imagine that our students rarely have smooth semesters: between work hours that are changed or need to be increased (not to lose their job or simply because they need to earn more), their dependents who need their support, their difficulties to purchase course supplies and textbooks, it is impossible to expect our students not to miss an assessment or assignment, or more. Additionally, picture an incoming computer science student, one that has not been blessed with opportunities, one that has not had people around him or her instilling rigorous work habits and strong analytical skills. They start the semester and most likely will not perform great (of course some do). They may even take until mid-semester to really grasp both the concepts of being a university student and the content of the class well enough to be able to perform well on any assignments or assessments. However long it takes, I have always found it unfair to keep their grades on record and compound them into their final grade when we know, because of our mission, that some of our students will have a hard time. So, do we admit them (with a big smile) and penalize them at the first misstep (with a stick), pretending we did not know they may be needing more time to assimilate what higher ed entails and all that we are covering? I cannot do that. This is so hypocritical in my opinion.

The situation I described above, although more salient in incoming students, can happen at any time during the curriculum (admittedly more so in lower division than in upper division, but I would argue that it does not cost us instructors much to simply assume our students need support and to be kind).

So, what can we do? I asked myself the question a long time. To answer it, I reflected on what teaching means to me.

What’s the point of teaching a class? What do we want our students to demonstrate? What should students who pass our class look like? Should they be the students who passed each of our assessments to satisfaction from start to finish, or at least managed to maintain a decent (passing) average among all these assessments? This is the most common approach I hear about. Yes, there are some subtle variations: for instance, some instructors drop a predefined number of lowest grades. This is a step in the right direction, and it can alleviate some stress on the part of our students. However, I would argue that it is a blind post-mortem approach that does not allow for individually tailored support throughout the semester, the type of attention that can make a world of difference in our students who have until then not had role models and mentors around them. Regardless, what about our students who will need half of the semester to catch up on skills that needed to be brushed from secondary education or to understand what it means to be a college student and build the work ethics that is needed to succeed? Imagine that they take this long to catch up: by that time, even dropping a few grades here and there at the end of the semester will not be sufficient to “rescue” them. Should they have to repeat the class even if they demonstrate full understanding and command of the material by the end of the semester? I argue that they should not. Should we assess a student’s pace of learning or instead celebrate their actual learning and growth? I argue that we should celebrate their growth.

Here is what I advocate for: truly helping and supporting my students’ growth. Focusing on their growth, their skills, rather than on how fast they get there. My classes are a failure-safe environment (sadly only until the end of the semester when we have to part ways and provide a final assessment). Students are told that they can fail however many times they need, that assessments are simply the following: a way for them to check what I strive for them to develop into, an opportunity for them to demonstrate what they know, and if they don’t know it yet, a way for both of us to decide what’s next, how to help them best grow as a person into the professional they’d like to become. Given this, I expect my students to trust that I am their best advocate. I want them to realize that their grades do not define them (even in the event that they cannot pass the class, they can push through and make it the following semester). I want to remove their fear of failure associated to their fear of grades, so that they can focus on learning and improving. The skills they learn while doing this are invaluable (and not assessed): they learn to learn, they learn to persist, they learn to fail and try again until they succeed, they learn that this process is normal and that nobody can pretend otherwise. When they do, they can be curious again, without the fear of being judged for asking a question; they can be creative, without the fear of failing; and hopefully it makes them happy to be learning and growing.

Is it simple? Absolutely not. Gaining someone’s trust is not easy. I am asking my students to trust that I will indeed focus on their growth, not their ability to dance my little assessment dance at the rhythm I arbitrarily set for all to follow. I am asking my students to trust that their missteps in assessments are not going to be consequential, that they do not define them, that I will work with them to get better. It takes time. Some still come asking about their grades (I understand but try to explain what, instead, I am focusing on, while giving them some snapshot assessment – “If we were to conclude the semester today, where would you stand?” kind of talk). Changes take time, but I believe you are never wrong when you are kind and consider people and their needs rather than mere numbers.

Rewarding pace of learning is unfair, orthogonal to our institution’s mission (and I would argue, to any place of education), and ultimately, we need not lose sight of the fact that this is simply not something that will be required in the workplace. Curiosity, though, as well as perseverance, grit, creativity, and simply happiness are important characteristics of a valued (co-)worker. So why do we insist on focusing and somehow valuing everything but these in our teaching and assessment of so-called learning?

[https://twitter.com/bencichy/status/1197752802929364992?lang=en]

Here are some readings that inspired me or comforted me in my teaching philosophy changes:

  • Mindset: The New Psychology of Success, by Carol Dweck, Ballantine Books
  • A More Beautiful Question, by Warren Berger, Bloomsbury
  • Daring Greatly, How the Courage to be Vulnerable Transforms the Way We Live, Love, Parent, and Lead, by Brené Brown, Avery Publisher
  • Grading on a Curve, Why the Playing Field is not even when it comes to Grades, blog by Mary McNaughton-Cassill, in Psychology Today

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.