Notes from Cal Newport's Deep Work

Some time ago, I had two people recommend Cal Newport's Deep Work to me in the space of one week. In fact, one of the two people assumed I had already read it. This was enough for me to put it on my reading list, and I got to it this past summer.

One of the delightful surprises early in the book is that Newport is a Computer Science Professor at Georgetown. Knowing nothing about him nor the book before getting into it, this was fun to come across. Although I haven't met him, I am happy that he's been able to find success in both technical research work and mass-market work like Deep Work. That said, I find myself wishing that Deep Work was written with more academic convention, including specific references at the points they are needed. Instead, references are given as notes in an appendix, but I don't know what that gains. By contrast, I am currently reading Edward Castronova's Life is a Game, which is very accessible but does not shy away from being specific about its citations. (More on that book another time.)

The premise of the book is that real value comes from deep work, the kind of work that requires focused attention and time to make progress. Newport pulls in a foundation from performance psychology to support this, pointing to Ericsson's deliberate practice as critical scholarship in that area. Deep work requires expertise and insight that is idiosyncratic and cannot be automated nor replaced. Newport acknowledges the value and role of shallow work as well, but he recommends establishing a shallow work budget so that it does not eat into deep work time. He recommends 30-50% as a reasonable budget, especially since the research indicates one cannot get more than four or so deep hours in a workday.

Newport cites Hoffman and Baumeister's Willpower, which reports on their finding that people have a finite amount of willpower that is depleted as they fight desires throughout the day. They point to routines and rituals as methods of sustaining or automatizing willpower in the face of desire. This section of the book has stuck in my mind, and I find myself ruminating on willpower as a diminishing resource in my family life, my work life, and as a game designer. 

I am intrigued by Newport's discussion of David Dewane's architectural conception of an office space that maximizes deep work potential, which he calls the Eudaimonia Machine. Details can be found once you search for those terms. The idea is that the space is a progression of depth, including intentional movement through inspirational spaces, from communal toward individual. I am not surprised at its monastic qualities, but I do not know if Dewane has discussed this connection or not.

Newport bookends his own work days with startup and shutdown routines. The last few work days, I have tried his startup routine: blocking out the day's hours, populating regions from my task list, updating the schedule to deal with unexpected twists in the day, and annotating blocks where deep work has happened. So far, so good. I've been doing informal estimations like this for years, and so my days have worked out pretty much as intended. Doing this deliberately has made me consider prioritization more explicitly than I would otherwise. 

What I have not done, and what I have never done well, is have a shutdown routine. Newport's involves a final email check, managing the task list, making rough plans for the next few days, and then stepping away until the next day. Deep Work gives me a name for a problem I am sure we all regularly face: the Zeigarnik effect. This states that incomplete tasks dominate our attention. They sure do. Even in the few days I've been trying the startup routine, I have had more than one case where I "check my email" only to find messages that then impose a drain on my attention. (I need to take my own medicine here. I regularly tell my students never to check email, only to process it.) This leads to my most significant Achilles Heel: a unified inbox. I decided decades ago to manage one inbox for all my messages so that I could always find what I needed. The problem is that personal and business messages both end up in the same place. When I'm looking for an update on a Kickstarter board game, I don't want to find a request to serve on a committee. The other side of the coin, though, is that if I'm looking for information about that board game and one of my students has problem that I can mentor them through in two or three sentences, I don't mind helping them out. Unfortunately, there's no way to eat this cake and have it too. It is an experiment I wouldn't mind running, but changes in provider interfaces would mean there is no going back.

Several concepts in the book had me reflecting on the weirdness of higher education, particularly public higher education. (Newport is surprisingly mum about the problems of academia, something that must have taken great restraint.) One such concept is the Principle of Least Resistance: "In a business setting, without clear feedback on the impact of various behaviors to the bottom line, we tend toward behaviors that are easiest in the moment." The bottom line at a state university is so far removed from faculty's daily activity that it is rarely discussed. Newport also has a lot to say about the dangers of "network tools," which seems to mean any electronic communication medium but is especially focused at social media. Here, he describes the Any-Benefit Approach to Network Tool Selection, which argues for using any network tool if it will provide any benefit at all, regardless of cost. This is another trap where academia is particularly prone to capture and for similar reasons. 

Regarding network tools, it is an oversight when he lumps blogging in with the likes of Facebook and Twitter. He treats blogging as if it is to build an audience, but there are many of us who do it for ourselves. Someone told me years ago, and I have found it to be true, that doing writing work in public encourages quality and clarity that could otherwise be illusory. (Indeed, it took me a few minutes to get that very sentence how I wanted it.)

Newport mentions Covey's The 4 Disciplines of Execution, a book that addresses how execution is harder that strategizing. The titular disciplines are: focus on the wildly important; act on lead measures; keep a compelling scoreboard; create a cadence of accountability. ("Lead measures" are in contrast to "lag measures." An example of the latter is customer satisfaction, while of the former, free samples given out. You control the lead measures directly and the lag measures follow.) It is no surprise that these align with agile software development practices, but I should keep this in mind should I end up in conversation with someone from the College of Business and we're looking for common ground.

The author's "Law of the Vital Few" is his spin on the 80/20 Rule or the Pareto Principle. His advice regarding it is surprisingly practical: if you are working toward a goal, and you're not in the effective 20%, then you should consider choosing a different goal. There's a business orientation here that may be valuable, but as with the discussion of network tools and blogging, it is also dangerously reductionist. It may just be my strange position as an academic, but it seems to me that one ought to consider one's intrinsic motivation, satisfaction, and sense of purpose in addition to measuring external factors. Some of my best academic works have zero or few citations and won't move the needle on any discussions, but I am a better person for having written them.

The last nugget I would like to share is Newport's heuristic for distinguishing between deep and shallow work. It surprised me that this came so late in the book. Yet, he presents it as a self-test, and I struggled to find the right answers, so there must be a wisdom to his placement. His heuristic (spoiler ahead) is, "How long would it take (in months) to train a smart recent college graduate with no specialized training in my field to complete this task?" Knowing that experts can only maintain about four hours a day of deep work, this heuristic can be useful in scheduling to ensure enough deep work gets done.

