After giving them a brief introduction and experience with pair programming, I had my students read Engineer Notebook: An Extreme Programming Episode and write an essay response. I found a few of their comments particularly insightful, and so I'd like to share them here.
"I felt that most of the things my partner and I were doing was making statements, but the two Bobs thrive on asking questions."
"As students we tend to be focused entirely on what we know and what we can do that we don't sit down and realize that most of the people in our class can do the exact same thing."
"Respect is key to pair programming."
Thursday, September 29, 2011
Wednesday, September 28, 2011
The words faculty use to describe their activities
I am on the university strategic planning committee. Over the course of the last several weeks, we have held many information gathering sessions with stakeholder groups, including faculty, students, parents, employers, and staff. Right now, my subcommittee is analyzing the data from two specific questions asked at the information gathering sessions:
- What did you learn about BSU over the last five years that you did not know before?
- If you could choose one area of focus that will have the greatest positive impact on the university, what would it be?
A few minutes ago, I finished my first pass through the responses, and this was my first attempt at open coding. Most of the data came from faculty sessions, and I was struck by how often the word "teaching" was used. Practically absent from their responses was any discussion of learning. The words faculty used to describe themselves and their activity matched exactly those words most commonly seen in promotion and tenure guidelines and annual reports: professors are obligated to do some amount "teaching."
Maybe I am reading too much into this, but it seems to belie a teacher-centric rather than learning-centric philosophy. I am reminded again of the advice of my colleagues, David Concepcion and Mahesh Daas: that the role of a professor is designer of learning experiences, and that to be a good teacher, one must be a humble learner.
The dean of my college, Michael Maggiotto, has been encouraging a transition from "teaching, research, and service" to "learning, scholarship, and engagement," as long as I have been here. At first, I dismissed this as simple alpha equivalence, and as potentially dangerous as it eschews the relationships among Boyer's four scholarships. However, reflecting on this in light of the data I just waded through, Maggiotto's approach may be a step in the right direction. The words we use shape the thoughts we think.
As an aside, I can't help but hope that I'm the first person to reference grounded theory and lambda calculus in the same post.
Monday, September 26, 2011
The Design Thinking Game
This morning in my game programming class, we started a short unit on game design. I brought in some prototyping materials and gave the students ten minutes to whip up a board game in the roll-and-move genre. This was inspired by Ian Schreiber's Game Design Concepts Level 1 activity and its primary purpose is to get students over the invisible barrier, "what if I cannot make a game?"
To explain what "design" is, I had started with a brief presentation of design thinking. Once I got the students started with the activity, I decided to sketch out a game as well. Glancing at the chalkboard, it struck me that the design thinking cycle could be modeled as a board game, so I made this:
The captions on the boxes are:- Empathy: an audience
- Identify: a problem
- Ideate: a solution
- Build: a prototype
- Test: a strategy
Each player starts at Empathy. Each turn, you roll a die and move that many spaces along the cycle. Grab a blank card and write down something that happens in that phase, using the caption to guide you. For example, my first turn, I rolled a three, and ended up on Build, so I made a build card, "Sketch." Then I rolled a two, putting me on Empathy, so I made an empathy card called, "Elderly." As soon as there is at least one card for each category, that player takes one card at random from each category and has to make narrative that explains how these five things fit together. I didn't get far enough in my own design process to decide on an initial scoring or elimination process, but I imagined that the other players would somehow score the story, and there would be a time or point threshold to trigger the end of the game.
That's it. A ten-minute game, most obviously inspired by design thinking, 1000 Blank White Cards, and Dixit. Is it fun? No, not really. You fly around the board and are forced to invent artifacts separated from any context, so you can only be very generic. Is it good? No, not really. It completely misses the point of design thinking, that you have to go through each phase to get to the next. So, why write it up here? It was actually a fun thought experiment. I used this ten-minute design exercise at the AIM conference a week ago, but I did not actually participate, I just observed. It was much more fun to actually get in and do it. I also enabled me then to present my flawed game design first, demonstrating the importance of metacognition, specifically learning from the process rather than judging the artifact too harshly.
Labels:
cs315,
design,
design thinking,
games,
teaching
Tuesday, September 6, 2011
Guest Post at Play the Past
My guest post at Play the Past is now online. It provides a birds-eye view of the design and development of Morgan's Raid, which I have written about extensively here.
Subscribe to:
Posts (Atom)