SIGCSE 2019: Where the inspired inspires the inspirer

I attended my first SIGCSE Technical Symposium as a faculty member last week. I attended one other time, way back in 2010, when I was a graduate student. At that time, I delivered a Student Research Competition talk and poster about my thesis work related to small group development as it relates to software development teams. I also served as a student volunteer for the symposium. It was a great experience, but I only experienced part of the full event. This year, attending as a faculty member, I was able to experience the full gamut that SIGCSE has to offer, including being both giver and receiver.

One of the symposium co-chairs is a two-time graduate of Ball State University's Department of Computer Science. Manuel Pérez-Quiñones now serves as the Associate Dean of the College of Computing and Informatics at the University of North Carolina at Charlotte. I first met him when he returned to the Ball State campus a few years ago to deliver a keynote at a diversity research symposium. It was good to greet him again and deliver a “hello” from BSU.

Dave, Christian, and James

I was fortunate to have a workshop proposal about specifications grading accepted for presentation Wednesday evening, at the start of the symposium. (I've previously posted about specs grading.) James McGuffee (Christian Brothers University), Christian Roberson (Florida Southern College), and I jointly authored this proposal, and I am indebted to their help making it a reality. The material we presented resonated well for the thirty-plus workshop attendees, and I believe we made a few converts that evening. We had lots of great questions and discussion, with many attendees staying well past the 10:00 PM ending time discussing possible ways to implement specs grading in their courses. All in all, it was a great way to start the symposium off on a high note.

I enjoyed the keynote presentations. Marie desJardins (Simmons University in Boston) focused on inclusion in computing, ultimately discussing these “Five Pernicious Myths.”

“He was born to be a computer scientist.”
“Computer scientists are… {insert stereotype here}.”
“Anybody can be a computer scientist—girls just don’t want to.”
“It’s a joke—don’t you have a sense of humor?”
“’Diversity programs’ are just political correctness.”

Check out her presentation slides for a wealth of information and resources.

Gloria Townsend (DePauw University) provided a top-ten list that identified the most effective strategies used at DePauw to recently award 47% of their computer science undergraduate degrees to women. Her list included these items, many focusing on women:

10.  Celebrations
9.    Networking
8.    ACW-W chapter
7.    Mentoring
6.    Role modeling
5.    Outreach
4.    Content preview
3.    Social activities
2.    Female CS1 teachers
1.    Encouragement

Mark playing a ukulele

Mark Guzdial (University of Michigan) delivered a keynote in which he posited that “teaching programming as a way to express ideas, communicate with others, and understand our world is one of the oldest goals for computing education,” and that “Computer Science was invented to be a tool for learning everything else.” His justification can be found in his presentation slides. At the end, he gave us a call to action to find our allies and grow the community, and to invent, mutate, and evolve. His blog is well worth your time, so take a look.

I first met Mark when he chaired my paper session at ICER 2010 in Aarhus, Denmark. This was my first international academic conference. To put things into perspective, I started my first semester of full-time teaching at a university a few days after the conference. I presented my thesis work related to small group development as it relates to software development teams. After collecting five years worth of data, I turned it into an ACM TOCE journal article. If I recall correctly, my table-mates for dinner that evening were Mark, Beth Simon, and someone from NSF, whose name I have long since forgotten. Talk about being out of my element! But they were all very gracious, and it was a great dinner. Beth and I talked about peer instruction and the use of clickers. I started using clickers that fall, but it was three more years before peer instruction made its way into my classrooms.

I attended a variety of paper presentations and a workshop. Since this post is already lengthy, and I have one more big thing I want to share, I’m going to skip the details of the papers and the workshop. If you really want to know, ask me about them.

But wait; there's more...

My two presentations served as bookends for my symposium experience; I started with the specs grading workshop and ended Saturday morning by presenting a poster about the CS1 Art Show I’ve been coordinating for six years. For much of that time I anecdotally knew the show had a generally positive impact on our students, the department, and how others view us. This past summer I started collecting data, and now can more formally make that claim, with data to back it up. My poster presented some of that data and described the details and logistics of producing the art show. Included were student and judge comments.

I talked with a dozen or more people during my two-hour poster presentation who seemed genuinely interested in doing something similar with their own course. I remember one person exclaiming “This is exactly what I’ve been looking for!” All these interactions provided a wonderful affirmation that I did something good. But there were three visitors, in particular, who but me over the top, providing a great way to end my symposium experience.

In the fall of 2013 we started using the media computation textbook authored by Mark Guzdial and Barb Ericson. That same semester, I was inspired to hold an art show based on collages our CS1 students were creating for one of their course projects. The idea originated from an article by Beth Simon and Leo Porter about a similar event they produced. I took their idea and modified it to work in our environment.

Fast forward to a few days ago. I wondered if Mark, Barb, Beth, or Leo (all of whom I knew were present at the symposium) might be interested in my research about the art show, so I sent them all a message letting them know I was presenting my poster Saturday morning. They all expressed interest, indicating that they’d try to drop by my poster session, but some of them indicated they had busy schedules. As such, I wasn’t holding my breath.

To my delight Mark arrived and talked with me for 10-15 minutes. While reviewing the presented data, he seemed excited about how learner-centered and engaging the whole art show process is. After he left, Barb arrived a few minutes later. I was talking with another individual at the time, but she very patiently waited until they were done, spending time reviewing my poster. She also provided lots of encouragement about the art show project.

Image by rawpixel.com

It was getting close to the end of the poster session when Leo arrived. We talked at length about the logistics of how I run the show. The more we talked, the more excited he became, and the more questions he asked. I could see a light bulb starting to glow. Now remember, Leo originated the art show idea with Beth when he was serving as a Teaching Assistant at the University of California, San Diego (UCSD), and operationalized it while at Skidmore College. But, after moving back to UCSD, he was faced with very large class sizes, and dismissed the possibility of continuing the art shows. Now, after years away from the art show, he was seeing a way to make the process scale to larger class sizes. Maybe he could produce an art show with large class sizes at UCSD. The light bulb was definitely on at this point, and that made me very happy. What a way to end my SIGCSE Technical Symposium experience.

The inspired (me), had just inspired the inspirer!

Lilly Conference reflections: 2018 edition

I spent the last three days at the 38th Original Lilly Conference on College Teaching at Miami University in Oxford, Ohio. This is the fourth time I’ve been able to attend this conference and have been privileged to present at the conference all four times as well. If you can afford the time and money, I highly recommend attending this conference held the weekend before Thanksgiving every year.

At my first Lilly (2013), I presented a poster with three of my colleagues (Rebecca Pierce, Lynne Stallings, and Petra Zimmermann) titled “Classroom Interaction Redefined: A Multidisciplinary Perspective on Moving Beyond Traditional Classroom Spaces to Promote Student Engagement.” We translated this into a journal article, which was recently published online.

In 2016, I talked about helping computer science students explore the issue of lack of diversity and inclusivity in our educational programs and profession. The last two years, I’ve talked about my experiences combining specifications grading with learner-centered teaching. I've blogged about specs grading here and here.

Every time I’ve attended Lilly, I’ve come away from the experience rejuvenated. When you spend time in conversations with others excited and interested in finding the best way to teach, how can you not become excited yourself? The conference attendees are a very friendly group of people. One has a sense of attending a homecoming and getting reacquainted with old friends when one attends Lilly.

Rather than try to detail everything I absorbed at the conference this year, I’m simply going to provide a list of very briefly annotated quotes I wrote down while listening to presenters. I’m not going into depth partly because I don’t have the time to do so right now, and partly because I’m yet to fully process most of what I experienced. They are presented here in the order in which I experienced them.

• “Get more sleep.” We have to have adequate sleep for our brains to make memories.
• “We can't solve our problems with the same thinking we used to create them.”  Time to think outside of the box.
• “Give authority to students and be prepared to be amazed.” I’ve had this experience many times, as recently as a week ago with honors colloquium students.
• “Memorizing is what you do when something doesn't make sense.” To truly learn something, it has to make sense.
• “What would students do if we gave them wrong or missing instructions?” Should we do this to make them think and question?
• “Students must have past knowledge to which they can connect the new information we give them.” Our brains store new information by attaching it to previous knowledge and experiences.
• “Test for what you want your students to know a year from now.” If it’s not important enough that you want the student to know it a year from now, why test them on it? What does it matter if they know it now?
• “Peer feedback should be thought of as reciprocal teaching, not an evaluation.” This changes the nature of the conversation.
• “Flipped learning may not be evidenced by short term assessments gains but will be reflected in long term knowledge.” Learners can cram for a test and do well but are much less likely to remember it later. True learning is for the long term.
• “We can’t change what we cannot see.” If we don’t know there is an issue, how could we know it needs changed? We have to look and observe.
• “What are the things going on in our students lives? How might those things affect their learning? How could it change our teaching if we knew?” We must do more than simply teach content.
• “Everything we do is a rehearsal for the future.” Extremely few things are ever done only once. Always strive to do better.
• “Impatience is the enemy of empathy.” Take time to understand.
• “Grades should be indicative of the quality and quantity of learning.” The key here is measuring learning, not testing.

Share your thoughts below. What quotes resonate with you? What ones raise questions? Do you find fault with any of them?

Popular achievements in CS 222

One of the assessible items in CS 222 (Advanced Programming) is something we call achievements. Achievements are designed to encourage student’s independent exploration of relevant course topics they choose from a provided list. My colleague, Paul Gestwicki, introduced these into the course many years ago, and I’ve chosen to keep them. Most achievements are designed to be individual exercises, although some may be attempted by small groups—usually pairs, but potentially an entire final project team.

Each student may earn up to four achievements during the semester; they must complete four if they expect to receive an A for the course. To encourage planning, a student may only submit one achievement claim per week. Students make achievement claims by sharing their artifact in a document in the course’s shared Google drive, to which they have write access, but is closed to anyone outside the course.

Every semester or so, we review the list of available achievements, adding a few new ones, while dropping others. We substantially changed the list after the fall 15 semester, but there is a core set that has remained on the list since. The achievement options have included the following items.

• Campus Leader: For serving your campus community. Help lead or organize a campus club or event that is relevant to our course objectives. Write a reflective essay about the experience. (Added fall 2017)
• Capstone Connector: For investigating the senior capstone. Interview a Ball State University Computer Science capstone team about their project. Write an essay describing the project, its client, and the tools and techniques used by the team.
• Community Connector: For engaging with alumni. Interview a Ball State University Computer Science alumnus about the essential questions of our class. Write an essay about the experience.
• Crystallizer: For being principled about software development. Read 7 Properties of Highly Successful Projects from Crystal Clear with your team before an iteration. Document how you will abide by these principles during the upcoming iteration. At the end of the iteration, write an essay reflecting on the experience.
• Didact: For sharing discoveries. Give a five- to ten-minute presentation to the class to explain something you have learned this semester that is outside the required work. Share any slides or handouts you create in our shared folder.
• Diversity Seeker: For discovering we’re too much alike for our own good. Search for reasons (supported by data/research) why the CS profession, and/or our CS major students are not diverse (based on gender and ethnicity). Identify potential actions that can be taken to make the Computer Science student body more diverse. Write an essay summarizing what you have found. Describe practical steps you believe we can take so that our CS Department will have an environment where all students feel welcomed and included.
• Fair-Minded: For exploring future opportunities. Attend the Cardinal Job Fair, or an equivalent, pre-approved event. Speak to representatives from at least three companies. Write a reflective essay on the experience. (Added fall 2017)
• Filmmaker: For using video production skills to help our community. Create and share a video to help students learn tricky concepts from a 100- or 200-level Computer Science course. I must approve the topic ahead of time.
• Jammer: For making something delicious. Participate in a jam or hack-a-thon event. Share your experience in a short reflective essay, including your product or a link to it, as appropriate. (Added fall 2017)
• Judge: For evaluating art and code. Participate as a judge for the CS 120 All-section Art Show. Write an essay about your experience, including a reflection on how your coding has changed since you were a student in CS 120. (Added fall 2017)
• Open Source Contributor: For contributing to the commons. Contribute to an open source project. Contributions can take many forms, including bug reports, documentation, or source code, for example. Write a reflective essay about the experience, including links to your contributions. (Added fall 2017)
• Reflective Practitioner: For learning from failure. Consider one of your failures from this course and write a postmortem about it. Use the format described by Fitzpatrick and Collins-Sussman, explicitly labeling each step.
• Rereader: For discovering once is not enough. Reread a minimum of four chapters of Clean Code. Write an essay reflecting on what you (re-)learned by reading it again, and why you feel you missed it the first time you read the book. (Added spring 2017)
• Seeker: For learning from a community of practice. Attend a Computer Science Department Colloquium, Google Developer Group Muncie, or other approved presentation, seminar, or conference. Write an essay in which you share your experience and tie it into one or more of our course's essential questions.
• Studious: For learning how to learn. Read Bill Rapaport's How to Study: A Brief Guide and then write a study plan for this course, including a grade goal and assessment plan.
• Third-Party Librarian: For being pragmatic about reusing features. Meaningfully incorporate a third-party library into your final project. Describe the library you are using, why you chose it, and how it is used, using examples from your project. (Removed after summer 2016)

The following table presents statistics from the most recent six semesters I’ve taught the course. I find it interesting to look through the table to see what is popular (and what is not). For example, considering all semesters, the Reflective Practitioner, Diversity Seeker, and Crystallizer achievements have clearly been the most popular. Looking at individual semesters, the Rereader, Seeker, Studious, and Third-Party Librarian achievements have also been very popular.
 

As mentioned above, achievements are designed to encourage student’s independent exploration of relevant course topics. Even though the Third-Party-Librarian achievement was very popular, we chose to remove it because the projects being assigned in the course were requiring the use of libraries. As such the achievement was doing little to cause a student to explore a new topic.

A few of the recently-added achievements have proven to be quite popular. In particular, the Fair-minded, Judge, and Rereader achievements appear to be gaining a strong foothold. I suspect some of them will creep into the most popular list within a semester or two.

Five achievements (Campus Leader, Didact, Filmmaker, Jammer, and Open Source Contributor) have generally been the least popular. We have chosen to leave these as options for students to complete so students with a particular interest or skill in one of those areas will have something tailored for them.

Lastly, I’ve found the number of achievements students choose to complete interesting. While a great many students do complete four, the majority do not. As shown in the table, the average for all semesters is just over three completed achievements per student. Due to the one submission per week limitation, and their lack of planning, some students simply run out of time to get all four submitted.

I believe the achievement system is meeting its intended purpose within the course. I will find it interesting to revisit this a year from now to see how the popularity of individual achievements has changed.

What we learned in CS 222: Spring 2018 edition

I've had the pleasure of teaching the CS 222 course since fall 2015. Having just started to blog last fall, last December was my first opportunity to blog about the end-of-semester activity we conduct in this course. This blog entry will report on this spring's course.

The final exam process for CS 222 consists of three parts. First, the students are asked to list everything they can think of that they learned--directly or indirectly--because of their participation in CS 222 this semester. Once the consolidated list is compiled (and cleaned of duplicates), each student has a limited number of votes to cast to identify the items they feel are the most significant. And lastly, each student then selects one of the items which received the most votes and writes a reflective essay about how they learned that item.

As we cleaned the list, we decided to place some individual items under a heading (e.g. Clean Code); it was the heading that could then be voted for. The consolidated list contained 97 items (after creating these consolidations and removing duplicates). Each student had seven votes to cast for the items they felt were the most significant for them. Because of a tie for seventh place, we included eight items in our "Top N List," which ended up including these items (votes shown in parentheses):

• Clean Code: Best practices of code structure (23)
• Test-Driven Development: Using test classes to guide production code (22)
• Git (12)
• Object Oriented Programming Model (9)
• Behavior Driven Development and User Stories (9)
• Stages of group development (Forming, Storming, Norming, Performing, Adjourning) (8)
• Empathy cycle (acceptance testing) (8)
• Plan and track your work (8)

The students in the fall 2017 section of the course developed this list:

• Clean code techniques (15)
• TDD (15)
• Stack overflow (14)
• It’s easier to take the time to write cleanly than to write dirty code and fix it later. (8)
• Code is like art. Anyone can look at code and call it beautiful, but it’s rare to find someone who can tell you why. (7)
• Time-management is a key factor in a lot of things (7)
• Consider what the needs of the end user are when developing functions, rather than developing functions based on satisfying your own goals for your application. (5)
• Navigation of GitHub (5)

Comparing the two lists, I see many similarities. Both lists include references to clean code, TDD, Git, and empathy/considering the users' needs. Clean code and TDD are major themes of the course, both of which are completely new concepts to the students. As such, they struggle with them. Similarly the use of Git and GitHub is new to virtually all students, and causes its own challenges, until they take the time to figure it out. The empathy theme comes from a discussion about a design cycle model a few weeks before the end of the semester. Planning and tracking work, and time-management are related items on each list, but have a bit different focus. Few students have had to manage a project that lasts more than a few days, so it is no surprise this would make it onto the list.

New to this year's "Top N List" is object oriented programming (OOP), user stories, and stages of group development. OOP terminology was on last fall's master list, but only received four votes. User stories received one vote last fall. Stages of group development was mentioned last fall, but did not receive any votes. It is rewarding to have it make it onto this year's list, because I added this topic to the course when I started teaching it. Noticeably missing from this year's "Top N List" is Stack Overflow, although is did receive six votes, so it was close.

There were a few items that I found interesting, but didn't receive enough votes to make the "Top N List."

• How much fun and how rewarding teamwork can be
• What I enjoy working on versus what I don’t enjoy working on
• Implementations are almost always more complicated than they appear at the surface

I like the that a few students now believe teamwork can be a positive experience. The fact the it didn't make the list could be that most students had already figured it out, or maybe they didn't experience the great teamwork these students did. It is always good to know what brings you joy, and what does not. The few students that voted for that item may well save themselves some grief in the future. The last item relates to the "plan and track your work" item which did make the list. Again, few students have had to deal with a "large" project, so there were lots of surprises awaiting them.

Comparing the course grades of this semester's students to those of the fall semester, the grades dropped slightly, though not what I'd consider significantly. Percentage wise, there were fewer Bs, more Cs.

	Fall 2017	Spring 2018
A	42%	42%
B	48%	42%
C	10%	16%
D	0%	0.0%
F	0%	0.0%

Last fall, I started using specifications grading for this course, but the assessable items did not change--only how they were evaluated. I reflected on my experiences with this transition in my previous blog entry. I continued with this method of grading this semester as well. The drop in grade for a couple students can be attributed to one student not "carrying their weight" within their team, and thus was rated low on the final project (which had a significant impact on their course grade), and another student simply not submitting much work, other than the projects.