These are my notes and not a review, but everyone I've talked to about the book has asked, "Is it worth reading?" I think that if one is looking for tips on improving personal efficiency, then it is worth it. The book is breezy, and this comes with the necessary caveat that complex ideas are treated superficially: one has to recognize that to really understand, say, willpower as a diminishing resource, one would need to take a deeper dive into it. Newport's motivating principle is true: that deep work is necessary and valuable, and that one can learn to do it better. I think it would be worthwhile to combine a reading of Deep Work with something to remind ourselves that joy will never be found in the pursuit of success.

Thoughts on Koenitz's "Understanding Interactive Digital Narrative"

Harmut Koenitz's latest book, Understanding Interactive Digital Narrative, quickly establishes itself as being postmodern and political. I am grateful for his overt framing, although significant portions of the book contradict the tenets of moral relativism and subjective truth, as I will discuss below. Whether populism truly is a "cancer" that only leads to violence and trouble does not come up again in the text beyond the introduction.

A primary contribution of the book is Koenitz's System-Process-Product (SPP) model for analyzing interactive digital narrative (IDN). SPP recognizes that the system is created by the developers, that it is reified through a process of user interaction, and that this results in a product, which can be the discourse about the experience or a recording thereof. SPP includes a "triple hermeneutic" that users would bring to the experience, recognizing the interpretation of possibilities for interaction, the interpretation of instantiated narrative, and the reflection on prior traversals, which entails using memory from prior traversals. The explanation of SPP draws explicitly on familiar concepts from object-oriented software development, describing how IDN systems are instantiated through interaction as being like how objects are instantiated from classes. I remain surprised that this model would be considered revolutionary since it is exactly how any reasonable game developer would think of their work: design ideas are captured in code and assets; the player interacts with the dynamic system; and as a result of that experience, players can talk about it or share their playthrough.

Koenitz brings up the cautionary tale of Microsoft's Tay, the chatbot that was taken down after only 16 hours due to its absorbing and then repeating racist content. In a book that is otherwise about the boundless potential of IDN, the author here exhorts the reader that there must be protections in place to prevent IDN from exhibiting such behavior. This reveals a significant gap in his analytical model. SPP has no affordance to talk about morals and ethics outside of a participant's or scholar's subjective interpretations. The analytical framework in the text lacks the epistemological power to claim that any player activity is ethical or unethical. The claim that some interactions are universally unethical reveals that the author is using a different interpretive lens than the one he describes.

I appreciate his lengthy treatment of the narratology vs. ludology wars and its numerous references. I transitioned into games scholarship when this conversation was cooling. Koenitz's claims that the ludologists' primary mistake was narrative fundamentalism. Because they believe in only one kind of narrative, they misunderstood the narratologists, who had special knowledge of the avant-garde and multiplicity of narrative forms. I am not conversant enough in this literature to support nor critique his arguments, but the unyielding insistence that the opposition has no merit leaves me wanting to hear a bit more from the other side.

The book includes a discussion of the interpretation of Bandersnatch. He explains how interactors have created different mappings of this IDN's formal structure based on their experience, pointing out that none of them are "the structure of Bandersnatch" but rather are each "an interpretation of the structure of Bandersnatch." He also claims, however, that "unless the original design documentation is released, we cannot be sure, and therefore different interpretations of the underlying structure exist." 

Two things struck me about this claim. The first is that he presumes the existence of an authoritative and correct "original design documentation." This seems like the same fallacy that desires design bibles in games and BDUF in software development. My experience is that there may be some original design documentation but that the design-as-such is only definitively manifested in the system. Anything that specifies the possible player experiences at the fidelity matching actual player experience is homologous to the system itself. (Incidentally, one of the reasons most of my projects are released as open source is to allow the curious to study the actual system and not just interpretations of it.)

Second, there is a contradiction inherent in defending the recognition that Bandersnatch has a structure and that all interpretations are valid. He states that the differences in mappings "do not mean that any of these interpretations are wrong in absolute terms, but rather that we need to be aware of their epistemological status as post-factum interpretations." How can the interpretations not be wrong and yet the difference in interpretations be contingent upon the original design documentation not being released? That is, there is an implicit acknowledgement that there is an absolute and authoritative structure, and that these interpretations are approximations of it, such that if one had the former, some of the latter could be shown to be wrong. It is possible that a commitment to postmodernism requires one to admit the viability of demonstrably-wrong structural interpretations, but if that's the argument here, it's awfully subtle. If there is a difference between someone's structural analysis of Bandersnatch and its actual structure, then that means that it can be demonstrated with formal analysis or automated tests. I would call that interpretation of the structure "wrong." Aside from this engineering-design perspective, one can see the problem from the lens of constructivism: the interpretation yields a non-viable mental model because it makes incorrect observations about the world. It reminds me of Koster's point about Monopoly: you can use house rules all you want, but you have to acknowledge that you're playing a different game with the same pieces. If someone's model of Bandersnatch leads to contradictions against the actual thing, then it's either wrong or it's a model of something that doesn't exist.

Koenitz uses a cooking analogy to distinguishing between the prescription of a recipe (a specification) and the description of food (a product of the experience). It's a reasonable metaphor, but here is where also writes, "Far too long have we tried to learn how to cook from descriptions of finished meals." There is no referent for "we," but I don't consider myself included. When I decided I wanted to get better at making games, I didn't turn to descriptions of games: I turned to the writings of people who talk about why and how to make games. Indeed, it's hard to imagine how one could expect to get better at any art form by only looking at descriptions of experiences of that art form. Who is "we" then? He must mean "my community of IDN designers."

The penultimate section of the book provides advice on how to design IDNs. It is what any seasoned designer would expect, and it repeats what has been documented in countless books on video game design: specify goals, create prototypes of increasing fidelity, produce the software, and test. This is the conventional production process that has been talked about in games since at least Cerny's Method talk in 2002 and well before that in user-centered design. The approach is so well established that it allows scholars like me to interrogate it to determine where agile software development methods can improve it.

Reading Understanding Interactive Digital Narratives helped me understand both IDN and the community of IDN scholars. I learned some new ideas from it that will certainly be helpful in my thinking and writing, including narrative fundamentalism, narrative ambivalence, and the cognitive turn in narratology. I applaud Koenitz for his insistence that precise definitions of words like "story" and "narrative" are necessary and that lazy or colloquial use holds back progress. Indeed, I respect that he doesn't insist that people use his definitions necessarily, but that one has to define their terms in order to ensure that they are understood. I believe the SPP model will provide a useful starting point for learners who wish to analyze IDNs, including games, especially those learners who don't have a background in systems design. However, for my students who want to get better at writing for games, I will continue to recommend Bateman's collection.

