Showing posts with label beginning programmers. Show all posts
Showing posts with label beginning programmers. Show all posts

Sunday, May 19, 2019

The empathy I gained while traveling

Picture of train ticket and a towel with "Don't panic" written on it.
The towel was a gift from a student. I take it on all my trips now.
Do you remember what it was like to first learn the body of knowledge which ultimately became your profession? So much of that initial learning is totally second-nature to us now, and we don’t even think about the fact that there was a time when we didn’t know it. We may have even forgotten how much we struggled to learn what seems trivial to us now. I suggest we need to have some empathy for our students' struggles.

Stay with me, while I relate a personal story to you. I’ll come back to empathy in a bit.

My wife and I have traveled to England, Scotland, and Ireland a few times, and thoroughly enjoyed each for many different reasons. Aside from the normal logistical challenges that arise, we found the trips and conversing with the locals rather easy. Obviously, the primary language spoken in England is English (although some of the words do have different meanings), but even in Scotland and Ireland, it is easier to converse in English than you might think.

Bayeux, France - Canal that runs through town
Bayeux, France
Last summer we ventured off of the islands onto the continent for our first time, traveling to parts of France and Germany for two weeks. Neither my wife or I speak French or German. We were assured by friends that—at least in the larger cities—this would not be a problem for us, and mostly that was true.
Bayeux, France - View of street from our apartment
View from our apartment in Bayeux, France

We started our visit to France in Bayeux, an old small town in Normandy on the northwestern coast. It is largely a tourist town, with a major attraction being visits to the various D-day and Normandy landing venues in the surrounding area. We stayed at a great Airbnb apartment in a multi-centuries-old building in the center of town. Being a tourist town, we had very few issues communicating with others. We enjoyed our time there and would have liked to have stayed a couple more days, but alas we had other reservations in Paris.

Our apartment in Paris, France
We boarded a train bound for Paris, where we had arranged to stay in another Airbnb apartment. This one was in Northeast Paris, far out into the residential suburbs. This was definitely not an area which catered to tourists, but it was wonderful to see this part of Paris as well. The apartment was great (complete with a washing machine, but no dryer), and was conveniently located just a few blocks from a Metro commuter train stop, which allowed us to get most anywhere we wanted to go. It provided a very cost-effective and pleasant way for us to stay in Paris.

By the time we arrived at the apartment the first evening, it was time for dinner. We also planned to eat our breakfasts in the apartment each morning and make our lunches to take with us each day. With a bit of research via information provided in the apartment by the owners, we figured out that there was a community square a few blocks from the apartment which had a few restaurants, but more importantly, a grocery store. Off we headed on, what seemed to us at the time, a simple mission—get dinner and buy groceries for the week.

Paris, France - Eiffel Tower
Paris, France - Eiffel Tower
Paris, France - Notre Dame Cathedral
Paris, France - Notre Dame Cathedral
Now remember, we don’t speak French, and we’re in a residential area of Paris, where it is unusual to have lots of tourists. We hadn’t realized that yet, however. Since arriving in Paris earlier that day, we’d spent the afternoon in the center of Paris, with all the other tourists, and store clerks who spoke English well enough to communicate with us. After walking a few minutes, we arrived at the square, and located a viable take-out restaurant for dinner. We entered and proceeded to try to figure out what we wanted to eat. All of the signage was in French, and the workers didn’t speak English. Did I mention that we don’t speak French? Fortunately, there were pictures, and we eventually got something bought and took it out to sit in the square to eat. We both enjoyed what we had for dinner, but I’m still not sure what it was I ate that night. We were starting to realize we weren’t in Kansas anymore!

Next task: buy groceries. We entered the store and it looked encouragingly familiar; aisles of packaged food on shelves, and lots of fresh, unpackaged food. But again, no English signage, and of course the package labels are all in French. And as a reminder (wait for it…), we don’t speak French. Long story short, what should have been a 10- to 15-minute jaunt into the store to pick up a few breakfast and lunch supplies, along with other miscellaneous items turned into nearly an hour excursion. Google translate quickly became our friend! We successfully bought everything we needed, but it took us way longer than we expected it to. By the end of the week, I was recognizing a lot of French words and understanding what they meant. I was somewhat surprised how often I could make a reasonably correct guess about a French word because of an English word being (somewhat) similar.

I felt a bit isolated after my experience that evening. I realized that if I didn’t know what something meant, I was going to have to ask questions. But if I didn’t know how to, or what questions to ask, how could I do that? I did find that the local residents were very willing to help me understand, as long as I was trying to understand their language and use it when I could. Don’t get me wrong, I thoroughly enjoyed my time in France (and Germany), but this was my first time traveling when communication had been a challenge for me. I was experiencing something new and unfamiliar, and had to work through it.

