Summer Course Revisions: CS222 Advanced Programming

I always revisit my courses over the summer, but this year there are higher stakes than usual. Ball State has opted to change the calendar from 15 weeks of instruction to 14 weeks. There will be significant ramifications for curricula with long prerequisite chains such as my department has, but those problems will have to be tackled systematically later. For now, the immediate challenge involved shaving a week from an already packed semester. This coincides with two other major changes I have had in mind: reviewing the textbook and getting away from Canvas. I plan to give each a fair treatment in this post, although some details may be reserved for future writings or conversations.

My draft course plans are available online. Much of it is copied over from Spring for expediency. I would like to tighten up some of the lengthier sections, but for now, it will suffice. The projects will be posted when they are assigned, as usual. 

The Calendar

For many years, I used the first three weeks of CS222 to prepare students for the rest of the semester. This was followed by the two week project, leaving ten weeks for the final project. A few semesters ago, I expanded the introduction to four weeks, and this proved helpful, so I shaved a week off of the final project in order to keep two weeks for the warm-up project. To accommodate losing a week, I have decided to shave a week off of the final project. It will still be done in three iterations, and this means that the iterations themselves will be shorter. In turn, this means that we will spend a higher proportion of the final project on project administration (presentations, planning, retrospectives) rather than enrichment work.

It will have to be this enrichment work that is cut, and I have not yet made up my mind which two days will go. Most likely, it will be some of the practice exercises such as in-class code reviews or part of my week-long defensive programming exercise. I can move the "What We Learned" exercise back into the final exam slot, but then it becomes harder to use that exam as an objective measure of learning; it may turn out that I have to change the structure of the exam as well.

I am comfortable putting off some of these decisions. The second half of the semester is always more about my responding to the students' needs anyway, so I can wait until I meet them and see where their interests are.

The astute reader may notice that my draft course plans have no mention of achievements. I would not normally have one assigned until around the two-week project anyway, so for now I have left them off. Achievements are an engaging part of the class, and I love the idea of giving credit to activities that are normally out of the scope of a college course. However, it's also one of the easiest things to cut. Even though they use little class time, they occupy significant amounts of student attention. A week's worth? Perhaps. This is another decision that I am putting off until the last responsible moment, when I will have the most understanding of its implications.

A Book

The second edition of Robert C. Martin's Clean Code was released not long ago. It is twice the size of the first edition, and this alone had me concerned. The first edition is a classic, but it does show its age. Much of the criticism that is levied against it seems to forget to whom it was written twenty years ago. Still, not all the criticism is unwarranted, and this prompted me to look for alternatives.

One is The Pragmatic Programmer, which saw a refresh in 2019 with its 20th Anniversary Edition. I have always respected this book, and the new edition is strong. Re-reading it, though, I remembered how much it assumes of the reader. The tips are useful, but many of the details are left to the reader's experience-—and my readers lack experience! I noted a few particularly salient sections that I think my CS sophomores would benefit from, but I didn't see an easy way to use it the way I've used Clean Code.

The other alternative is Ousterhout's A Philosophy of Software Design. I got a copy of this book as soon as I heard about it, but I bounced off of it pretty quickly. The book presents itself as the sole source of design wisdom, which is already off-putting, but what really got me was Ousterhout's summary dismissal of Test-Driven Development coupled with an incorrect explanation of what it is. It's not hard to learn what TDD is, and if the author couldn't be bothered to cite a real source, then how much of the rest of the text should one take seriously?

Having put these two books aside, I decided to give a closer look to the new edition of Clean Code, starting with an inspectional reading. By golly, there's a 50-page appendix that recounts a conversation between Martin and Ousterhout! It was fascinating to read, especially since so much of it is criticism of the first edition. It inspired me to read the rest of the second edition, which does indeed address much of the criticism Ousterhout and others have levied against it. Martin is not explicit about why he devoted so much of the book to this conversation, and despite how much I enjoyed reading it, I wish he hadn't: the book could be more manageable and affordable without it.

The other primary reason for the book's being so large is that it now includes abbreviated versions of two of Martin's other books, The Clean Coder and Clean Architecture. There is some convenience to having this content here, especially since the three ideas are not orthogonal to each other, but again, I would have preferred a tighter volume. More books, I say, not bigger books. Doesn't that seem more modular?

The best improvement in the second edition is that Martin is more careful in his chapter about comments. Almost all of my students have misread his chapter as an admonition against all comments, even though that is not what he says. When I push students to re-read that chapter more carefully, they have always come out with better understanding. The new articulation tones down the rhetoric, and I think fewer students will need a re-reading in order to get the main ideas.

The section that I miss is the old chapter 17, which was a long collection of code smells and heuristics. There was a lot in there that was not in the rest of the book, and it was all bite-sized, small enough for a sophomore CS student to recognize and think about.

I look forward to seeing how students react to this new edition. Expect an end-of-semester report, as usual.

An Edupunk Reaction

I have long bemoaned the problems of Canvas, and it keeps getting worse. A full treatment of this may wait for another blog post or some kind of SIGCSE opinion piece. For now, suffice it to say that an experience last semester was the straw that broke the camel's back, and I'm going full edupunk.

The new course has been built using Astro, which allows me to compose large portions of the course plan in Markdown. This makes it much easier to edit code samples and assignment sequencing than my previous, lit-html-driven approach. This does not represent a major change since I have not bound my courses tightly to an LMS since experimenting with Moodle in the late 2000s. One of my lessons there was don't bind your course tightly to the LMS.

[EDIT: The following few paragraphs describe an approach that does not work but I have left them here for historical purposes. See the later post for notes on a working replacement.]

