Earlier this semester in my game design class, I overheard a student say to another, "If you don't know much, you won't be able to think of something."
He's right, contrary to the philosophy that believes that students don't need to learn facts because they can look them up.
By virtue of receiving the inaugural Teacher of the Year award from the College of Sciences and Humanities, I was invited to give some remarks at the Dean's Honor Reception. The reception is later this morning, and these are the remarks I intend to give. I will be working from notes, not this written form, so the precise delivery will certainly vary, but these are the main points. Also, the original title for the talk was "The End of Higher Education," which was a pun on the two meanings of "end," but it was softened to "The Goal of Higher Education."
EDIT (Feb 2): The talk was well received. I have edited my original post to contain a few turns of phrase that I used spontaneously at the time.
In preparation for this talk, I read through two of the notebooks I keep whenever I read a book. It was purely delightful: it's like someone wrote a book that contained only things that I find fascinating, inspiring, or challenging. I hope that you also keep notes when you read. It will bring you joy to read them later.
I searched my notebooks for an answer to the question, "What is the goal of higher education?" I am sure you have your own answers, perhaps dealing with careers or impact on the world. In the Republic, Plato asserts that the goal of higher education is to love what is beautiful. I think he's right.
You might ask, "How do we come to recognize beauty?" I put it to you that beauty is already there, that it's a transcendental property of the world around us. The question then becomes, "How do we fail to recognize beauty?"
In The Lord of the Rings, Gollum was not free to recognize beauty. Gollum could only see the One Ring. Because he was distracted by this created thing, he was blind to the beauty around him. He elevated this created thing beyond its station, and this led to his downfall. Tolkien scholar Joseph Pierce talks about how we can all become Gollumized. We can become so distracted by things that we fail to see beauty.
German philosopher Martin Heidegger wrote that we are not free if we believe that technology is morally neutral. Heidegger recognized that humanity has always used technology, but he said that we are not free if we think of this technology as neutral. Take the humble hammer as an example. With a hammer, I can pound nails, but remember the old saying, "When all you have is a hammer, every problem looks like a nail." It's true. The hammer has moral agency. That is to say, the hammer affects the moral decision space that you are in. With a hammer in hand, striking things with it becomes an option. The hammer has moral agency. How much more so the smart phone?
Canvas is a technology. Canvas affects your moral decision space. Canvas color codes your grades so that you "know how well you are doing." Canvas gives you notifications, so that you stop what you are doing and pay attention to it. Canvas gives you confetti when you turn in work on time. Beware. Larry Muller, in his brilliant book The Tyranny of Metrics, writes about how the calculative is opposed to the imaginative.
How is one to recognize beauty while tempering the calculative? I have time to share with you three stories.
My friend Dannie was an undergraduate architecture major here back in the 1990s. He asked one of his professors, "How am I doing in this course?" expecting a quantitative answer. The professor took out a piece of paper and, along a line, drew an egg, a tadpole, and then a frog. He pointed to a spot on the line and said, "You're about here." Now that is a midsemester grade!
Last weekend, I ran Global Game Jam here on campus. This is an event where people get together and, in 48 hours, create original videogames. We had over 40 people attend, mostly Ball State students but also students from other places as well as community members. There was no judging, there were no grades, there were no prizes, there was no competition, yet at the end, we had made eight original videogames, which are now available to the world for free. We made them for the joy of creating them and the pleasure of sharing them. This event is a global event, and all together, this community created over 11,000 games, just for the sake of beauty.
I regularly teach a required sophomore-level programming class. In this class, I use a system called "achievements", inspired by video games, that let students earn course credit by doing things that are outside the normal course expectations. One of the options is called, "Detox," and it requires a student to go 24 hours without looking at a screen. Every semester, a few students try it, and the beauty of their essay responses would make you weep. Students have told me how they walked across campus and really heard the birdsong for the first time. Others write about how they reflect on their life, how they got to where they are, and their hopes and dreams. My favorite story is of a student who, instead of doomscrolling on Instagram, took her grandmother for coffee. There is nothing better than that.
I put it to you that beauty is all around us—well, unless you work in the Robert Bell Building, like I do, but we're doing our best.
Look at the people on stage here. They are beautiful. Look at the people sitting next to you or behind you. Really! Do it! They are beautiful.
Speaking for myself, I don't care what grades you get. I want you to find your One Ring—because we all have them—cast it into the fire, and then join me in life's great adventure of loving beauty.
Midsemester grades are epistemologically invalid. Yes, you can compute something but it doesn't mean anything. At midsemester, every student's grade ought to be an 'F' since they have not finished the course. Aside from that, any faculty worth their paycheck should be giving student enough feedback that they know how they are doing, what to do to improve, and how to get more help or practice. At Ball State, a rule was passed a few years ago that we have to give "midsemester grades" in all classes. Par for the course, nobody actually defined what "midsemester grades" mean.
At midsemester, I threw my students' grades into a spreadsheet blender and dutifully keyed the results into the terrible Web database interface. Because I use a form of mastery grading—where students can resubmit work until it receives full credit—it is not uncommon for students to have an F or a D at midsemester and end up with a B or an A. Furthermore, the majority weight of a student's grade comes from work in the second half of the semester. I made an apologetic announcement on Canvas about having to file midsemester grades, explaining exactly what I did, that it should contain no surprises, and suggesting how students interpret their status. (It turns out, explaining to someone how to achieve their goals is the actual solution to the problem that the university is trying to solve through midsemester grades. The process is human and personal, not quantitative and automatic. No one should be surprised by this.) A few students expressed concern about their midsemester grades, but not many, which I take as an indication that perhaps a majority read the Canvas announcement. A professor can dream, anyway, since the alternative is despair.
But none of that is my reason for writing today. The previous two paragraphs provide the backdrop my tale. Pardon the metadiscourse.
As I explained in early January, I introduced a new achievement into CS222 this semester. Tool-Maker is earned by "satisfying your obsessions," and more particularly by doing the following.
Write a program to compute a student's grade in CS222 based on the policies described on this course site. You may use any programming language or environment that you like, but you must follow the practices of Clean Code.
I know of one student who is pursuing this achievement, and he has been working on it on and off for a little while, sending me occasional questions to clarify policies described on the course site. Today, he emailed me such a question. He asked whether the tool should compute one's grade as if there are no future assignments or whether it should compute one's grade and counting future work as zero.
Exactly!
He stumbled directly into the midsemester grade problem. He did not mention if his question was based on memories of my Canvas announcement, and so I suspect he simply ran across this as he tried to know whether his tool was correct or not. I told him that either way was fine with me. Practically speaking, I don't care, because the two goals of the assignment are to understand class policies and to get practice with Clean Code. My scholar sense tingles, however: once he has completed the work, I will have to ask him why he chose the path he did. One of them may simply be easier than the other, and I couldn't blame him for taking that one. However, he may make his choice based on perceived usefulness, and which model he finds useful might be a tasty bit of insight.
Writing, painting, drawing, acting. These are arts that you cannot really do wrong, but you can do poorly. If a student writes a weak, unstructured, meandering essay, a good teacher will have to tell them that they did it poorly. A less dedicated teacher may decide not to give such feedback or even to lie that the work is good. Remove the feedback system, and the author will have to draw conclusions about their writing for themselves, subject to all the usual bugaboos like impostor syndrome and the Dunning-Kruger effect.
Programming is different. You can do it poorly, but you can also do it wrong. If your program does not compile, it is not really a program at all. That is, the syntax of a programming language determines what constitutes a valid program, and if you don't have valid syntax, you only have an approximation of a program. You have a non-program. Once you've done it right—once you have something that is, in fact, a program—only then can you consider whether you've done it poorly or well. Put another way, you cannot even program poorly unless you have programmed.
This puts learners of programming in a unique situation in education, as far as I can tell. The closest relative may be poetic forms like haiku. If someone walks up to you, shows you four lines in iambic pentameter, and asks, "How do you like my haiku?" the only real answer is that the question is malformed. It is not a haiku at all. If someone hands you a bunch of monospace text and semicolons and asks, "How do you like my Java program?" then unless it compiles, all you can say is that it is not a Java program at all.
Proofs and philosophical arguments are interesting to consider. For these forms, each step should follow logically from the previous. Consider what happens if a nascent mathematician produces a "proof" but the steps do not logically follow from each other. Is it a wrong proof or is it not a proof at all? That is, can a proof be wrong? I think most mathematicians would agree with me that it is not a proof since the question remains unproven. Notice, though, that in the absence of an evaluator, or in the presence of evaluators' inevitable oversights, a learner may not recognize the distinction. This can be addressed by formal theorem-proving systems, which are, essentially, programming.
It seems then that computer programming is the best tool for teaching someone that truth exists. Without the intervention or explanation by a teacher, a learner can see that some things are programs and some things are not.
Recently, I asked my students to evaluate their accountability to a team with respect to a stated methodology. Several students presented arguments in this form: (1) I followed the methodology. (2) There was one part I didn't follow. (3) In conclusion, I followed the methodology. This kind of intellectual dishonesty pervades undergraduate writing and thinking, although I cannot tell if it is getting worse or if I am getting tired. The compiler doesn't care how much I want the text in this file to be a Java program. It won't take sympathy on you, it won't tire of reading, and it won't lie.
A student emailed me the other day to ask about what books I would recommend they read for some "computer science goodness." They asked about books that I enjoyed and books that shook up how I thought about the field. I could have sworn I wrote a blog post about this in the past. Turns out, I wrote a post in 2016 about books that influenced my teaching practice. I was a bit surprised to find, on searching my blog, that I also wrote a post in 2011 about books that influenced my teaching practice. It's hard to keep these posts DRY.
My list here has some overlap with those other two lists, since a good book will often be multifaceted. Here's a quick list of titles that come to mind with very brief descriptions of why I like them. I've included links to sources or storefronts for reference; I don't make any commission on these. Since I don't have any other real ordering to the recommendations, I've provided them in alphabetical order by author.
As I mentioned in my previous post, I rearranged the first three weeks of CS222 assigned work into six assignments. Part of Assignment 0 involved reading and responding to portions of the course plan. I did this with a quiz in the past, but now it was rolled into a larger "Assignment." I still feel like quizzing students over the course plan represents further infantilization of college students, I also can't deny that I've had less confusion around the policies in the course plan since grading student work about it.
I have spent significant effort over the years curating my Tips page, but I had never previously required students to ever engage with it. Sure, I encouraged and cajoled, but there was never anything graded that came explicitly and solely from that page. I changed that this year by adding a question to Assignment 0 asking students, "What surprised you on the Tips page?"
There were a range of answers. A few students aid that while it was good advice, nothing there surprised them. Others mentioned that the presence of the page at all, or its attention to writing, were surprises. A few students referenced the checklists, indicating that they were thinking ahead to how they will know if they are doing what is expected in the future.
My favorite responses were those that referenced George Orwell's writing tips. The tips page includes a quotation from George Orwell's 1946 essay, "Politics and the English Language." It is a masterful essay, and you should take a few minutes to read it. While only a few students referenced it as surprising, one student was particularly clear* in their response, writing, "George Orwell's tips surprised me the most because they are just about the opposite of what I learned in probably every English class I've ever taken." In my feedback to this student, I indicated that I would love to hear more about this, but that's the kind of thing that rarely receives notice from students, much less a response. Perhaps I can use it to engage my classes in person, however, in those few awkward minutes between when I get myself set up and when the meeting begins.
* My first draft used the phrase, "hit the nail on the head," but then I realized that this violates Orwell's first rule.
Welcome back to the "What we learned in CS222" series. As part of the final exam in this course, students participate in a divergent thinking exercise in which we list off what we learned during the semester. Then, in a convergent exercise, each student gets a number of stickers with which to vote for the ones most important to them.
One thing that was a bit different this semester was that, in a fit of distraction, I forgot to set the timer. We came up with this list of 129 items in roughly half an hour, but it was only roughly timeboxed. Another first was that one student misunderstood the instructions, marking the sheets that were most important to him rather than the items. We all had a good laugh about this, but it does mean that his votes may not have actually ended up where he wanted them; some were off on the side clearly not marking a specific item, but others were near enough to text that they were indistinguishable from legitimate votes.
The other unique element this semester is the answer to the question you might have from looking at the list below: Who is Jack? Jack is a Computer Science student who was not in my class but had better attendance than several students who were. Jack was enrolled in a separate section of CS222, taught by one of my colleagues, so he was studying similar material. He had a class in the room immediately before my class, so he regularly would just stay sitting with his friends who stuck around for my class. It was the strangest thing: I've had plenty of students sign up for a class and not show up, but I've never had someone not sign up but come. Maybe someday he'll shed some more light on his experience attending both classes. The only time I asked him about it specifically was on the last day of class, after my students had presented their final projects. I asked him which section of the class had better projects. He thought a moment and told us about some of the visually compelling projects in the other section, which he thought were more impressive, but added that my students probably had better code. I'll take what I can get.
Without further ado, here is what the students said they learned.
I will be giving a presentation at GodotCon 2021 entitled, "(Almost) A Year of Fam Jams". The presentation will be a summary of how my family started doing game jams together and what we learned from the process. It draws liberally from my blog posts on the topic. The presentation is already recorded, and the conference organizers will set up a time that it streams, during which time I will be online to answer questions.
In preparing for the presentation, we had a family meeting in which I asked everyone what they learned over the past year and what advice they would give to someone who wanted to start fam jamming. This was an interesting exercise, and one thing that stood out to me was that some of them were happy to give advice that it wasn't clear they themselves had learned yet. "Do as I say, not as I do" is a powerful human capacity! I hope they understood when I pushed back on these points, because I wanted to make sure I distilled our true and best ideas for the presentation.
I took more notes from this meeting than I could fit into the presentation. This blog post gives me a chance to share my notes more exhaustively. I will start with the youngest family member and move up from there. I believe this order might be enjoyable and also demonstrate the differences in ability to form abstractions and conclusions. I have listed the items so that the first statement captures the essence of what the family member shared, and then I provide my commentary on that item after that.
Put the game's name on the title screen. This was one of the first things anybody said in response to my question, and it made me laugh. He's right! We do always put the name on the title screen. Now, it's less clear to me that he understands the value of this in setting the expectations of the player or conveying the theme, but that will come.
Make sure everyone can work at the same time. That is, he recognizes that we don't want to be in a position where anyone is "busy-waiting", such as waiting for access to a particular machine or resource. Astute!
Use the black keys when composing music. Readers may recall that this son is very interested in using LMMS to compose music for the games, and I showed him many months ago that he could avoid some dissonance by using only "the black keys" to get a pentatonic scale. He's latched on to that, and his compositions have been more ear-friendly for it.
Make the game's music match the theme of the game. This is a great observation, and I think it first came up in Get the Food. We definitely came back to this idea in other games, too, including Find the Ornaments, where we talked about what might make a song sound like the holidays. (Also, I don't think it only comes in games titled Verb the Noun, but more data may be required.)
Have someone who can do everything that needs to be done. His point here is that you don't want to have three people who all want to write the music for the game and nobody who wants to do art. It's an interesting perspective, since I tend to think about it the other way: design the game such that it leverages the abilities and interests of the people involved. In fact, my wife brought up this point in response. Both sides are true, and I'm glad he brought it up.
Playtest with people who didn't program the game. He has noticed that if his older brother and I work on the programming, we might sometimes have blinders to things that are wrong or just feel bad. Again, this is a pretty astute observation. At first, I thought he meant people outside the family, but he really just meant that people inside the family should be giving feedback during the whole production process.
Leading does not mean you tell people what to do and wait until they are done: it means you check in with them and give them advice. This is an amazing point, and I remember that he struggled a bit with it the first time he was creative director. I think it was something like his telling other people to work and then his sitting down with a book. He got the idea, though, and we worked through it. Now, he is much better about communication, negotiation, and critiquing.
Prototype the gameplay with blocks. That is, don't get caught up in producing and perfecting the minutiae before you get the big ideas working.
It's fun to make different kinds of games. I couldn't agree more!
This son also mentioned something that may seem pedestrian, but it's really not: how to use Godot Engine. He's become quite accomplished with it, to the point where he can navigate the documentation and forums and figure out pretty much anything he needs. Right now, he's looking into networked multiplayer games; we had a good talk about IP addresses on our family walk yesterday.
Do drawings in pen or marker—not pencil—for ease of cropping and scanning. She has spent a lot of time post-processing the kids' hand-drawn artwork, and this is a nice, easy pro-tip.
Even though each game is different, there are certain things that you always need, such as fonts. I sometimes forget that, coming into it, my wife really had no idea how video games were made. That is, just because someone is smart and my age and played some video games doesn't actually mean they know what goes into the engineering of them. Now, she sees the patterns that I took for granted, like the idea that there are certain elements that you always expect to be on the to-do list.
We face challenges sharing workstations, and it's better to have each person have easy access to their own machine. She and I have tried to manage the proliferation of devices in the household, and we don't have a one-laptop-per-child policy. We have Old Lappy and New Lappy. Sometimes, this is not quite enough, and we're still trying to figure out the best way to manage all the technology needs and desires.
It is useful to follow genre conventions. Our first game was designed by a five-year-old and defies expectations, but after that, we moved more into conventional forms. This has been helpful for allowing everyone to imagine what the end product might be. It also has become easier as we have learned more about the tools themselves, since the tools are designed to help with common problems.
Determine your screen-size early. We had some mismatched expectations in our early jams about how to manage the size of screens, in part because the programmers saw this as flexible but the art production required it to be fixed. Now, we set the screen size early on, which means the prototype programming matches the expected final look, and the art comes in without needing to be resized multiple times.
Use drawing templates for young artists. As of The Flying Planes, we have been focused on trying to get more art into the games. In theory, this is simple: if we can put in one plane, then we can put in several. In practice, the kids drew them in all different shapes and sizes, which made it hard to get them all to fit and look right. Now, if we know something is to be mass-produced, she provides the kids with a rectangular template, which is really the bounding box. This makes it easier to scan and process as well as to integrate into the game itself.
Determine a palette early. This is a standard graphic design idea of course, though it's not something most kids (or maybe anyone?) thinks of. The games that have had constrained palettes are certainly easier on the eyes. Maybe this would be a fun area for us to grow with the kids, allowing them to explore palette creation and see how they affect the look and feel of the game.