Book Recommendations for Computer Science Goodness

 

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.

• Alistair Cockburn. Agile Software Development: The Cooperative Game. This book lays out an operationalized definition of what software development is: a cooperative game of invention and communication. It helped me think more specifically about the intersection of my knowledge of software development and game development. It also gives a good grounding in what "agility" means beyond buzzwords.
• Allen Holub. Holub on Patterns: Learning Design Patterns by Looking at Code. While the original GoF book is undeniably influential, this is my favorite book on design patterns, since it shows how they occur in practice: nested within each other and inside of meaningful contexts. The book is showing its age, and I'd love to see a second edition that uses more modern language features. That said, the first chapter is one of the most brilliant essays on the meaning of OOP.
• Andy Hunt and Dave Thomas. The Pragmatic Programmer. This is a classic book of good, practical, generally applicable advice for writing high-quality software.
• Robert C. Martin. Clean Code. Amazing book about how to write high-quality software. The student who emailed me should have already read this, but I'm including it here for completeness' sake.
• Peter Seibel. Practical Common Lisp. Like a lot of people, I was intrigued by Lisp when I learned it—and when I taught it! But I never quite understood how you would use it to build something substantial, something that wasn't just a classroom toy. This book explains not only that, but why macros and metaprogramming really are the cat's pajamas.

Reading "Procedural Storytelling in Game Design"

Last night, I finished skimming through Procedural Storytelling in Game Design, and I decided to use this post to capture some of my reactions to it. The book is a collection of essays edited by Tanya X. Short and Tarn Adams, published in 2019 by CRC Press. It consists of 28 chapters, which are divided into the themes of Structure and Systems, Worlds and Contexts, Characters, and Resources.

Kate Compton's first chapter provides a good overview of generators. In fact, the first chapter is an edited version of her public tumblr post, so go ahead and check that out. She presents an AI-lens on generation, framing the capabilities of generators in terms of the human skills they mimic. Then, she summarizes six approaches: distribution, parametric methods, tile-based, grammars, constraint solvers, and agents and simulators, which includes traditional CS techniques such as steering behaviors, genetic algorithms, and cellular automata. This essay also defines the 10,000 Bowls of Oatmeal problem as one of the complications of producing meaningful generators.

I can easily generate 10,000 bowls of plain oatmeal, with each oat being in a different position and different orientation, and mathematically speaking they will all be completely unique. But the user will likely just see a lot of oatmeal. Perceptual uniqueness is the real metric, and it’s darn tough.

From this introduction, I had assumed the rest of the book would dive deeper into each of these ideas. I was disappointed, then, when that wasn't the case. Most of the essays are descriptions of how procedural storytelling was used in different projects—some familiar to me, some not. They tell of design challenges and constraints, and the stories are interesting but generally atheoretical. Perhaps, once again, my hopes for formalism in game design were too high. I was reminded of a recent conversation with a technical friend and game designer, a conversation in which we both experienced finding lots of advice and stories but relatively little theory and practically no empirical evidence.

It leaves the book in a funny place: I was able to pick up on some lessons from the storytelling within because I've done similar work, but it's not the case that I could hand this to an undergraduate and ask them to explore some of the techniques presented in the book. There's just not enough detail. However, I did get links to several projects that were hitherto unknown to me. These include the tools Kate Compton's Tracery, Bruno Dias' Improv, and James Ryan's Expressionist, as well as Stéphane Bura's essay, "Emotion Engineering in Videogames." I look forward to taking a closer look at these over the break. 

There were a couple of other generally useful ideas that I picked out of the reading.Adam Saltsman's chapter, "Plot Generation," introduced me to the useful concept of froth, which he claims emerged from the LARP scene. He defines it as "the way we tell each other stories after a match and the way we construct narratives about all the cool stuff that happened during the game—that whole phase of play that is sort of after the game but sort of not." 

Tanya X. Short's chapter, "Maximizing the Impact of Generated Personalities," includes a useful counterpoint to traditional narrative design. The usual advice for a writer is, "show, don't tell;" indeed, that's something I regularly tell my own students. However, for generated characters, her advice is "tell, then show." That is, use the affordances of videogames to give the player a hint about the character and then reify that personality through an interaction. Her example from The Shrouded Isle shows how a character has the "accusatory" personality tag, which allows the player to quickly recognize this as a part of the character's personality, rather than having to establish it through a Karamazovian mountain of text.

The title of Darius Kazemi's early chapter emphasizes his main point: "Keeping Procedural Generation Simple." This is echoed in a few other chapters as well, that procedural generation should be simple and deployed both thoughtfully and tactically. 

I have been a fan of Dan Cook since playing Triple Town and reading at The Lost Garden, although I cannot remember now which of these came first. (Egads! The Lost Garden URL has changed and the old RSS feeds stopped working three years ago, but Dan has been posting things. Well, now I have even more stuff to read over the break. Fellow Feedly users, update your feeds.) It was interesting to read his chapter about Triple Town and contrasting the point he was trying to make with how the game was received and played. He is quite frank about the unexpected disconnection, its implications for design, and how some of the same mistakes emerged in different ways in future projects. 

The most interesting technical chapter was "Procedural Descriptions in Voyageur" by the aforementioned Bruno Dias. In this chapter, he digs into his tool, Improv, and describes how a set of increasingly complex filters and generators can be used to solve a creative design problem. 

I've had some procedural storytelling ideas kicking around my "Game Design Ideas" folder for some time. More recently, as part of a grant proposal, I spent some time with Reigns: Her Majesty to think about its narrative system and compare it to an old project of mine, Social Startup Game. Through my interest in Flutter, I also came across Filip Hráček's Knights of San Francisco, which got me thinking more about generative narrative as a presentation layer for a simulation. I am inspired to try making something of a similar genre, but knowing that the first three steps in Glassick's model are clear goals, adequate preparation, and appropriate methods, I hoped to find something in Procedural Storytelling in Game Design that would push me in a fruitful direction. Unfortunately, this was not the case. I am eager to look into those items I've shared above, and maybe therein I will find some techniques to sink my teeth into. That said, it's also possible that everything I need to know is already in my head: after all,  judging from the stories in the book, it all boils down to the prudent use of grammars, tiles, parametric methods, and automata. I suppose, then, that I'm just at that point where I need to choose between research and making the first prototype. I'll let you know how that goes.