In the past, my students submitted work through Canvas even though it was usually created either on GitHub or on Google Drive. Now, I will be skipping the middle man entirely. I plan to collect assignments through a form, and I will track grades in my own Google Sheets document. I used Apps Script to create a simple web view of the data based on the authenticated user. I already have students register a Google Account with me so that they can access the shared drive, so there's no extra administration required here.

My sheet looks like this:

Sample sheet

That row of sample data is linked to my own email address for testing; the email address is redacted for public posting. When I go to the deployed app, I get this report.

Progress Report WebApp

The layout is a placeholder, but it already exhibits the strength of having been created intentionally for pedagogic purposes. There is no coloring, there is no "grade so far," and there is no confetti. It is a simple report that a student can review in order to make decisions about what to do next. My plan is to embed this as an iframe right in the course site, but I haven't done that yet.

Technical note: I was a bit confused about Apps Script and web deployment, so I want to keep a note here for later. After the first deployment, one needs to revise the existing deployment in order to maintain the URL, not create a new deployment. The interface here is very strange. First, select Manage Deployments from the Deploy dropdown, then use the pencil button to make the deployment editable, then use the Version dropdown to make a new version. The description then can be something like a commit comment. Upon saving, the latest version of the script will become the new live version.

As for grading, I will do this Google Drive or in GitHub. I already have a workflow on Google Drive in which I leave comments in students work. I had been then summarizing those comments on Canvas, but now I can simply do that in Drive and record the grade into my spreadsheet. Similarly, for projects, I would clone the project, evaluate it, and type the results in Canvas; now, I will instead do that on GitHub, posting my feedback as an Issue. Existing privacy options means that none of this leaks out to the public: I simply use the permissions features already baked into Google Drive and GitHub.

My approach separates the concerns of (1) presenting course details, (2) collecting submissions, (3) giving feedback, and (4) presenting a dashboard summary from which students can choose what to resubmit.

As mentioned above, expect a full report here on the blog at the end of Fall. I know, you're probably wondering, "When are you going to get back on the Small Web and host your own blog?" I think this would be fun to pursue, but I'm also weeks into a very exciting, non-course-related summer project. I look forward to returning to it, but I may ride this momentum into planning my Fall CS315 course as well.

One final logistical note, for my own future reference: Making these changes took me about four full-time days, not counting reading time. I had used Astro before, for my CS390 page last semester, and I had never used Apps Script. I wanted to track that here so I can come back to it, expecting critical discussion in Fall about purported vs. actual justification for calendar changes combined with the increased work required of faculty with respect to ADA requirements.

Reflecting on CS222, Spring 2026 Edition

I had a fun cohort of students in CS222 this semester. Each team designed a final project of the "connect to a Web service and do something with the data" variety. In many ways, their foibles and experienced were akin to past students, but something that stood out to me was how well they asked each other questions. It is not clear whether I have done something different to foster this; one possible factor is that I have improved the requirement that teams give a technical lesson as part of their presentations.

We cover a lot of ground in CS222, and so I am concerned that next time, I will have only fourteen weeks of instruction rather than fifteen. The university is changing the academic calendar as of Fall 2026, and it will be hard to find a week's worth of work to remove. Also, students coming in will have two fewer weeks of classroom experience programming; given that many students do not do much independent practice, this will have a significant effect on downstream courses. Coincidentally, I just got out of a meeting this morning where we talked about how much more we want to teach within the undergraduate major, and yet we will have eight fewer weeks in which to do what we are already struggling to fit in.

My course requires students to read and evaluate "project code," which is a term I define but that a majority of students don't understand. Either they don't read the instructions or they lack the ability to distinguish between code-for-learning and code-to-do-something. As a result, many of them look back on their own code that was just purely pedagogic; others find code on GitHub, which I recognize is a leap of faith, but they look at code that is just someone else's classroom or tutorial project. This leaps out to me upon inspection, but because they have only ever read pedagogic code, I don't think they recognize it. Hence, rather than just refine by definition, I think I need to point them toward specific examples of projects that are appropriate. I hate to do this because there is so much code out there and I want them to find projects that are interesting to them. Yet, despite this encouragement, almost no one has ever done that, so maybe that's a dream not worth chasing. I would need to set up some guardrails to prevent two students from evaluating the same block of code, which is also something I am not keen on. Perhaps I need to set up some kind of draft.

I have had a note in my planning spreadsheet for some time to remind students that a good way to think about SRP is responsibility to whom. Also, though, there's a second edition of Clean Code out now that I haven't read yet. I need to see if the new edition is worth switching to, especially around explanations of OO principles that often trip students.

My final note is about the final exam. Many years ago, it comprised only reflective questions, and those gave me an insight into the student experience. A few semesters ago, I was concerned about students blowing steam, and so I added a content question as well, to make sure students could express some of the fundamental class topics. One of these questions has been perennially challenging to articulate correctly. Essentially, the question is trying to see if students understand that they should be able to make a list of unit tests they have yet to write and that these should be SMART. The trouble is that if I remind them that each step has to be SMART, then I have given them the answer. What happens is that students will say that their first step is to "write some tests," for example. That is not wrong, but it also doesn't illustrate what I'm trying to get at. Relevantly, I think many student teams continue to struggle with this idea throughout the semester, that they should always have a goal to work toward. TDD is supposed to push them in this way, but in practice, many fall back on old habits of just plowing forward without discipline. So, I think this points toward two other action items for me: first, to use more class time to have them practice articulating what their immediate next steps are, like Kent Beck does in Test-Driven Development By Example, and also then to use a similar framing to ensure that they can do this individually, as an outcome of the class.

What we learned in CS222, Spring 2026 edition

