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.
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.