My Notes on "Make It Stick: The Science of Successful Learning"

Several weeks ago, I finished reading Make It Stick by Brown, Roediger, and McDaniel. It was recommended to me by a good friend with a heart for improving education. The book aims to explain what we know about learning from cognitive science and how this can impact the practices of teaching and learning. I found the book to be inspirational, and I mentioned the book in several recent essays and presentations. I happened to meet local cognitive science and student motivation expert Serena Shim this semester, and she affirmed the findings and value of the text as well.

One of the most important findings that came up throughout the book is that spaced practice is better than massed practice. I think we all recognize that it is true: of course studying throughout the semester is more effective than cramming. However, the science is more nuanced. Massed practice is actually better for short-term recall than spaced practice, but spaced practice is better for long-term recall. This has a fascinating corollary: if our courses contain high-stakes tests, then it is a good tactical decision for students to cram.

This implies to me then that we instructors have to make a real choice between I want students to pass this test and I want students to remember this a year from now. I have a rule of thumb that I have only recently had to articulate, which is that I only want to teach content that I think students should know in five years. My general pedagogic approach favors spaced practice, but perhaps I can do more to support this. However, recent conversations made me realize that this perspective is not universal. I was involved in a somewhat heated discussion about a master syllabus revision with a colleague. The particular syllabus had, in my opinion, too many low-level learning outcomes. I argued that students don't learn these items, and he argued that they do. As evidence, I cited that they could not repeat their achievements a year after taking the class, and as evidence, he cited that they passed the final exam. Here are the loggerheads of higher education: we both believed the other to not just be wrong, but to be holding the wrong value system.

I was reminded by the text of the value of testing as retrieval practice. I had read this before but tried to dismiss it; however, the presentation by Brown et al. makes it hard to ignore. Learning improves through retrieval practice, and testing is perhaps the simplest way to practice retrieval. I mostly gave up on using tests many years ago, favoring instead continuous authentic work. However, I also see my students not remembering to apply fundamental lessons early in the semester into their work later in the semester. I need to review my use of quizzes and tests, as well as how I prepare students to do their own self-testing.

Another theme of the book that knocked my proverbial socks off was that immediate feedback is not always better than delayed feedback. I think that in the educational games community, it is taken for granted that feedback is simply good, and that quicker feedback is better feedback. As the argument goes, if feedback is good for learning, and games are feedback machines, then games can be good for learning. This is not wrong, but it is also superficial. Not all feedback is created equal. The authors cite studies that show that delayed feedback can lead to better learning. As I understand it, the actual reason for this is not understood, but the prevailing hypothesis is that immediate feedback makes the feedback indistinguishable from the task itself; this leads to a result where when the feedback is not present, knowledge of the task breaks down. This sounds an awful lot like "I can do it in the game, but I cannot do it outside the game." I wonder how many empirical educational game research projects have investigated feedback delay as a dependent variable, and if not, how one would construct such a study. After all, a player expects that if they press 'A', Mario should jump right away.

Reading the section on delayed vs. immediate feedback made me think of two other salient examples where immediate feedback may be causing problems. The endemic one is automatic spellcheck and grammar check: we all know that students do not learn to spell or write by letting their word processor do the work, it just builds a reliance on the word processor. The other, related example is IDE for novice programmers. As with automatic spellcheck, the IDE will add red squiggles to invalid code, and students can right-click on it and change it to whatever the IDE wants—often without regard for whether it is what they should want.

Chapter 8 of the book provides a series of helpful summaries that are organized for different reader demographics. It's a valuable chapter, and so I will spend a bit of time on it here describing what caught my attention and where I think it should take me. In the section for teachers, they recommend explaining to students how learning works. The following quotation is a good overview:

• Some kinds of difficulties during learning help to make the learning stronger and better remembered
• When learning is easy, it is often superficial and soon forgotten
• Not all of our intellectual abilities are hardwired. In fact, when learning is effortful, it changes the brain, making new connections and increasing intellectual ability
• You learn better when you wrestle with new problems before being shown the solution, rather than the other way around
• To achieve excellence in any sphere, you must strive to surpass your current level of ability
• Striving, by its nature, often results in setbacks, and setbacks are often what provide the essential information needed to adjust strategies to achieve mastery

Another tip for teachers is to teach students how to study. This has been on my mind quite a bit, along with the question, "Where does the buck stop?" I teach primarily junior and senior undergraduates, and I estimate that 5% of them have any real study tools. Indeed, I think a good description of the Ball State demographic is, "Students who are smart enough to have gotten this far without having developed study skills." Including direct instruction on study habits is an investment in their future learning, but I doubt I would be able to reap it in my own courses, so it's taking away from time on topic. More frustratingly, I have seen for years that I can teach good processes for learning and software development in a course like CS222, only to see that a year later, the students have never touched any of those techniques because other faculty do not expect them to. For example, I can teach the value of pair programming or test-driven development, present the students with research evidence that these increase productivity, and require them to deploy these techniques; but a year later, when I ask them to do these in a follow-up course, they say that they have not used these since CS222. Why should I be more optimistic about study skills, when inertia is powerful and habits are so hard to override?

The section of tips for teachers returns to the theme of "desirable difficulties" that came up throughout the book. Here are some specific desirable difficulties that they recommend:

• Frequent quizzing. Students find it more acceptable when it is predictable and the individual stakes are low.
• Study tools to incorporate retrieval practice: exercises with new kinds of problems before solutions are taught, practice tests, writing exercises reflecting on past material and related to the aspects of their lives; exercises generating short statements that summarize key ideas of recent material from text or lecture.
• Quizzing and practice count toward course grade.
• Quizzing and exercises reach back to concepts and learning covered earlier in the term.

Again, this is a valuable summary. Each of these items is covered in the text with explanation and citation. It's clear what actions can come from this list as well, and it makes me look at opportunities in my upcoming HCI class in a new way. I also recognize in it the value of several things I already do in the class, such as having students connect readings to their experience and writing reflections of development experiences. Given that I tend to divide semesters into a content-oriented first half and project-oriented back half, I need to be more conscientious about designing assignments and quizzes that reach back to the early part of the first half; this should help students deploy these ideas more readily in the second half.