I worked my CS222 students through my usual semester reflection exercise today. I gave them five minutes to write down everything they learned this semester that was related to CS222, then we set a timer for 30 minutes while they offered items and I wrote them on the board. For some reason, we only had nine people in class today, but these nine came up with 88 items. I was going to give then six votes (because ceil(lg(88))=6), but a student in the front agreed with me that five was more symbolic, so they got five votes to mark the items most important to them.

The distribution of votes was unlike any I have seen before, and this may be because of the low attendance. Two items rose quickly to the top, with five and four votes respectively, but the next classification were with two votes, of which there were six. After a brief reflection, I decided to seize the opportunity and go ahead and mark all eight of these as "top items" for use in the final exam. These items, and their vote counts, are as follows:

• Clean Code (5)
• TDD (4)
• Version control (2)
• Using an API (2)
• SRP (2)
• Coding with a team (2)
• Red-Green-Refactor (2)
• Always run all the tests (2)

There is clearly some overlap among these, but that is fine. I look forward to seeing what the students have to say about these topics in the final exam.

Amphibian-based grading

I have a friend, roughly my age, who studied architecture at Ball State as an undergraduate. He told me a story many years ago about his most formative interaction with the faculty. He asked his professor how he was doing in a class, expecting a quantitative answer. Instead, the professor drew a line: on one end, he drew an egg; on the other, a frog; in the middle, a tadpole. He pointed to a spot on the line and said, "You are here."

I tell that story to my students every semester when the question of grades come up. I recently shared the story with a faculty discussion group dedicated to improving teaching practices. Everyone who hears this story immediately understands that the professor has given the student valuable information—that this feedback is much more valuable than something like "86%" or "C+".

At the faculty discussion group, one of the participants asked us if we still had any marked-up papers from our own undergraduate years. I do not, though many did. She pointed out how modern undergraduates don't even have the opportunity to hold on to such things. All their interactions are mediated by technology; all their interactions have become transactions.

Yesterday, I recorded the podcast discussion around my essay for The Raised Hand. The other guest was the author of February's essay, which will be published in a few days. The moderator identified a theme between our essays: that there is an intrinsic danger to separating people with technology. Reflecting on the conversation, it strikes me that technology allows us to have a limited communication with people who are distant, but also limits our communication with those who are nearby.

Earlier this week, I graded my CS222 students' two-week project submissions. The explicit goal of this short project is to prepare students for the eight weeks of the final project. The short project integrates all the challenging ideas from the first four weeks, and so it is designed to help students figure out which of those things they really understand and which require more attention. How should such work be graded? I expect each team to miss some fundamental concepts in their project, often things like having clear names or following the Single Responsibility Principle. If a team misses one of these, should they get a low grade because the work is wrong or a high grade because they did what I expect? A low grade suggests that they have done badly, but they have done well, and a high grade means they have done well, but they actually misunderstand important concepts.

I end up giving them low grades because that feels like an honest assessment of where they are. What I really want is to show them how close they are to becoming a frog. Why am I giving them numeric grades despite having told them about amphibian-based grading?

After grading these projects, I always tell the students not to panic about the grades. I point out that in the course grading scheme, this grade will be dropped if they do better on the final project than they do on the short project. Everyone does better on the final project in part because the short project actually works: it shows them their weaknesses. But look at what I have done here: I have crafted a mathematical system, justified pedagogically, so that I can give grades to things. It's true that at the end of the semester, I need to have enough evidence to tell students where they are on the amphibian line. It is a line after all, and so letter grades can be interpolated over it. Yet, while a tadpole is in the pond, it is nonsense to say that it has failed to be a frog.

In my podcast discussion yesterday, my interlocutor described how an integral part of education is helping people develop well-ordered desires. The desire to quantify human formation is disordered. I did not become a professor so that I could make good Canvas experiences. I became a professor to kneel beside the pond and cheer on the tadpoles. 

I write this so that I will remember it.

Why I am not using GitHub Classroom

As I mentioned the other day, I have turned my attention to preparing for Spring's courses. I am on deck to teach CS222 in the Spring. It's a fun and challenging course to teach, and I've been thinking about whether there are some ways to streamline the student experience. This morning, I spent some time investigating GitHub Classroom. It wasn't the first time, and that's why I'm writing this quick reminder to myself about why it's not the right fit for me.

There are two things that keep attracting me to GitHub Classroom. The first is that it reinforces the use of distributed version control. Anything that gets students into the habit of using version control and making small commits is good. The other is that it leverages the power of Markdown, where a writer can seamlessly integrate different kinds of text into one document: prose and code live happily together. This forms a synergy with the first point, since it gets students to start to think about version controlling all the things. 

What specifically got me looking again at GitHub Classroom though was its support for feedback via pull requests. This would allow me to comment on an individual line of student work as well as the work as a whole. The shortcoming is that the writer cannot do the same. 

I need a student to be able to do three kinds of writing:

• Traditional prose
• Source code
• Commentary on specific lines of the source code

The writing environment has to allow a student to say that a particular section of code manifests a particular property. This cannot be done in source code comments because those comments are part of the code itself. Rather, I'm talking about a kind of metadiscourse that is at a different level of abstraction than the code. It cannot easily be done in prose either. This requires either interrupting the code with commentary or using a referencing system, such as line numbers. The latter is not terrible, but it pales in comparison to the approach I have used for years: using Google Docs' comment feature to comment on different parts of the document. Using this approach, both the student writer and I can evaluate the text. In fact, I wish I had one more level of abstraction: I would like to comment on the students' comments, not in a thread, but at another level yet. 