Paris, France - Painting of "hieroglyphics" on the wall in a Metro commuter tunnel
Paris, France - Painting of "hieroglyphics" on the wall in a Metro commuter train tunnel
As I reflect on the experience I had that evening, I wonder if it is similar to what our students experience at the start of our introductory courses. They are being immersed in a topic they know little or nothing about. They have little context to which they can attached their new knowledge. We often use new terminology, or use their familiar words in different ways. They may know they have questions, but don’t believe they know enough to ask us questions. As someone who teaches an introductory computer programming course, I’m asking students to learn new concepts and to learn a new (programming) language, complete with its own (unusual) punctuation.

I came back last summer with a renewed appreciation for (some of) what it means to be a new student. We teachers need to remember that we haven’t always known everything we now know. There was a time we struggled to learn it, and that is the same struggle our students are having now. If we are to be effective guides in the learning process of others, we need to remember those first days when we were learning the material which we are now helping others master.

We need to have empathy and remember what it’s like to be in a foreign land and not know the language. How can we reach out and help these intrepid travelers we call students? Share your ideas below.

Friday, February 9, 2018

Of programming projects, specifications grading, students dropping my course, and Charles Dickens



With apologies to Charles Dickens… It was the worst of days. It was the best of days.

Yinn Yang symbolMy day started by learning that a student had dropped my CS 120 course. Yes, I’m usually a bit saddened when this happens, but I understand there are lots of reasons students drop a course for which they’ve enrolled, and that most of those reasons have nothing or little to do with me. But this time it was different; the initial reason she gave to me for her dropping the course was how I was grading her work. I was particularly saddened and discouraged that I appeared to be the major reason for her dropping the course. Further, since there are few females who enroll in computer science courses, I really like to keep the few who do enroll. To think I might have chased one away was unacceptable to me.

I am utilizing specifications grading for the first time in our CS 120 course this semester. (Read my previous discussion of specifications grading in a different course.) This course serves as our first introduction to programming for our students. I am evaluating most assessable items in the course as complete/incomplete—either they fully met the detailed specifications I provided to the students, or they did not. I am evaluating the outside-of-class, work-by-yourself projects based on an A-F scale, where students must complete certain specifications to earn a given grade. The better the grade, the more items that have to be successfully completed. However, the highest incomplete specification determines your grade.

In the instance of this student, she completed nearly all specifications correctly, and would have received an A, except for two of the lower-level specifications which were required for a grade of C. As a result, I recorded a grade of D for her, as I described would happen in the project specifications document. The items she did not complete should have been relatively easy to complete; that’s why they were at the C grade level. She took exception to this, saying her program generated the correct answer, so therefore she deserved an A, and felt it was totally unfair to receive a D. Further, she stated that she was thinking about dropping the course. I do have some empathy for her stance; it does seem a bit unfair. On the other hand, had she paid a bit more attention to details, she could have easily earned an A. Further, I’ve provided for this sort of situation by providing every student four Oops Bits at the start of the semester. These Oops Bit can be used to resubmit a variety of assessable items which are not completed successfully on the first submission, or can be used to gain an extra day to complete an assignment.

In an attempt to try to help her understand my rationale for establishing the grading for the project in the way I did, I asked her to consider this analogy.

What if you were an excellent employee, and there were few people that could do your job better, but you had a hard time showing up to work on time, maybe even missing some days altogether. Most employers would not be willing to keep you as an employee—even though your work was excellent when you showed up—because they couldn’t depend on you showing up, a fundamental quality of a good employee. They would be more likely to retain the employee they could depend on, even if their work quality was a bit lower.

Up to this point, our conversation about her grade was all via e-mail. I encouraged her to meet with me in person to discuss the situation further, and she agreed. We met yesterday and had a relatively pleasant, healthy conversation for nearly an hour about specifications grading, and how I had structured the specifications for this particular project. One thing I asked her to do was to arrange the items in the project specifications into what she considered to be a better set of requirements for each grade. My intent in asking her to do so was twofold: I was truly curious how a student would arrange the list, and I wanted her to critically think about what qualities of the project justified an A versus a B, etc. She obliged and came up with the following list. The first two columns in this table indicate what is required for a given grade. All items below a particular grade are required as well. If any of the items marked as a grade of D are missing, a grade of F would be recorded. The first column is how I organized the list, and the second column is her ordering. (I’ve arranged the list based on my specifications for the project.)

My grade category
Student grade category
Assessable item description
A
A
Program accurately creates all 31 possible versions of the shifted alphabet
A
A
Program accurately lists all 31 possible translations, based on character shifts of 0 through 30 positions to the right
A
A
At the end of your reflection paper, tell me to what this encoded message translates.
B
B
Program lists all 31 possible translations, based on character shifts of 0 through 30 positions to the right (correct or not)
B
C
Program uses descriptive function and variable names
B
D
Program capitalizes the input parameter value
C
C
Program is formatted/indented similar to the text book authors’ examples
C
D
ALL files for the project are placed into a folder named project0. Compress this folder. Submit this compressed folder.
D
B
Reflection paper completed and submitted according to specifications provided in Canvas
D
C
Program will run in JES
D
C
Program uses the character set provided
D
D
Program will load in JES
C

Program accepts one input parameter