The final bit of advice in Chapter 8 is to be transparent with students about incorporating desirable difficulties into the class. I have always been a fan of white-box pedagogy, although it's not every semester that I see students take interest in why I am teaching the course the way that I am. Student teaching evaluations often reveal quite mistaken models about my intentions as well. Sometimes I get these excellent reflection sessions as I described in Fall's HCI class, but the irony here is that they generally come after students have completed their evaluations.

I highly recommend Make It Stick. It is written clearly and precisely and organized in a way that emphasized the important points. Crucially, it avoids educational fads in favor of empirical research. Chapter 8, as I have said, provides a great synopsis that turns the ideas of the book into potential action items for practice. 

Game design book recommendations

Sometimes people ask me, "What game design book would you recommend?" I received the question today, and in the spirit of sharing knowledge and making the most of each keystroke, I figured I'd make a short blog post about it.

My number one recommendation, with no hesitation, is Ian Schreiber's Game Design Concepts. It's not technically a book—it was a free online course offered through a blog before the "MOOC" term rose and fell in popularity—but it still has everything you want. Schreiber provides twenty chapters of escalating difficulty, exercises to challenge your knowledge, and plenty of references for those who want more on any particular topic. I participated in the Game Design Concepts project individually when it first came on the scene, treating it as an independent study rather than a community exercise. If you were interested, you could certainly find a cohort to read through it and review each others' work. Huge kudos to Schreiber for keeping the site open and free for so many years.

If you really wanted a book in the traditional sense, then I don't think you can really go wrong with Tracy Fullerton's Game Design Workshop. It is thoughtfully composed and contains many interesting anecdotes to go along with the more formal text. The numerous exercises are also quite good, and they are easily adaptable to individual or group implementation (as I recall). My only criticism of this book is that it too often falls into making generalized claims without acknowledging the underlying philosophy, presenting items as definitive without admitting that these definitions are subjective and arbitrary. If you wanted to illustrate this point—for example, in a game design course—you could easily pull up "MDA: A Formal Approach to Game Design and Game Research" by Hunicke et al. It presents a different formalist notion of what constitutes a game, definitions that conflict with Fullerton's, and this can lead to a healthy recognition of how little is established in the field. (You should read that article anyway, really, if you're interested in teaching or learning game design.)

My next recommendation may be a little controversial, but I really enjoyed reading Keith Burgun's Clockwork Game Design. In contrast to most other game design theorists, Burgun is unabashedly specific about what he means when he says "game." In particular, he is talking about interactive contests of ambiguous decision-making, where the decisions are endogenously meaningful, and there is a quantifiable outcome. So, if you're interested in writing interactive fiction or adventure games, this is probably not your next stop; however, if you are interested in reading a zealot's perspective of how to approach strategy game design, I think it's a thought-provoking piece.

There are several other books that I have read and could comment on, but those are the top three that I recommend. Schreiber is #1 for being comprehensive, thoughtful, and free. Fullerton is #2 for being accessible and action-oriented. Burgun is #3 for being focused and for challenging assumptions.

Books that influenced my teaching

A colleague is undertaking a sabbatical project that involves collecting books related to teaching in higher education. I was honored to be asked to provide some for his list, and in the spirit of last week's post, I figured I would share them here as well. He was asking specifically for books about teaching in higher education, which I'll start with; he also clarified with me over email that particularly inspirational disciplinary books may also be of use to him, so I'll share some of those as well.

General Teaching Books

Without going back through my old notebooks, here are the books that I remember reading and enjoying. I've provided Amazon links mostly to remove any ambiguity, not because I have any particular need for people to shop there.

• How People Learn is an excellent overview of what is known about learning, and I remember that reading this helped me build a better understanding of some core educational concepts. Like most professors, I had practically no formal education in how to teach, and I had picked up a lot of folk wisdom; this book was useful for turning this ad hoc understanding into something more rigorous.
• How Learning Works, I read this about the same time as the previous one, and I remember it covering similar ground but with more emphasis on higher education. Since I read these at the same time, and many years ago, I may have muddled some of their influences, but to me that's okay: I believe I have internalized most of the main premises into my action, and that was the goal.
• Situated Learning: Legitimate Peripheral Participation. This book was recommended to me by a colleague, and it was fundamental in helping me shape my current understanding of learning as a social process. I have directly drawn on the ideas of this book in designing my game production studio courses. If anything, I wish I could use more of the ideas in this book: my main annoyances in higher education are precisely those conventions and structures that make it hard to follow the patterns of LPP described here.
• Visible Learning and the Science of How We Learn provides another overview of the science of teaching and learning, framed and supported by the Visible Learning meta-studies. This is a fascinating piece, and in some ways it is a quantitative counterpoint to Situated Learning's qualitative perspectives. It's fascinating and well-supported, and yet the authors' apparent disdain for non-quantitative work left me feeling uneasy. (For what it's worth, I came across this book by reading Grant Wiggins' blog, where he points out one of the most important contributions of Hattie's work: that there are many easy classroom practices that have a higher effect size than students' socio-economic status. Also, in digging up that link, I just found out that Wiggins died in May 2015, over a year ago, and now I am kind of bummed. I knew I had missed his writing; I didn't know he had passed away.)
• Speaking of Wiggins, Essential Questions: Opening Doors to Student Understanding focuses on what I consider the most fascinating aspect of Understanding by Design: framing inquiry through essential questions. Longtime readers will know that I have been tinkering with EQs as a method to frame my courses for a few years, and now I feel like they are a critical tool to my course design and evaluation process. In fact, now I often prefer to describe courses in terms of their questions rather than their content.
• Although I have not read their entire book, I will point out Papert and Harel's chapter "Situating Constructionism" from Constructionism. I think I may have read this more times than any other article. I find it fascinating, and when I am pushed to state what educational philosophical camp I belong to, I would have to say constructionism. (Of course, then I usually have to explain that I didn't just say "constructivism," and people give me blank stares. Hence, I include this chapter here, because anybody interested in effective higher education philosophy should read it.)

Other Inspirational Books

There are several books I have read that are not about education in particular, but that reading them greatly informed and influenced my teaching practice. Here are some:

• Scholarship Reconsidered: Priorities of the Professoriate and Scholarship Assessed, which I read in my third year as an assistant professor, gave me a much broader view of what it meant to be a scholar and a professor. Relevant to this post, it helped me to see how my teaching was scholarship, not just something that produced scholarship. This fundamental observation from Boyer's classic work is still something I find broadly misunderstood in academia. The counterpart by Glassick et al. provides a well-known six-stage framework for assessing scholarship—a framework I use not only in my own work, but which I worked to incorporate into my department's promotion and tenure documents.
• A Theory of Fun for Game Design. For those who are not familiar with Koster's amazing treatise, this is not a book about how to design games but rather about why we design games. The fundamental thesis presented here is that learning is fun, or put another way, fun arises from learning. I read the first edition of this book shortly after becoming an assistant professor, and the ideas of game design here strongly influenced my course design.
• Agile Software Development: The Cooperative Game. The title of this book hints at its thesis: that software development is a cooperative game—not engineering, not modeling, but a game. Internalizing this principle has allowed me to apply my research on game design directly into my teaching work. 

I hope you find this list useful. Please feel free to share your feedback or your own favorites in the comments!

Choosing Your Own Adventure

While visiting the educational resources section of the Ball State library the other day with one of my boys, I saw a pair of Choose Your Own Adventure books—easily recognizable to me by the red banner on the spine after not having seen one in many years.

I checked out Lost on the Amazon by R. A. Montgomery and brought it home to show my six-year-old son, who is an avid reader. He seems to have no trouble with the How to Drain Your Dragon and Captain Underpants series of books, and I thought a classic CYOA might be fun for him.

When I brought it home and explained what it was, he was uninterested. I brought it up a few times during the past two weeks, but he didn't show any interest until we sat on the couch together yesterday afternoon and read it together.

I will summarize our story. We were a doctor whose friends had gone missing on the Amazon River. When we find this out, we have to choose to immediately go up the river with the "Indian" Owaduga, charter a plane and go to the last known location of our friends, or wait three days to go upriver with a group of police and soldiers.

We chose to trust the Indian, and he took us in his dugout canoe up the river. As dusk approached, Owaduga gave us a choice:

We decided to rest a while, so we set up camp on the shore. Then, ...

The bold serif The End was as memorable to me as the red logo. Through no faulty reasoning or logic, we ended up being eaten by piranhas. I explained to Alex that CYOA books are like Faster Than Light: you play for the fun of playing, always with a hope of winning, but usually dying.

However, this discussion was not my first response: my first, internal reaction was to flip back to the previous decision and try again. In fact, I felt it in my fingers: I remembered how I used to keep a finger on the previous page so that I could easily backtrack.

That is, I used quick save.

I had last read a CYOA book some time in the 1980s. At the time, I was also playing games at the arcade, on the Commodore 64, and on friends' Atari machines. The arcade machines were quarter-eaters of course, and the few home computer games that had any save mechanisms were anything but "quick." (Trigger the sound of a 1541!) I have recently been thinking about the implications of digital quicksave-quickload systems on modern consciousness, knowing that experiences with technology can change the structure of the mind. However, here is evidence—long buried in my mind and perhaps inaccessible without the mediation of holding and reading this book—that my experience with quicksave-quickload predates their digital incarnation by about ten years.

My son and I read through two more times, both resulting in death by poison arrows. He tried to read it again that night, and when I asked him about it, he said he "kept getting lost." It's not that he was lost in the Amazon—he was forgetting that he couldn't just read page by page and had to follow the instructions at the bottom! This morning, he tried the plane for the first time, and he ran excitedly into my office, saying, "I survived!" Turns out, he got stranded and had to await the River Patrol: he didn't actually find his lost friends, but he had also not died, which to him was an epic win.

Resources for Games, Fun, and Learning

In February, I spoke at the Ball State University Department of Physics and Astronomy Colloquium Series as their once-a-semester "outside speaker." I used the opportunity to put together a presentation entitled Games, Fun, and Learning, and I provided an introduction to these three topics, their intersection, and why  this line of scholarship is important. The presentation was a big hit, so much so that we had to move to a larger lecture hall before starting. My friends at the Emerging Media Initiative had heard about the presentation but many of them could not make it, and so they arranged for me to give a repeat performance, which I did last Friday. The slides from Friday's talk are available, although they are probably more useful as a refresher to those who attended than to those who are new to the domain.

Much of the talk involved highlights from some of my favorite resources, and during Q&A, I was asked if I had these all together in one place. For your browsing pleasure, here's a list of the works I referenced in the presentation and in the Q&A portion.

• Benjamin Bloom. Taxonomy of Educational Objectives Book 1: Cognitive Domain. This is the primary reference for Bloom's Taxonomy of the Cognitive Domain, but you can also get a good introduction on Wikipedia.
• Limbo.
• Johan Huizinga. Homo Ludens. Also has a good overview on Wikipedia.
• Katie Salen and Eric Zimmerman. Rules of Play: Game Design Fundamentals.
• Quest to Learn, the school based on game design principles at which Katie Salen is Executive Director of Design.
• Bernard Suits. The Grasshopper: Games, Life and Utopia.
• Chris Crawford. Chris Crawford on Game Design. This is Crawford's latest work; the original one that I referenced is The Art of Computer Game Design. See also his Dragon Talk.
• Raph Koster. Theory of Fun for Game Design.
• Mihaly Csikszentmihaly. Flow: The Psychology of the Optimal Experience.
• Electric Field Hockey.
• Tic-Tac-Toe.
• Chess.
• Go.
• Team Fortress 2.
• Sid Meier's Civilization 5.
• Matt Leacock. Pandemic. See also Leacock's Google Tech Talk, Cooperation and Engagement: What Can Board Games Teach Us?
• Mizuko Ito et al. Hanging Out, Messing Around, and Geeking Out: Kids Living and Learning with New Media.
• Doug Thomas and John Seely Brown. A New Culture of Learning: Cultivating the Imagination for a World of Constant Change.
• World of Warcraft.
• Alistair Cockburn. Agile Software Development: The Cooperative Game.
• Jane McGonigal. Reality is Broken: Why Games Make Us Better and How They Can Change the World.
• Andy Lester. 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star.
• Robin Hunicke, Mark LeBlanc, and Robert Zubek. MDA: A Formal Approach to Game Design and Game Research.
• Raph Koster. An atomic theory of fun game design.
• Daniel Cook. The Chemistry of Game Design.

Enjoy! Thanks again to the Department of Physics and Astronomy and the Emerging Media Initiative for hosting these talks.

EDIT: The EMI talk has been put online. See this blog post for details.

Books for practitioners