These qualities describe a writing environment unlike any I have seen. It would be an interesting HCI exercise to explore how one might interact with such a thing. One might start by looking at Google Wave (RIP) or Code Bubbles. In the meantime, I will have to keep using word processors like Google Docs that allow for the metadata stream of comments.

Updated postscript:

I was thinking about switching from Google Docs to Office365, but after that experimentation, I don't think it is fit for purpose either. It seems like Word insists that we are preparing documents that will be printed on paper, whereas Google Docs has long allowed for continuous, non-paginated documents. 

Reflecting on CS222, Spring 2025 Edition

This semester's CS222 class was unlike any other. My department is once again involved in a 1+2+1 program with a Chinese university, meaning that Chinese students complete their first undergraduate year in China, their next two years in the USA, and then their final year back in China, culminating in dual degrees. It was a vibrant program many years ago, and I am glad to see that it has come back. In the Spring semester, I had all of the eligible 1+2+1 students in my section, which meant that half of my enrollment consisted of domestic students and half consisted of Chinese nationals. I used to have some in my classes, but I've never had half of the enrollment in a class be international students before. It meant that on most days, there were more native Chinese-speakers in the classroom than English-speakers. 

One of the things I realized this semester is how often I speak in idioms, using phrases whose literal translations don't have an obvious meaning. For example, I told one of the teams that they had gotten "in a pickle." Then I laughed and wrote that expression on the board, gesturing to it and pointing out how ridiculous it was. I explained that it meant that the team had gotten themselves in trouble, possibly of their own creation. 

Unfortunately, moments like this were not as powerful as I would have hoped. Turning to my class, the domestic students were smiling as they contrasted the literal and figurative meanings of the phrase, but almost all of my Chinese students were as they always are: eyes glued to their monitors or smartphones. A guest speaker's presentation allowed me to sit in the back of the room and verify my suspicion about what was going on: most of the students had their phones propped up on their laptops and were running voice translation software. They were not listening to the speaker in any significant sense but reading in Chinese what it thought the speaker was saying. Occasionally, a student would switch to the laptop to visit a site or verify a term, but mostly they were reading real-time translated transcriptions of what was spoken. Not all of them did this, but most did. Some listened and took notes. One watched Chinese television. In this way, they are not unlike domestic undergraduates.

As usual, we completed a major project lasting about 8 weeks, and it was split into three iterations. I gave lengthy feedback to each team's submission, and sometimes teams even read and responded to it. An unusual frustration from this semester was that none of the teams really nailed the final iteration. I expect 20% or fewer to get the process right the first time, and then maybe 40% on the second iteration, and I usually get 60% or better addressing the fundamentals by the third iteration. I didn't have that this time: each project had something fundamentally wrong that I had already pointed out to them in a previous iteration. One conclusion from this is that I may need to rearrange or remove some of the elective content from the class in favor of more supervised in-class practice. Another consideration, though, is that I hadn't accounted for the extra labor done by international teams. I strongly encouraged—but did not require—international project teams, and most of the teams were. This means that in addition to tackling the significant challenges of the course, which include trying to change habits and conceptual models around programming, these teams were also dealing with language and cultural differences. That work is real work but it was outside the grading scheme. When I laid out their final grades yesterday, I decided to add a flat boost to the international teams to compensate them for undertaking the challenge. The resulting grades looked more appropriate to me for how well I knew the relatively small class. If I were to teach another class with such a high proportion of international students, I would need to revisit the question of whether an up-front incentive might be fruitful.

Course achievements were once again counted as regular assignments rather than their own category, as I did last semester. I do think this works better since it lowers the cognitive load of the course. My department currently has unprecedented growth in student organizations, and I need to bring back some of the achievements related to those. 

Counting achievements as a regular assignment has helped students navigate that part of the class, but I have yet to crack the problem that many students who ought to resubmit work don't do it. The idea is that students resubmit work until they have shown an understanding of it, and I am not sure what impedes students from doing this. It's possible that it's too liberal for Canvas to handle. Canvas won't tell them that something is due because they can resubmit any past assignment once per week. I suppose I could make a separate weekly resubmission assignment, which may solve the problem that some students fail to understand what "one per week" means. It feels like catering to their LMS addiction to me, but maybe it's what they need to help them through the challenging content.

I'm still stuck on the question of whether the content of the course would work well as a portfolio. Take a principle like naming: I could require students to submit in a portfolio an evaluation of something they wrote before 222 (which I do as an assignment) along with a sample of work that demonstrates their following the principles. Such a portfolio would be a powerful testament to what they have learned, but I've struggled to figure out how to pace such a thing. When I first started using achievements in CS222, all the assignments were from a grab bag of achievements, and in many ways, it was a portfolio-style assessment. As I put more emphasis on the project, I had to put that aside. I mention it here in part because, as I understand it, the 2026-2027 academic year will see a transition from a 15-week to a 14-week semester here. That will require me to blow up the course and rebuild it since there's no way I could just trim a few things out and have the rhythm still match.

The last note I'll mention here is something from my planning document, where I keep short notes about how things went and what I want to change the following year. This year, I had several teams undertake projects whose nature did not fit the requirements of the final project. The reasons undoubtedly come from a combination of background, culture, language, and generational differences. To cut to the chase, I realized I need to make it even more explicit that the final project needs to do something computationally interesting: being a clever interactive app is not enough. Some of the projects students wanted to undertake would have been great in a course on web and mobile apps, but they were not good contexts for exploring TDD for the first time.

I will be on sabbatical in the Fall, which means I'll be stepping away from this and all my other regular courses for a semester. It will be a good chance to catch my breath, and I won't have to carve out a week over the summer to rebuild the course.

What we learned in CS222, Spring 2025 edition