I’ve highlighted the items where there was a difference in our ordering. The items highlighted in yellow are one grade different, sometimes higher, and sometimes lower. The darker highlighting are items with a difference of two grades, again in both directions. I find it interesting that most of the ordering is relatively similar. I also find it interesting to see what this student valued compared to other items.

During our conversation, she shared some about other courses she is taking this semester, and how none of them are required for her major, including CS 120. She is transferring to another university next semester, and is simply taking core courses and electives which will transfer. By the end of our conversation, I felt I’d made some progress, and asked her to give the course three more weeks before making a decision about dropping the course. This would provide her more time to experience the course, and sit for the first exam. By then, she’d have a good idea how the course was going for her. As we parted ways, I believed I’d see her in class today. Unfortunately, she did not attend, and I received word after class that she had dropped. 

Initially, I was rather discouraged to have a student drop my course because of how I am conducting the course, and specifically because of how I am grading. Upon reflection, and remembering what she shared with me during our conversation yesterday, I have come to realize her reason for dropping the course was much more than how I graded her project, and perhaps that was not even the major reason. She was taking an eighteen-credit hour load, had multiple demanding courses which are requiring significant amounts of time, and the courses are not directly required for her major. Dropping CS 120 likely bought her a lot of time to devote to other courses, and is not likely to have a significant impact on her college career. I likely would have made the same decision myself.

So, by now, I’m feeling a bit better than I was earlier in the day.

And then the student for my 5:15 PM appointment arrived.

This student is one who had met with me a few days ago because he felt he was struggling to understand the course material. When I sense a student is capable, but maybe just needs a bit of a push and assurance that they are capable—a shot of self efficacy—I will offer to set up a standing appointment to meet at the same time every week when they can come in and ask what ever questions they might have. Students are always welcome to meet with me anytime our schedules permit, but for some students, having a pre-scheduled time seems to make a significant difference in their progress. He was one of those students, and was arriving for his first appointment.

I expected that he might have a question about one of the recent activities we’d worked on in class. This was not the case. Rather, he came very prepared with a mental list of items and concepts for which he had questions, or felt like he needed clarification. We very productively moved from one topic to another, and I could tell, based on the type of follow-up questions he was asking, that he was gaining a much better understanding of the material. We worked through course material for nearly an hour, that very quickly passed—at least for me. The more I worked with him, the more he impressed me with how truly committed he is to learn and understand the course material. He was a total joy to work with.

So, was it the worst of days? Or was it the best of days?

I’m going to go with the best.

Sunday, October 29, 2017

Eat that elephant!

I once read a short book titled Eat That Frog! 21 Great Ways to Stop Procrastinating and Get More Done in Less Time. The author, Brian Tracy, mentions an old saying that claims:
 “If the first thing you do when you wake up in the morning is eat a live frog, then nothing worse can happen for the rest of the day!”
Tracy’s premise is that you should do the hardest or least-desirable item on your to-do list first, and then the others will flow more easily from there. It’s great advice that really does work (and which I need to follow more). In addition to this however, I believe there is another challenge that keeps many of us from moving forward, or even starting.

I’ve spent much of the last couple of days gathering files and creating a web page for the upcoming Ball State University Computer Science Ninth Semi-annual All-section Art Show, which displays the peer-selected collages created in our Computer Science 1 course. (I’ll likely write a post about that as a recap after the show.) We ask the students who are selected to be part of the show a few questions, one of which is “What did you find the most challenging about creating the collage?”

I always find it interesting to read the student’s responses as I assemble the materials for the show. There are usually a couple themes focused on technical challenges like getting pictures sized and placed where they want them in the collage. A non-technical theme that is always evident is “where do I start?” Three sample responses from this year’s show include:
“The hardest part, at first, was deciding where to start.”
“The most challenging part of the collage creation was figuring out what I wanted to do for this piece.”
“I had a tough time finding a starting point.”
There’s another old saying that asks:
“How do you eat an elephant?”
Dave with an elephant headThe answer is, “one bite at a time.” There is no way we can eat a whole elephant at once—even a baby one! But if we start taking one bite after another—given enough time (and a way to keep the elephant from rotting)—we can eat the whole elephant. So many of us get stuck, having no idea where to start, because we feel our task is too large, and thus impossible. All we see is an elephant we can’t possibly eat. We just need to take a moment to decide which bite we’re going to take first.

I see this time and time again with beginning programmers. I assign a project for them to work independently on, and some come to my office claiming they have no idea how to do the project, despite the fact they’ve been attending class and doing the work. I start by asking them if they can do “x,” and inevitably, they respond “yes, we learned that weeks ago.” So, then I ask if they can do “y,” and again get a positive response from them. Next “z?” Yep, they can do that too. By this time, they’re starting to realize they’ve completed half of the project, and maybe they can complete it themselves. They originally saw the project as a huge, impossible thing to accomplish—an elephant. I simply offered them little steps, which they already knew how to do.

So eat that frog, but don’t forget to start taking bites of that elephant on your list as well.