At the end of the semester, a few students asked me for technical book recommendations. I have listed below the books that I tend to reference most often in my teaching and in my practice. Links to Amazon's listings are provided, not because I specifically endorse Amazon, but they sure are convenient.

• Alistair Cockburn. Agile Software Development: The Cooperative Game. Second edition. (Addison-Wesley, 2006).
• Allen Holub. Holub on Patterns: Learning Design Patterns by Looking at Code. (APress, 2004).
• Andrew Hunt. Pragmatic Thinking and Learning: Refactor your Wetware. (Pragmatic Bookshelf, 2008).
• Andrew Hunt and David Thomas. The Pragmatic Programmer: From Journeyman to Master. (Addison-Wesley, 1999).
• Robert C. Martin. Clean Code: A Handbook of Agile Software Craftsmanship. (Prentice Hall, 2008).

All of these books are worth reading, but where you start depends on your interests. If you are interested specifically in object-oriented design, definitely start with Holub on Patterns. Clean Code and The Pragmatic Programmer are replete with bite-size tips that can immediately make you a better professional. Pragmatic Thinking and Learning is not about technology per se, but rather it is about how to be a more effective learner. Finally, Cockburn's book is the largest and most academic on the list, but it provides tremendous insight into how one can approach software development methodologies from a perspective that is both humanistic and scientific.

DeMillo wrote this post for me already

I have been reading and enjoying Rich DeMillo's new book, Abelard to Apple: The Fate of American Colleges and Universities. I am planning to read the final chapter tonight and had intended to post a summary afterward. However, on his innovate-edu blog today, DeMillo posted his comments to the Joint Education Subcommittee of the Georgia Senate, and these provide an excellent summary of the book. This link will get you there.

Continuing Academically Adrift

I was excited to read the final chapter of Academically Adrift, entitled "A Mandate for Reform." Although I enjoyed reading it, the final chapter was neither as revolutionary nor as specific as I hoped. The authors discuss several inhibitors to change, the most daunting of which is the lack of demand for learning, which I wrote about a few days ago. Their suggestions match much of what my own Future of Education Task Force concluded: we need a greater focus on student learning. This support must take the form of both respect and rewards, since as long as teaching is institutionally considered a lesser responsibility to research, then there will be no change.

Let me be clear that I enjoyed reading the book and consider it a significant contribution to the field. Perhaps it was unfair of me to expect that their conclusions would be more immediately actionable, since their stated goal was research, not reform. Consider, for example, the authors' suggestion that effective reform needs to happen from within the current system, allowing actors to innovate within the existing space of higher education. This compares to my Future of Education Task Force recommendation for what we called "The University Sandbox," an initiative that would be authorized to work within the university while ignoring conventional assumptions of higher education. Our recommendation was not codified to the point of being immediately implementable, but I was hoping that Academically Adrift would provide more examples of how institutions might consider approaching the problem of fostering educational innovation.

In the final chapter, the authors to begin to fall into the social science trap of claiming their results are broader than what they actually found. Their study used the Collegiate Learning Assessment (CLA) to look specifically at critical thinking, complex reasoning, and writing, measuring a cohort as they entered college and as they finished their sophomore year. They found that individual studying improved students' scores while group study did not, and the last chapter begins to conflate CLA achievement with learning in general. This matches my experience and intuition: a student's ability to individually write an essay should only be improved by that individual practicing writing essays. However, they neglect to mention that CLA-measured skills are not the only skills that need to be learned. For example, there is a body of research in Computer Science education that has shown that pair programming—undeniable a form of group study—improves learning and retention. The authors clear bias for individualized rigor could have been balanced with a caveat that there are disciplinary idiosyncrasies.

The final chapter's message could be summarized as, "Be deliberate about fostering student learning in higher education." The criticism of cargo-cult active learning was refreshing, given how many papers I have reviewed and presentations I have heard where the researcher has not demonstrated any significant understanding of the fundamental tenets of learning. I also appreciate their argument for more widespread teacher-training within doctoral programs. The crux of their argument is that for the foreseeable future, many more Ph.D.s will be adjunct faculty or in teaching roles than tenure-track at research-intensive schools.

There is one immediately actionable recommendation for faculty that the authors return to time and again: be rigorous. Their own study and several related studies have shown that rigorous coursework improves student academic achievement. This may seem obvious to those outside the ivory tower, but those of us on the inside have seen how easy it is to trade away rigor for easier teaching. This comes back to the delicate equilibrium I wrote about the other day, in which learning is generally not considered worth institutional sacrifice. The good news is that students are hungry for it.

Despite any nitpicking, I do strongly recommend the book, especially to anyone who is just starting to dip their feet into higher education reform. It is probably best read in conjunction with a book more specifically about learning, such as How People Learn, How Learning Works, or, for like-minded technocrats, Pragmatic Thinking and Learning. (NB: I have not yet read the second book mentioned above, but I have heard good things about it.)

Academically Adrift and the Status Quo

I am nearly finished reading Academically Adrift: Limited Learning on College Campuses. In case you are not familiar with the book, here's the short version. The authors studied 2000+ students from 24 four-year institutions of higher education, giving them tests that measure general (as opposed to discipline-specific) skills that practically all colleges claim to enhance: critical thinking, complex reasoning, and writing. The tests were given before starting college and halfway through the sophomore year, and so they were focusing on the effects of common core curriculum experiences. The results were dismal, with the average gain being very low and about 45% of students showing no improvement.

The fifth chapter is entitled "A mandate for reform," and it makes an important point about higher education: there is no crisis. There is no crisis because there is nothing that, right now, is threatening the existence of higher education as an institution. All of the stakeholders are in good position to maintain the status quo. Parents grumble about tuition but continue to pay it in exchange for credentials for their children. Students readily seek out courses that provide little challenge, require minimal work, and allow for plenty of time for social activities, while still maintaining progress towards credentials. Professors minimize interaction with students, exchanging unchallenging courses for high course evaluations and therefore more pay, while also gaining more time for other scholarship—which also leads to more pay. Administrators keep students happy in order to improve recruitment and retention, focusing on revenue streams. Legislators and other politicians gain a credentialed citizenry, improving metrics against competing states, nations, etc.


This gives me another perspective on why it has been so challenging to try to push for learning reform within higher education: "learning" is completely absent from the status quo. There is nothing about the current balance of powers that supports, rewards, or encourages undergraduate learning, and in fact, to do so would upset the balance.