I usually like to make the What we learned exercise the last thing in the semester before the final exam, but this year, I had to move it up a little. I had two seniors come to class today to talk about their experience, and that meant that the remainder of our meeting was just enough time to do this exercise.

In 30 minutes, the students came up with 109 items. I gave each student six stickers, and they voted on the items that were the most important to them. These five rose to the top:

• Test-Driven Development (13 votes)
• Clean Code (11 votes)
• Programming intentionally (6 votes)
• Model-View Separation (5 votes)
• Canvas stupid (5 votes)

The students recognized that many of these top items are categories rather than particulars and so tended to attract more votes, but that's fine with me. The list is still remarkable in two ways. First, the third most important item to this population was programming intentionally. I don't remember this coming up as an outcome of the course before, but it's a fascinating sentiment. It is different from saying "We are using Clean Code" or "We are using Mob Programming." It is a statement of how we even go about making those kinds of choices, which is great. Maybe if I ever pull all my ideas together into a book of programming advice, I'll call it Programming Intentionally.

The other noteworthy thing on the list is the last one. It's the first time I remember a "joke" entry showing up as a top item. Any good class is going to have some funny items on the list, especially once they relax into the exercise of reflecting on the semester. In this case, "Canvas stupid" was my shorthand for a student's much longer comment, which was reflecting on my telling them how the way that Canvas deals with points is stupid, that you cannot deal with small numbers nor large numbers adequately. In my particular case, I believe I was ranting to the class about how I want to normalize scores into the [0,1] range, but how Canvas has hard-coded two decimal places. I even reached out to Canvas support earlier this semester to see if we could enable more somehow, and I was told it was hardcoded into their implementation. 

Reflecting on CS222, Fall 2024 Edition

I had a little break from teaching CS222 last semester as I wrapped up work on STEM Career Paths. I have not blogged much about that project, but you can read all about it in my 2024 Meaningful Play paper, which I understand will be published soon. In any case, here I want to capture a few of the highlights and setbacks from the Fall 2024 class, and I promise, I'm trying not to rant about Canvas more than I have to.

Regular readers may recall that I tried a different evaluation scheme this semester, which I wrote about back in July. In September, I wrote a detailed post about some of my initial frustrations with the system as well as a shorter one about how I felt my attention being pecked away. I don't want to bury the lede, so I'll just mention here that to compute final grades, I went back to my 2022 approach, the tried and true, the elegant and clean system that I learned from Bill Rapaport at UB: triage grading. Between my failed experiment this semester and the similarly failed EMRF experiment from last year or so, I feel like I'm looking for a silver bullet that doesn't exist. It reinforces to me, yet again, that I should really be running some kind of workshops for local people here to learn about what makes triage grading superior.

I still want to track some of the specific problems of the semester, though, so that readers (including future self) won't walk into them. First, I tried to set up a simple labeling system in Canvas such that I could mark work as being satisfactory, needing a minor revision, or needing a new attempt. I made no headway here in part because of Canvas' intolerable insistence that courses are made up of points. I talked with a respected colleague who is willing to toil over Canvas more than I about his approach, and he mentioned that he encodes this information into orders of magnitude, something like 10 points for satisfactory, 1 point for minor revisions, and 0.1 points for new attempt required. Combining these together, students get a weird combination of numeric and symbolic feedback. He acknowledged that it wasn't perfect. 

What I tried to do instead was to use Canvas' built-in support for grading as "complete/incomplete." Because that was all I cared about, I set the assignments to be worth zero points. When I used SpeedGrader, sure enough, the work was labeled properly. It wasn't until midsemester that I downloaded all the grades as a spreadsheet and saw that it only gave me the zero points. That is, whether the work was complete or incomplete was stripped from the exported data set. There wasn't so much data that I couldn't eyeball it to give students midsemester grades, which was facilitated by my recent transition to only giving A, C, or D midsemester grades (which are epistemologically vacuous anyway). 

It wasn't until weeks later that it dawned on me that my students almost certainly had the same problem: Canvas was showing them zeroes instead of statuses. Of course, all my policies for the course were laid out in the course plan, and I do not have any qualms about considering those to be the responsibility of my students. However, when the university's mandated "learning management system" actively disrupts their ability to think about the course, it becomes more of a shared responsibility. About two weeks ago, I went in and re-graded all of the work to use triage grading instead, which allowed me to distinguish not only between complete and incomplete, but also between things that were submitted-but-incorrect and things that were not even attempted.

One positive change that I made this semester was counting achievements as regular assignments. This made processing them simpler for me, and I suspect it made thinking about them easier for the students too. While they have a different shape than the other assignments, they are "assigned" in the sense that I expect people to do them to demonstrate knowledge. I also set specific deadlines for them, spaced out through the semester. This reduced stress from the students by providing clear guidelines, since they could still miss one and resubmit it later by the usual one-resubmission-per-week policy. It also helped me communicate to them that the intention behind the achievements is that they give you a little side quest during the project-oriented portion of the course.

I had a really fun group of students this semester, as I mentioned in yesterday's post. There were still some mysteries around participation, though. I had several students withdraw a few weeks into the semester without ever having talked to me. It is not clear to me if they decided the course was not for them or if they were simply scared. By contrast, I know I had at least one student who was likewise scared early on, but who stuck with it, and ended up learning a lot. It is not clear to me if there is more I can do to help the timid students lean toward that mindset. Also, despite excellent in-meeting participation, I had many students who just didn't do a lot of the assigned work. I have some glimmers of insight here, but it still puzzles me: how many times do I need to say, "Remember to resubmit incomplete work?" I hope that some of the simplifications I have made to the course will help streamline students' imagination about it, but more than that, I am thinking about the role of the creative imagination. I am sure that a lot of students come into this required sophomore-level class without a good sense of what it means to study, to work, or to learn. My friends in the Biology department recently took their required senior-level professionalism course, in which students do things like make resumes, and made it a sophomore-level course. I wonder if we can do something similar to help the many students we have who are not well formed.

What we learned in CS222, Fall 2024 edition

My students are currently typing away, writing their responses to the final exam questions for CS222. As per tradition, the first step was to set a 20-minute timer and ask them the list off anything they learned this semester that was related to the course. This was an enthusiastic group with hardly a quiet moment. They listed 130 items in 20 minutes. I gave them each six votes, and these were the top six:

• TDD (9 votes)
• SRP (8 votes)
• Code cleanliness (6 votes)
• DRY (6 votes)
• Git (6 votes)
• GitHub (6 votes)

Here are all the items they listed, together with the number of votes each earned, if any. There some interesting items here that point to interesting stories of personal growth. It was really a fun group of students to work with, even though several of them exhibited some behaviors I still cannot quite explain, such as a failure to take advantage of assignment resubmission opportunities.

• Flutter (1)
• Code cleanliness (6)
• TDD (9)
• A new sense of pain
• How to set up Flutter (1)
• DRY (6)
• SRP (8)
• Mob programming (2)
• Pair programming (1)
• Git (6)
• Version control (2)
• Future builder
• Setting up your environment
• Asynchronous programming (1)
• UI design (3)
• GitHub (6)
• Code review (1)
• Defensive programming
• Working with APIs (1)
• Model-View Layers (2)
• Teamwork (4)
• Better testing (1)
• What "testing" is (2)
• Explaining code with code instead of with comments (1)
• Understandable and readable code
• Agile development (1)
• Naming conventions
• Functional vs Nonfunctional Requirements
• User stories (2)
• Paper prototypinig
• CRC Cards
• User acceptance testing
• Programming paradigms
• How to write a post-mortem
• Resume writing
• Knowing when something is done (3)
• Debugger (1)
• Time management (3)
• Using breakpoints
• Test coverage (1)
• Modularization
• Distribution of work (1)
• Communication skills (1)
• Discord
• Dart
• commits on git
• pull using git
• Flutter doctor
• pub get
• Configuring the dart SDK
• Rolling back commits
• Checking out commits
• Going to office hours early
• Commit conventions
• CLI tools
• Don't use strings for everything
• Structuring essays
• Enumerated types
• Sealed classes
• Better note-taking
• Humans are creatures of habit
• Parse JSON data
• JSON
• Refactoring (5)
• How often wikipedia pages change
• Data tables
• OOP (2)
• URL vs URI
• One wrong letter can lead to the program not working
• How data are handled in memory
• FIXME comments (1)
• Widgets
• State management
• Encapsulation (1)
• Abstraction (2)
• Presenting projects
• Coming up with project ideas
• Reflection (2)
• pubspec management
• .env files
• Hiding files from GitHub
• Serializing JSON
• Personal strengths & weaknesses
• Falling behind sucks
• Software craftsmanship
• Work fewer jobs
• Finding internships
• Remember to email about accommodations
• Accepting criticism on resubmissions (1)
• Procedural programming
• You don't have to take three finals on one day
• Painting miniatures
• GitHub has a comic book
• Being flexible
• Dead code
• Holding each other to standards
• Bad and good comments
• Aliasing
• Reading a textbook thoroughly
• Rereading
• No nested loops (no multiple levels of abstraction)
• Using classes is not the same as OOP (1)
• SMART
• A bit about the Gestwicki family
• Places to eat in NY
• Getting ink to the front of an Expo marker
• How to clean a whiteboard properly
• New York Politics
• Data structures vs DTOs vs Objects (1)
• Conditions of satisfaction
• Setting up ShowAlertDialog
• Handiling network errors
• Handling exceptions
• Build context warnings
• CORS errors
• Semantic versioning
• Dealing with Flutter error reporting
• Test isolation (1)
• Don't make multiple network calls when testing
• Improving test speed
• Always run all the tests
• You can test a UI
• Writing 'expect' statements
• Running tests on commit
• Autoformatting in Android Studio
• Testing in clean environments
• Creating dart files
• Hard vs soft warnings
• Functioning on 0-3 hours of sleep
• Configuring git committer names

Paper!

I have a pile of things to grade, seemingly unlimited committee work to complete, and major decisions to make. I am having a bit of a stressful week. But you know what I just did that made me so happy that it's worth taking the time to write a blog post?

I graded something on paper.

My new coworker Travis Faas shared with me a format he uses for peer critiques during his game programming class. It's something I want to draw into that class. Today, in CS222 Advanced Programming, my students were to showcase their two-week project submissions. I've traditionally done this in an unstructured way, something like an academic poster session. Just a few minutes before class, I thought to myself, "What if I tried out that crit format here?" I literally did not have time to lay out even the simplest of templates, so I just grabbed a stack of blank white paper and headed downstairs to class.

I told the students that, during their showcase, they had to write at least three outcomes from their discussions. I suggested (following Travis) that these could take the form, "I learned X," or, "Y is something I want to learn more about." I also foreshadowed that there would be a secret final step.

As always, they walked around with real interest in what each other had done. This time, however, they paused after each station and jotted little notes on their paper. What might otherwise be fleeting thoughts were tracked, held on to.

Once we were done—and gave out the Audience Choice award, of course—I gave them the final step: to write down some action that they plan to take next that relates to the outcomes of their discussion. I gave them two or three minutes to do this before collecting their papers.