From page 127, "Many higher-education administrators and faculty today have largely turned away from earlier conceptions of their roles that recognized that providing support for student academic and social development was a moral imperative worth sacrificing for personally, professionally, and institutionally."  There were some on the Future of Education Task Force who were willing to bring up the concept of institutional sacrifice, but I have yet to see this manifest on the Strategic Planning Task Force.

Looking at it positively, this book gives me more ammunition to support what I believe is the moral imperative to fundamentally improve the higher educational system. The book is well-written and contains plenty of references to supporting literature.

Manager's Guilt

We're in the final week of the Digital Archaeology Project, and the students have really hit stride in terms of productivity. The content team has developed a working understanding of iterative design, and they are dealing with the technical challenge of XML-as-a-DSL. (NB: Not ideal, but in a five-week timeframe, nigh inevitable.) The technical team has shown remarkable growth in working with Unity: as I watch and listen to them work, I observe most of the conversation is about the problems of the domain, not problems with the technology.

Yesterday I started reading Clean Code, by Robert C. Martin. I've been enjoying it and am considering using it for Fall's CS222 class, but as I read it, I was forced to acknowledge the dual roles I have been playing on the digital archaeology project—or perhaps, the dual roles I'm not playing.

Early in the book, on page 6, Martin describes the tension between managers and developers, specifically with respect to a manager's need to meet production goals and a developer's need to keep code clean.

"But wait!" you say. "If I don't do what my manager says, I'll be fired." Probably not. Most managers want the truth, even when they don't act like it. Most managers want good code, even when they are obsessing about the schedule. They may defend the schedule and requirements with passion; but that's their job. It's your job to defend the code with equal passion.

I had a discussion (moderated by Google+) with the technology team just yesterday in which they pointed out that our methodology had been ad hoc and that formal code reviews would probably have helped our progress. It forced me to realize that I had been acting only as a project manager, trying to push this ambitious project into its five-week timeframe without stopping to consider the needs of the developers to write clean code. More specifically, I fear that I did not uphold my duty as an instructor to help the students learn how to do these code reviews, how to write usable code. David's recent post on the team blog highlights a symptom of this problem: we both saw that some of his code was unclean, but I fear I did not adequately authorize him to be able to tell me that he needed the time to clean it up. That is, if I only criticized it but did not impart on him the authority to deal with the criticism, then it was a learning opportunity forever lost.

Not that this has all been bad, by any means. Watching the team learn .NET with almost no prior introduction to it was great, and as I mentioned above, their savvy with Unity is laudable, especially after such little calendar-time working on it. Several times, we have been able to reflect on our lessons from Morgan's Raid and apply them to this new context, for both technical design and experience design issues.

But, as this is my place for reflective practice, I feel it is important for me to reflect on the feeling of guilt that washed over me as I read Martin's book. The challenge for me, moving forward, is to me cognizant of my two roles. This is significant for project-oriented, inquiry-based learning. For me to be a facilitator of learning, it's not enough to be a project manager: I need to be aware of those times that the schedule needs to be adjusted in order to help the team to understand the "principles, patterns, practices, and heuristics" that then they can "grind... into your fingers, eyes, and gut by working hard and practicing." (Martin, Clean Code, p.xxvi)

Books that influenced my teaching practice

I've been thinking these last two days about the books I have read in my six years as a professor, and how these books have affected my practice. When I started at Ball State University, I was like a lot of freshly-minted Ph.D.s: I had spent the last several years focused on research with just a little bit of teaching experience, and I had never really been mentored in effective teaching practices, not beyond some TA training just before starting grad school.

Hindsight is imperfect, but if a new CS faculty member were to ask me today what to read in order to develop a better understanding of teaching, here's what I would say. They're listed in the order I read them.

Holub on Patterns. This is one of my favorite books on patterns. It takes the Gang of Four patterns and presents them in the context of two case studies, and these come after two of the best chapters on the philosophy object-oriented design that I have ever read. The fact that the patterns are shown in collaboration is significant: one of my lessons from grad school was that it was very hard to teach or learn the patterns in isolation, because that's not how they emerge in practice. While his book is not explicitly about teaching, the idea of holistic education arises every time  I design a learning experience. I think I read it at a very influential time as well: as I was finishing my doctorate and thinking about what kind of professor I wanted to be.

Scholarship Reconsidered and Scholarship Assessed. I read the Boyer and Glassick et al. books when serving as chair of my department's Promotion and Tenure Committee. These should be required reading for anyone going interested in becoming a professor, and university administration should be required to re-read them every three years. Boyer famously describes a taxonomy for scholarship, but I think it's Glassick's book that forced me to think about the extent to which my teaching was scholarly activity.

The Pragmatic Programmer. I wish I could say, "'Nuff said" and be done with it, but I that is insufficient. All computer science professors who have not read this book should do so now, especially if involved in curriculum design and outcomes assessment. Reading this book is as close as you can get to having an expert advise the practice / applications side of the curriculum.

Disrupting Class got me me seriously thinking about the educational complex more than any other book. It's easy to find flaws in the system, but rather than dwell on these, the book addresses fundamental concepts innovation and growth. It raises the important point that organizations protect themselves at all costs, and that disruption can only be achieved by making a market where there was not one before. Several of the ideas from this book influenced my concept of the university sandbox, a place to foster the reimagining of higher education, as documented in the Future of Education Task Force report.

Pragmatic Thinking and Learning is a brilliant presentation on how people learn, focusing on software developers in particular. I would love to know what a non-developer thinks of the book. I found it to be general enough to extract several pieces into completely unrelated teaching experiences, but I also have the benefit of sharing a jargon and mindset with the author and the intended audience.

How People Learn. By the time I read this book earlier this year, I knew most of the big ideas already, having come across them in other readings or through SIGCSE and CCSC:MW. The piece of the puzzle I had not previously considered was the role of culture in learning and the vast, undocumented differences that can exist within superficially homogenous groups. I have always known that my game-related examples in CS120, for example, appeal to subcultures in the class, and so I would try to balance them against other examples, such as economics or sports-related. However, before reading this book, I hadn't considered the deeper issues of how people communicate and express understanding.

This is far from an annotated bibliography, but after reading Spinuzzi's eight-year anniversary blog post, it got me thinking that I should be sharing more about the books I read, and providing more critical evaluations of them. If nothing else, it will help me remember how I've grown and changed through reflective practice, and hopefully it will also help provide a corpus of related work as I continue to document my research.