Both of my Tuesday/Thursday classes had major deadlines today, so it was quiet during office hours. I sat down in my chair, grabbed my favorite pen, picked up the stack of papers, and read through them. On each, I gave a little, hand-written affirmation, encouraging students or providing tips on how they might move toward their goals.

Paper! Wonderful paper!

I am looking forward to turning back their papers on Thursday. I wonder when the last time was for them that they had such a human experience as handing a teacher their ideas and then waiting, waiting without a chance of hearing from me about them before our next meeting. No anxiety about checking grades. No notifications. Quiet, from which comes a chance for peace. 

Paper!

CS222 and CC17

It has been many years since I have required my CS222 Advanced Programming students to read chapter 17 of Robert Martin's Clean Code. This chapter is entitled "Smells and Heuristics," and it contains a wonderful collection of common code problems and potential solutions. This year, I had my students read the chapter just before starting our two-week project, and I gave them the challenge to pick three items from the reading that were particularly interesting to them. These were fun for me to read, displayed thoughtful reflection on programming, and to top it all off, were easy to grade.

Some of my favorites showed up in the students' responses, such as the advice to extract conditionals into named functions, to replace magic numbers with named constants, and to avoid selector arguments. Feature envy showed up more than once, which surprised me. Students recognized that some of their previous courses actually habituated them to these smells rather than their cleaner alternatives.

I need to remember to keep this assignment. I plan to ask my students today whether they think this chapter would have made a good introduction to our reading rather than a capstone on it. Because the chapter is so accessible, it's possible that reading it first might help them get better faster, and to do so before they get into the trickier distinctions such as SRP (Chapter 10) and the distinction between objects and data structures (Chapter 6).

Summer course revisions 2024: CS222 Advanced Programming

I made a few significant structural changes to CS222 for the Fall semester. The course plan has just been uploaded, so feel free to read it for the implementation details. The motivation for all the changes was the same: reduce friction. The course has always had a lot of stuff going on in it, and students seem less able to manage this than they could in the past. For example, it used to be that I could explain triage grading such that most of the students understood it, but students become more brainwashed into the LMS way of running a class, they become less able to conceive of alternatives.

I decided to use the same grading scheme in this class as I am trying in Game Programming. Each assignment will be graded on the scale Successful, Minor Revisions Needed, New Attempt Required, or Incomplete, following Bowman's case study. The EMRF approach that I tried last year did not work, and I am hopeful that this alternative alternative will patch some of the leaks. I considered breaking down the CS222 assignments into individual goals, as Bowman does in his math courses and as I have done in Game Programming, but I found it to be unnecessarily complicated to do so. Instead, I have taken each day's work and consolidated it into a single assignment with multiple graded parts. I hope that this, too, simplifies the students' experiences.

I am still using achievements, but I have changed how they are assigned and assessed. For many years, I have had an open submission policy, where students can complete achievements at any time, and their final grade is based on the quantity and quality submitted. This gave students one more thing to manage, and it was something that could not easily be represented in Canvas. My wishing that students didn't delegate or subjugate their planning to Canvas won't change the fact that they do. Hence, I'm just asking students to do three achievements during the semester. It will be like choosing an assignment from a menu. Since they are otherwise a normal kind of assignment, I don't need special policies for resubmission, either. Maintaining this parallel structure between achievements and assignments also made me remove the star system evaluations. Previously, students could claim one star through self evaluation, two through peer evaluation, and three through expert evaluation. I love the idea of having students review each others' work in this way, but in the name of streamlining, I have removed it. Since I don't have this kind of peer evaluation on other assignments, I am going to remove it here as well.

From the beginnings of CS222, I have used Google Docs to manage submissions so that students can see and comment on each others work. I used to spend time in class doing more peer review in this way, but this got cut out as new "content" was added to the course. Google Docs stayed as a convenient way for me to see student work and especially for students to do the peer reviews required for achievements. Taking those away means there's no real good reason to make students go through the process of submitting through Google Docs. As students' general computing literacy has declined, I have had more and more trouble with students understanding how to use Google Docs and the browser according to the instructions. Now there's no reason besides tradition to keep it, so out goes Google Docs.

I still want to keep my course plans online and publicly available rather than having them stashed away on Canvas. However, my old approach to managing the course site as an SPA made it impossible for me to link directly to specific parts of a document. Somewhere between .htaccess configurations and shadow DOM, I could just not make it work. This was especially frustrating since this is so simple in vanilla HTML: just link to a named anchor. With the change in how I am assigning and evaluating work, I decided it was time to make this work. I have spent about two work days fighting with web development and finally ended up with the solution you can find on the course plan. I have kept lit html and Web Components because of the powerful automation tools they provide: I can define the data of an achievement, for example, and use Javascript and HTML templates to generate the code that displays it. I have stopped using the open-wc generators and npm. I looked into trying to use the open-wc generator and rollup without the SPA configuration, but it turns out that the instructions for doing this are not up to date: they produce a conflicting dependency error. Hence, I just went with a simple deployment solution that copies my source files and a minified JS lit-html library to the web server. Even though I already wrote about my frustrations with maintaining my Game Programming site, and how they led me to migrate the site to GitHub, I am thinking about revisiting that decision based on the work I've done to get the CS222 page working properly.

Reflecting on CS222 Advanced Programming, Fall 2023 Edition

As you may have noticed, I tried something a little different this year and extracted topical reflections into their own posts [1,2] rather than embed them into a lengthier reflection about a class. Aside from those concerns already expressed, CS222 went quite smoothly this semester. I had a small section, and I feel like I had a good rapport with the students. 

I had most recently been teaching the course on a MWF schedule, but this semester it was back to my preferred Tuesday-Thursday schedule. This means more time in one session to dive into a topic, but it also meant I touched on fewer topics. This is a worthwhile exchange, but I didn't get to all the extras I like to cover during the semester. For example, we didn't get a chance to explore state management in Flutter as much as I would have liked. That particular context is where we get into the Observer design pattern, which this batch of students will not know by name. I also did not get a chance to talk at all about software licensing and intellectual property aside from a quick, hand-waving statement that the students own the rights to their projects.

I also added a fourth week to the pre-project portion of the class, cutting a week off of the final project to compensate. This gave more time in the early part of the semester, where students tend to struggle with the basics. Shortening the iteration lengths for the final project did have the anticipated positive effect that students worked more consistently. That is, reducing the time between deliverables gave students fewer opportunities to procrastinate.

The most surprising finding this semester was that the first Clean Code assignment was too easy. I've been giving this assignment for years: read the first chapter of Clean Code and write a paragraph reflecting on which definition of "clean code" most resonates with you. It is intended as a warm-up exercise to get students used to the unconventional method of documenting and submitting work for the course. One of my students pointed out that it gave him a false sense of what to expect from assignments, all of which take orders of magnitude more effort than this first one. I am thinking of simply dropping the assignment in favor of more meaningful ones.

I teach CS222 almost every semester, but I have a break next semester while I work on a funded research project. It will be good to have a little break from it, and I imagine I will be back on rotation some time next academic year. We also had a new faculty member teach the course this Fall, but I haven't made the opportunity to talk to him about the experience yet. I will do that in Spring.

What we learned in CS222, Fall 2023 edition

Once again, I gave my CS222 students the challenge to make a list of everything they learned this semester. This semester's group came up with 155 items, and then each individual voted on their top seven—the seven that they thought were the most important. Our top items this semester are as follows:

• Clean Code (8 votes)
• GitHub (7 votes)
• TDD (5 votes)
• Time Management (4 votes)
• OOP (4 votes)

If we had kept stepping down the line, the next cluster was at three votes, and only two items had these: Software Craftsmanship and Resubmissions. This is interesting to me, since I don't remember "resubmissions" being such a focus in past semesters on this list. However, a lot of students did a lot of resubmissions this semester. I don't fully understand why they would put this on the list and vote for it, but I am hopeful that it is because they have recognized the utility in thinking about learning this way: that it's not a case that you learn something or not and then move on, but that if it's worth learning, it will probably take some time to get it right.

This really was a fun group of students in CS222 this semester. I feel like we had a good rapport, with many of the students catching on to the method behind the class. I think this manifests well in one of the items on the list today: a student said that they learned how to follow detailed system configuration instructions early in the semester, when configuring their Flutter development environment. I usually try not to interject while students are brainstorming their list of things they learned, but I did take the opportunity here to point out that this was on purpose, that part of the course design was to help them understand how to do this so that they would be better at it next time.

I expect to write a more thorough retrospective on the semester next week, as I usually do. In the meantime, here is the full list that the students came up with, sorted by votes.

Clean Code	8
GitHub	7
TDD	5
Time Management	4
OOP	4
Software Craftsmanship	3
Resubmissions	3
SRP	2
Acceptance Testing	2
Naming conventions	2
Debugging	2
Good names	2
Shu ha ri	2
Unit tests	2
Incremental Development	2
Teamwork	2
Flutter	1
DRY	1
Tokens	1
Beck-Style Task List	1
SMART	1
Abstraction	1
Encapsulation	1
Research	1
APIs	1
Getters and Setters are Evil	1
Comments are evil	1
Code should explain itself	1
Android Studio	1
Exploratory coding	1
Experimental code	1
Conditions of Satisfaction	1
Ctrl-Q	1
Keyboard shortcuts	1
Refactoring	1
Efficient programming	1
Gamedev jobs/internships	1
Internships	1
Overcoming procrastination	1
Commit messages
Red-Green-Refactor
UI
Mob Programming
User Experience
CRC Cards
FIRST
User Stories
Law of Demeter
Aliasing
MVC
Listeners
Stepdown Rule
Branching
Feature branching
Defensive Programming
Game Jams
Code Coverage
Resume
Psycho/sociopaths on teams
Dart conventions
Linked In
Communication
English
Scheduling
Priority lists
JSON decoding
JSON
API Keys
Configuration files
Secure key management
Serialization
Authorization
Directoiry management
Semantic Versioning
Alan Kay
RCM
Holub
Kent Beck
Dijkstra
The Null Guy
Widgets
Null Safety
Semantics
Bureaucracy
Tim Cain videos
Coding ethics
Intellectual property
Triangulation
Testing
Good use of types
Enumerated types
Dart
Error handling
Separation of concerns
Sorting
Monads/Arity
Kanban boards
Code review
Network clients
Integration tests
Learning tests
Being programmed
Data structures
Obvious implementation
Fake it
Avoid "cute" names
Dependencies
pubspec.yaml
Imports
Cornell Notes
README
Beams' commit format
Mike Cohn
Using the terminal
"Problems" tab
Shift-F6
Alt-Enter
Mind maps
Flutter Cookbook
Syntax
Exceptions
Format on save
Android SDK
Following configuration instructions
Macbooks are evil
Windows Developer Mode
Visual Studio
Stack Overflow
git usernames
git commands
pull requests
Google Drive
Google Docs
Achievements
PowerPoint
Preparation
Presentation
Alternative grading systems
Reflection essays
Leap years
Foo/foobar
FizzBuzz
GradeTool
Printing in production code is bad
Cannot build across async gaps
Demonstrating understanding in assignments
Patience
Trust the process
Wikipedia
Soup
Self responsibility
Career is not a zero-sum game (win-win situations)
EMRF
Arxiv
Developer jobs