Archive for the ‘Teaching’ Category

CS1, Thinking, Programming, and Impediments to success

June 11, 2010

The following situation has arisen several times in my teaching of CS1. In an introduction to object-oriented decomposition, I demonstrate to my students how to create a MyRectangle class. This class has a constructor that takes the x, y, width, and height of a rectangle, and it has one public draw method. We’re using Java, so the draw method accepts a Graphics parameter. The draw method is very simple: g.draw(x,y,width,height), using the attributes of the rectangle. This gets us into a nice discussion of “rectangleness”, which is represented by the class, versus individual immutable rectangles, which are represented by objects. (NB: I do not follow the naive textbook approach and have every object follow whitebox design with public accessors and mutators for all attributes. That is just training students in established bad practice. I teach them to make every object immutable whenever possible.)

From here, I have them create a MyOval class. The students check out the Graphics class in the Java API and realize that there’s a drawOval method that looks deceivingly like the drawRect method, and sure enough, the implementation of MyOval is strikingly similar to MyRectangle’s.

Then, after extended discussion about encapsulation and object-oriented systems as collections of objects that communicate by passing messages, I explain the following problem: when I define a circle, I don’t like defining it by its bounding box. Unlike a rectangle or an oval, I want to define a circle by a center point and a radius. This is “natural” to me, the user of the MyCircle class. I give them this challenge, and away they go.

First, they look for a drawCircle method in the Graphics class. There is no such thing, so I point out that circles are special cases of ovals. Then, one of two things happens: either the student jumps in and writes MyCircle’s draw method to be exactly like MyOval’s, or they make some attempt to determine how a circle would be specified by its center and radius instead of a bounding box. Note that in the former case, the circle will end up in the wrong position.

I recently gave this assignment, and for the first time, none of the students got it right. Usually, it’s a minority, but at least somebody gets it. The astonishing thing this semester is that only one or two submissions showed any evidence of analysis of the problem, doing anything beyond simply calling g.drawOval(x,y,radius,radius).

The solution to the problem is, to me, so dazzlingly obvious that it’s hard to explain. It is simple geometry: if you want to get the x,y coordinates of the bounding box of a circle, you subtract the radius from the center point’s x and y. It’s geometry, easily solved visually:

the circle is specified by center x,y and radius, so the solution is quite easyAs far as I can tell, there’s only two reasons how someone could get this wrong if they were actually trying to succeed:

  1. They did not take the time to read and understand the problem before solving it. This is a common failure among CS1 students: given a problem, they start at the keyboard instead of in their brains. They start typing and typing and typing and expecting magic to happen. After all, isn’t that what the professor does in class?
    No it isn’t! For all of these drawing problems, I always start with “analytical mode”, drawing the problem out on the whiteboard, asking for suggestions, talking through my thought process, and then writing the code for it.
    This is, in my estimation, a failure of knowing how to think, i.e. a failure of reflective practice. This is the result of inculcation in regurgitative non-learning, in which points are given for showing up.
  2. They lack mathematical literacy. In this particular case, they have no grasp of geometry or the relationships between numbers. I know much less about acquisition of mathematical literacy than I do about the science of learning in general, and so the specific evidence is unclear to me. However, I have noticed that, when faced with any mathematical task — even trivial ones — many of my students will completely lock up. Of those who don’t completely freeze and wait to be handed an answer, many of these go off in crazy flights of fantasy, totally unrelated to the problem at hand.

These two factors are not independent. Although the latter may have more specific roots in the cultural establishment of math anxiety, I suggest that they may have the same root cause: students do not know how to learn. This can manifest as (1) not taking the time to read and think about a problem before answering it and (2) never needing to learn how to solve problems. This experience makes me think of Polya’s How to Solve It. I was underwhelmed reading the book because I knew most of it already, but I think this is significant: I would wager that successful students (i.e. students of life, not just people taking classes) would read that book and see it as confirmation of what they already do. On the other hand, it’s exactly the kind of thinking that many people lack, such as struggling CS1 students.

Bringing this back to the task at hand, I am forced again to look at this question: What should students learn in CS1? There are a few reasonable answers, but the two that rise to the top of the list are (1) how to think computationally and (2) how to program. The latter is dependent on the former. The former is dependent on being able to do elementary mathematics, which itself is dependent on being able to learn in the first place. If it’s true that many of my students don’t know how to learn and don’t have fundamental mathematical literacy, then it’s no wonder that CS1 courses have 50% withdraw and failure rates!

I am reminded of an uncomfortable discussion I had with a mathematics professor about programming. She was pooh-poohing the study of programming, claiming that it was easy to teach programming to her upper-level mathematics students, so therefore programming was easy. I take this as anecdotal evidence of my theories: give me a class full of students with mathematical aptitude and problem-solving skills, and I could certainly teach them the simple task of programming. They already know the hard part—thinking and problem-solving strategies—that I am challenged to teach to everyone else.


The All-Novices in the Cooperative Game

June 3, 2010

I am about halfway through Alistair Cockburn‘s Agile Software Development: The Cooperative Game, second edition. The book provides an excellent and thorough coverage of agile methodology development, which dovetails nicely with my need to develop an effective methodology for Fall’s game programming course. I have taken copious notes and written several times in the margin, “How will this apply to CS315?”

Chapter 5.1 was added in the second edition in response to the myriad misunderstandings of the agile manifesto. In this chapter is Cockburn’s first explicit consideration of dealing with an all-novice team, which is my situation in the Fall. This paragraph is from p258, in a section addressing the misconception that agile methodologies only work with expert developers.

If I had a project consisting only of novices, I would put my money on their doing better with an agile rather than a plan-driven process. I can’t imagine novices coming up with a meaningful plan from the beginning, or delivering a successful project by sticking to that plan, or updating the plan every time they found a mistake in it. An agile process would call for them to work together, integrate frequently, test their code, show their results to their sponsors and users, and update their plans and working practices accordingly. With this approach, they would have a better chance to learn and improve within the project.

I have been using agile methods to varying degrees in my project-oriented classes, and I am certain that they engender learning and improvement. I think it’s worth teachers’ time to look at the best practices espoused by the signatories of the Agile Manifesto.

This has important implications for classes, especially project-based, studio-based, or otherwise constructivist learning experiences. Perhaps the most important is that it is the students’ right and responsibility to modify the environment after each iteration.  If students are the owners of their learning experiences, then they must be held to the same level of citizenship as a programmer on a software development team. I find that there are two impediments that challenge this, namely the professors’ and the students’ comfort with conventional objectivist designs. The sooner we can break both populations’ addictions, the sooner we can get on with learning.

Further on in the same section, Cockburn tackles the problem of the ratio of novices to experts. In dealing with an excess of novices, in situations in which getting rid of them is not an option, he recommends:

Use an agile process with the smallest number of people possible to get the job done; let the rest of the people do anything they want just so long as they don’t interfere with the progress of the development team. (Emphasis in original.)

There’s a convenient solution to a production-intensive learning experience in which firing personnel is not option. Of course, these folks should not expect “A” grades.

(I plan on writing more about how Cockburn’s observations and advice can apply to the design of project-oriented courses, but this particular paragraph inspired me to start tonight.)


June 2, 2010

One of the teams (or, I think, one of the members of one of the teams) from my Android-HCI class cleaned up the class project and has released it on the Android Market. If you have an Android device, open the market and do a search for “Elemental”, and you’ll find a nifty little periodic table application by Team Phosphoric. Well done, gentlemen! I found posting an Android app on the Market to be a fulfilling personal experience and a great learning experience as well.

The good folks at Google have promised that we should get a Web-searchable version of the Market soon, as well as cloud-to-device messaging, which will allow me to give you a link directly to the app installation. Until then, you’ll have to do it the conventional way.

Reflection on 345/545

May 6, 2010

It’s the end of the semester, and today were the final presentations in the HCI class. I am taking this opportunity to reflect upon this teaching experience, an attempt to articulate some of the joys and frustrations of this semester.

  • I am disappointed that none of the projects have been released on the Market. I suppose it’s a good thing for the students that I didn’t make this a requirement to get an A. I do not think that any of the teams even seriously looked into the distribution requirements, which makes me sad, because there are many interesting elements here, including application permissions, application signing, certificate management, and dealing with feedback from unknown and unexpected users.
  • I knew going into the semester that the vast majority of the students would not be able to adequately scope their projects, and so agility was built into the expectations. However, I did not fully account for the negative relationship between estimation inexperience and team size.
  • I suspect the results would have been better overall with smaller team sizes: this would have increased both accountability as well as motivation, since individuals would be needed. I tried to keep the number of teams relatively small so that I could keep track of each team and provide directed feedback. In retrospect, seven teams were too many for me keep track of anyway, and so having more teams would not have been a significant drain on my time. It would have complicated in-class presentations, but I suspect this would not have brought as much difficulty as benefit. (Many wise students suggested smaller team sizes in their reflections.)
  • The risk matrices were generally useful, but the MSF Team Model was not. From personal experience and the stories told in students’ reflections, it is clear that most students did not understand the meaning of the roles, and I suspect the “role” system caused more difficulty than was necessary. Students with no prior experience in significant team development projects have no useful mental framework for roles, and so, in retrospect, I should have predicted that they wouldn’t appreciate what the roles meant. Point in case: “testing” doesn’t mean anything to a student who has never tested anything. (The fact that students can go through the foundations courses and never discuss testing is a problem, and it’s being addressed by the introduction of 222.)
  • The teams suffered from communication breakdowns and uncertainty about tasks at a fine grain. The risks of the risk matrices were slightly too abstract for the students with no prior team or large-scale development experience to handle. I suspect one of the following would be preferable: (1) more rigorous management of the risk matrices, including more directed feedback from me about the appropriateness of risk articulation; or (2) a more quantitative, task-oriented project management technique such as the product backlogs of Scrum or the use of issue tracking software.
  • Having community partners was important, especially to the best students. Many of the students clearly learned important lessons from these interactions. Some of them were lessons I was also trying to convey, but it was much more effective to work with the ignore-the-professor-in-favor-of-outsiders phenomenon than it was to fight against it!
  • The reflections were worthwhile except that I needed to set stricter deadlines. I am not a fan of deadlines for such work, but they are needed for my own sanity, not for the students. Because I did not set explicit deadlines, I have been inundated by “reflections” the last two days. The astute reader can guess the quality of reflections that are being sent in right before the end of the semester. Hint: they’re not the ones I really enjoy reading, and I think they primarily why I have been so blue today.
  • Expanding on the previous point, it was very rewarding to read the reflections of the responsible students. By responding to their metacognitive essays, I felt like I was having a direct and positive impact on their individual learning, a great win for a constructivist. I realize that there are two potential complications in this: (1) there is a chance that better rhetoric is being rewarded over authentic-but-inarticulate reflections, and (2) a student who is savvy with emotional intelligence could manipulate me through these essays. I think either are acceptable costs. Regarding the first, writing is an extremely important skill that students should have anyway, and regarding the second, I think the best of the students are more honest than that.
  • Expanding on this point again, it was frustrating that some students still did not get the point of the reflections, or perhaps what metacognition is about. I am concerned that perhaps I did not articulate the requirements clearly enough, but with targeted individual responses, I’m not sure what else I could do aside from assigning them to do exercises out of Pragmatic Thinking & Learning.

There are some things I would change if I could do this course again, but mostly, I wish I could take all of my “A” students and with me and do some really great things. Unfortunately, the curriculum doesn’t work this way: this is a terminal class, and I have to let go. (Another reason I’m a little blue today.)

For any of the negative aspects of the course, I do believe that the students really did meet the learning objectives of the course. By and large, I think they understand better the role of humans in software development, both as users and as collaborators. For those who are not graduating (who are most), I look forward to watching them move through the curriculum and seeing if the course really had a measurable effect, especially as they take the capstone course— projects of which are often characterized by team trouble and bad user-interfaces!

Also, the design of the course met the primary constraint: the students were able to hit the ground running with a mobile application development project of their own design, while I was free to enjoy the birth and first few months with my second son. I wouldn’t want to do this every semester, but this one worked out fine.

Advice to future students from current students

May 6, 2010

It’s the end of the Fall semester, and I am a little bummed. More on that later. For now, I will amuse myself by sharing with you, dear reader, the advice that my students are leaving to future students. Specifically, this came from an anonymous survey in my HCI class. The class was project oriented, 15 weeks on a mobile phone application. In the survey, I asked for “Advice to Future Students,” and the students were told that any responses would be shared.

I will be linking my 315 and 222 students here in the Fall.

The only advice that I can give. Any course taken by Dr Gestwicki is very immersive and practical. If you want to fully utilize his course, dont take any other course or atleast dont burden yourself with too many courses other than the required minimum. I personally felt that I had only used 10% of him this semester and still I found it very enjoyable and wonderful. So imagine how I would feel, if I had utilized him to the full. You can make a living out of any of his courses. Attend all of is meeting( I wouldnt say that as classes) and always dont hesitate to ask him any doubts, even if they are silly. Go and knock his office doors often :)

Tackle the bigger problems first, making about pages, and splash screens is trivial compared to the main functionality of your program.

Consider your scope very very carefully. Consider how you are going to meet that scope. Consider what you want to do and make sure you refine that as much as possible. If you have someone that’s taken software engineering before have them help you figure out a development process that will work for your team. Try and do everything you can to involve all the team members.

start your project eariler,
go to developer guide, if you have some problems with andorid coding
communicate your team more than once per week

My advice would be to always get your work done in a timely manner. This, of course, does not pertain to the specific class alone. Nobody likes the person that never does their work. Don’t be that person, is my advice.

Read your documents and any extra material that you think you may need or even peaks your interest. In this field its always good to stay up to date on the latest information as well as branching out and learning new languages, ideas, and methods for accomplishing a goal.

Also, get to know people a bit before you decide to work with them. Just because you are friends with someone doesn’t mean you know their work ethic or their abilities.

Read before start

A good group makes all the difference, and bigger isn’t always better. Having a good tight group of 4 or so people will keep you organized and agile.

Let me begin with an overarching caveat: when you take a class like this, the majority of your work – perhaps 90% or more – will be dealing with other people. You will pick your project, the difficulty level, and almost every aspect of how it should get done. Furthermore, everyone in a 300/500 level CS course should be able to write code and solve problems. Skill is not the problem. Getting people to do the work is.

Take the hiring phase of this course seriously, even though you may have little time/resources to do so. Once you’ve formed a team, get to know the PEOPLE on your team ASAP, not just WHAT they can supposedly do. Find out if they have a lot of other courses this semester. Find out if their other courses are difficult or easy. Find out whether they will consider this a blow-off class or not. If you find yourself among a team of slackers, leave the team or fire those people immediately. Otherwise, you will probably ruin what could have been a fantastic learning experience in this class.

Additionally, find out how your teammates think. This is especially important (in my experience) if your team includes students from other parts of the globe; not everyone thinks like you. The words ‘testing,’ ‘development,’ ‘design,’ etc. can mean slightly/very different things depending on your background. In fact, even if your team consists of just one nationality, your teammates’ past project experiences may foster inconsistent team-wide expectations. Create a terms list for your team ASAP defining project-related terminology. Make sure everyone is on the same page.

Lastly, make sure you adhere to the following three rules when it comes to working as part of a team:
1. Communicate early.
2. Communicate often.
3. See rules 1, 2, and 3.

The internet will lie to you, only incorporate those ideas and algorithms into your project that you understand.
It is best to address the problem of an unproductive team member early rather than late and to do this in as creative and friendly of a way as possible.
Satisfactory results are not always correct results. Test at the margins; the beginning and end of files, the extremes of input – large and small, and test your project with both an expert and a novice.

Reflections on Situated Learning

April 23, 2010

I just finished reading Situated Learning: Legitimate Peripheral Participation by Lave and Wenger. It’s a fascinating piece of scholarship published in 1991 that approaches learning from a situated, social perspective. An overview of Legitimate Peripheral Participation (LPP) can be found on Wikipedia. Many ideas came to mind as I read this book, but before I go any further, I should mention that this is still relatively far afield from my usual research areas, so I welcome correction if I am missing the nuances or even just plain wrong on my interpretations.

Communities of Practice

The authors describe learning as happening in a community of practice. To establish this point, they leverage a variety of examples of apprenticeship. One of the core contradictions the authors use is that of community regeneration, that newcomers become old-timers. Tying this into higher education, it makes me concerned that much of higher education is designed to propogate professorship. This is almost too easy an explanation for why motivation to study is generally low among college students: the intention of the teacher and the perspective of the student (assuming the student is not intending on an career in academia) are completely different.

Masters such as these

A quotation from p85, in the context of discussing how learning occurs in communities of practice despite the absence of didactics:

If masters don’t teach, they embody practice at its fullest in the community of practice. Becoming a “master such as these” is an embodied telos too complex to be discussed in the narrower and simpler language of goals, tasks, and knowledge acquisition.

This captures some of my frustration in teaching. I reference my working with two students on Confluence as one of my most positive learning experiences, and I feel strongly that we all learned substantially from this experience. Borrowing from Lave and Wenger, my students were legitimate peripheral participants, and I was the master—not the “teacher”. This is in stark contrast to my experience with 345/545 this semester. With 33 students spread across seven teams, I am left barely involved in their processes. I am a master in abstentia, but I can see no other way to organize so many people with one course load.

The other course I have this semester is on history education game design, and I am team-teaching it with my esteemed colleague Ronald Morris. We have eleven students who are working on the design for a game that will teach fourth-graders about Indiana’s Civil War history. While the class has some forward momentum now, there have been several points where I have felt that the students were either not putting in the right amount of effort, or that they were not putting effort in the right direction. I have tried to guide this as a mentor, but looking at it from the LPP perspective, not as a master. I cannot help but wonder what would have been different if I had been the game designer, and the students had legitimate peripheral roles: would that have been a better learning experience for them, with less of the frustration that comes from masterless apprenticeship? I am going to need more time to think about this, but I offer it here for consideration and commentary. (EDIT: I should add that I don’t actually consider myself a master game designer, but rather someone who is learning along with the students. However, my “mentoring” actually separates me from being a legitimate peripheral participant. Weird.)

Lave and Wenger do not explore the structural changes that would be necessary in formal education in order to leverage LPP, but I do not blame them for avoiding that minefield in this work.

Teaching a craft

One of the more interesting case studies referenced in the book is that of the apprenticeship of tailors. An apprentice starts by learning to finish a garment: sewing buttons, hems, etc. The apprentice then learns the production process backward, so the last thing the apprentice learns is how to cut the material. This way, while working peripherally yet legitimately in the community of practice, the apprentice is learning not just the feel of the material, the repeating patterns of tailoring, but also the social interaction and the personal identity of tailorship. The authors claim that this outside-in pattern of learning a craft is common across times and cultures.

I agree with Alistair Cockburn that software development is largely a craft. Are we guilty of teaching students inside-out, from cutting to polishing? Given that students rarely ever truly ship anything, I would answer affirmatively. Understanding this model of learning a craft, and the theory of LPP, has given me a new perspective on an old frustration, but again, I’m going to need more time to digest it.

Team focus vs. product focus

April 22, 2010

On Tuesday, we had a guest presentation in 345/545 by Jim Solenberg, Chief Architect at LaViaz Mobile. He gave a very nice presentation on UI design and development, pulling from significant experience in both the technical and the human factors of application development. He based much of his presentation on the Apple iPhone Human Interface Guidelines (HIG), which are worth an exploration.

Solenberg argued strongly for having a product definition statement that a team could return to for justifying all significant decisions about an application. This is a good idea and, as I understand it, a best practice in application development. However, from what I have seen, the Apple HIG does not address the nature of the team, only the nature of the product. In 345/545, we have been following a loose interpretation of Microsoft Solutions Framework (MSF) Team Model, specifically the Risk Management Discipline. This approach was recommended from Hal Abelson for mobile application development within a classroom environment, based on his pioneering courses on mobile application development at MIT. MSF is product-agnostic, but it heavily relies on collaboration by peers: all members on a team are peers, and open communication is necessary.

Inspired by MSF’s Team Model, I had my students include a team mission statement during team formation. The intention was that this would capture the ethos of the team and give them a stable point, even if they changed projects. That is, even if the team unwittingly undertook a project that was beyond their capacity to complete, they could be agile enough to change projects as long as it was consistent with their team mission statement. This is reminiscent of the Resources-Values-Processes business analysis model from Clayton Christensen, where the mission statement represents the Values of the organization.

Students were asked to give a 2-minute project pitch the same day as they announced their team formation. My intention was that this pitch would contain the “elevator talk” version of the project, the product definition statement of the Apple HIG.

From my observations, I suspect that none of the teams have referenced either their mission statement or their 2-minute pitch since the beginning of the semester. One of these is focused on the team, and the other on the project, but they serve a similar purpose: to steer a team towards success. I am left wondering whether more rigorous enforcement of either would have helped the teams through some rough patches. However, because neither the team-centric mission statement nor the product-centric elevator pitch seemed to have much effect, I am left wondering what elements of this approach should be reused. It may be worth noting that none of the teams have shifted projects since their initial pitch in the first week of class, although all have revised their designs through a few iterations.

Higher education desideratum: intentional completion

April 3, 2010

Desired: a learning environment in which participants engage in intentional completion. That is, they “ship” their work when they decide it is time: not when the semester ends, not when a deadline looms, not when they want to give up.

One of the main reasons we don’t have this is the conventional grading system. What is needed is continuous formative evaluation. What we provide are punctuated summative evaluations: grades during the time-boxed learning experience directly impact a final assessment. This does not provide a “safe fail” environment necessary for real learning. Real learning happens when contradictions within the mind are discovered, and that essentially requires failure. I contend that building an environment to support intentional completion requires embrace of failure and therefore the abandonment of conventional grading.

Education discussion in Linchpin

March 20, 2010

Clearly, I’ve been introspective about both the specifics of my teaching and the general properties of higher education. I was feeling like I had found some closure internally, when I sat down last night to read a bit of Seth Godin‘s Linchpin. Two nights ago, I had read a few pages on education, and I was so struck by them that I set my bookmark back intentionally to read them again. I don’t remember ever doing that before, for what it’s worth.

From page 39:

We’ve been taught to be a replaceable cog in a giant machine.

We’ve been taught to consume as a shortcut to happiness.

We’ve been taught not to care about our job or our customers.

And we’ve been taught to fit in.

None of these things helps you get what you deserve.

That’s reasonable, and it echoes what I believe about striving for excellence, about “good enough” simply not being good enough. He goes on to say [p44]:

Teaching people to produce innovative work, off-the-chart insights, and yes, art is time-consuming and unpredictable. Drill and practice and fear, on the other hand, are powerful tools for teaching facts and figures and obedience.

Again, I agree. I read this paragraph over and over again, and it is sobering. He continues [p47]:

What should they teach in school? Only two things:

  1. Solve interesting problems.
  2. Lead.

Right-on. However, then he extrapolates:

The idea of [computing a hypoteneuse] by rote, of relentlessly driving the method home, is a total waste of time.

Now, I’m not so sure that Godin and I are talking about the same thing. While it’s true that most people do not need to memorize the Pythagorean theorem in order to succeed in every day life, this ignores one of the most important aspects of a liberal education: that it trains the mind to think deeply about problems. I came across a compelling argument recently (though I cannot remember where) that said that the point of K-12 math is not to teach mathematical skills, but to hone the learner’s ability to mentally manipulate complex and abstract concepts.

Taking the Pythagorean theorem as an example, it may be true that there are diminishing returns in “relentless” repetition, but on the other hand, it takes 10,000 hours to be an expert. If we want students to be able to even conceive of higher mathematics (i.e. to gain any insight beyond novice or advanced beginners), would they be able to do this without practice? I’m not so sure.

I can’t help but think about Math and Computer Science together here. My Calculus professors in college were traditional mathematicians who made us do volumes of exercises, the same exercises the students before had done. I suppose I learned some Calculus at the time, although now I can only remember the very basics of differentiation and integration, and I certainly don’t remember “series” except by name. Honestly, I don’t really remember clearly what they are for.

My Computer Science professors were, by and large, mathematicians also. (It was a Mathematics and Computer Science Department while I was there.) Our assignments were very similar: build up something non-novel that is a little step above what we built before. Thinking about data structures, I remember binary search trees since we used them again and again as examples, and they are conceptually simple. I remember the names of red-black trees and AVL trees, but I could never build one now without either searching the Web or essentially re-inventing it. That is to say, I don’t have any working knowledge of either advanced data structure aside from knowing that they’re balanced trees.

Also, I am OK with this. I brought up a similar point in a curriculum committee meeting once, and some of my colleagues seemed to think I was nuts, that I didn’t mind not remembering “fundamental” Computer Science ideas. However, it hasn’t stopped me from solving interesting problems, as Seth Godin puts it.

The question remaining for the scientifically inclined is: would I still be able to solve interesting problems without the physical changes in my brain brought about by years of mathematics practice? Several studies in CS education point to time-on-task as a major factor in success, suggesting that motivation works only in that it encourages fruitful practice.

I have been enjoying Linchpin, but this discussion of education is not as black-and-white as the author portrays it, not according to recent research on the science of teaching and learning. Adopting Dreyfus’ terms again, it’s one thing for an expert to spend his/her time solving interesting problems, but novices still need rules and scaffolding to move up the skill acquisition ladder.

Criticism and Teaching

March 19, 2010

Yesterday, I had an interesting juxtaposition of events. In the early afternoon, my students in 345/545 gave their status reports. Immediately afterwards, I went to a colleague’s class — a graduate course in architecture — to help review status reports there.

In my own class, the students had previously set goals for what they would accomplish before Spring Break. I think the teams had set (mostly) set reasonable goals, although several of them struggled with the concept of measurability. (As in, the goals had to be measurable.) The point of Thursday’s status reports was to briefly address how well the teams had progressed in meeting their goals.

While some of the teams had met their goals, I was overall disappointed with the progress. Some teams clearly misunderstood that there was no expectation in the schedule for work over Spring Break — although it was an opportunity to make up for lost or mismanaged time. Some of the teams have been struggling with the same technological issues since the beginning of the semester, and this is inexcusable. Fighting against the technology, there will be no progression into the deeper topics of HCI that I want students to explore through their projects.

However, I did not tell them this. I was mostly quiet during the status reports, offering little nuggets here and there. My thinking at the time was that the public shame of having missed even rudimentary self-imposed deadlines, and the peer pressure from their colleagues, would be enough to force them to move forward. In retrospect, I’ve been acting this way for weeks, and I’m not sure that this has been the right course.

I moved from this class to a colleague’s, in which I was one of several faculty and staff members who were providing feedback on entrepreneurial innovative ventures. Th best part was the discussion following the presentations. Without naming any names, I’ll say that I was vocally critical of one of the presentations. During the presentation, I recorded a page of criticisms. When we got to Q&A, I tried to gently address the shortcomings of what was presented, though I probably addressed only half of the items I had written down (and none about the dreadful infographics). I was fair, I think, and firm. Yet, perhaps not firm enough: the real problem was that the presenters had an idea but not a plan. Ideas are a dime a dozen: implementation is what defines success. However, I tried to criticize what was presented rather than the process I perceived; I did not want to come across as a jerk with an axe to grind when invited into another’s classroom. However, when the professor himself gave his closing comments to the team, he articulated very clearly what was really the essence of my piecemeal criticism: the problems of the team’s process itself rather than the specifics of their presentation.

As I reflected on this — and discussed it with my wife over dinner — I feel like I was two people yesterday afternoon. In my own class, I was standoffish, not even writing down the many and valid criticisms that could (and probably should) be levied on my students. My wife put it well when she suggested that I should have said, “It goes without saying that your work is unacceptable.” The problem is, I don’t know if it actually went without saying, or if my students are blissfully ignorance of their impending doom should they fail to pick up the pace.

Conversely, in the afternoon, I was diving into specifics, leveraging the critical power of the unknown professor to try to pry the best ideas out of these students who I don’t even know.

And this makes me wonder if this is the essence of the problem. I have gotten to like my 345/545 students, and I want them to succeed. I don’t really know how much criticism I can hit them with and have them still be inspired, rather than becoming disenchanted. I am reminded of a story that Hal Abelson told me about his mobile application development class: when one of the students listed “lack of time” as a risk, one of the professors suggested he either drop the course or deal with it. That’s tough love — I respect that, but sometimes I have a hard time doing it. I wonder if maybe I have coddled my students too much, given them a false sense of accomplishment where, in fact, I complain to my wife almost every night that I am concerned about their lack of progress in their projects.

From this cogitation, I have come up with two actionable ideas. First, the teams should be smaller. My initial vision for the course was that students would be inspired to take the initiative to explore the rich landscape of HCI, and that each would bring unique talents to bear on the success of the project. This has not happened, and I can’t help but blame The System: my students are being asked to do too many things in one semester for them to be able to focus on learning. (Learning in higher education?! No time for that. (That’s the topic of another post.)) As it turns out, some of the teams are just too big, and it opens up the possibility for miscommuncation, mismanagement, and blamesmanship in completely unproductive ways. If I cannot change the system, I can mitigate the problem with smaller teams, I suspect. The confounding corollary is that then I would have about twice as many projects and teams to keep track of, which would be very difficult for me, and again I can’t help but blame The System.

The second action item is to specify milestones for the second half of the semester. Some of the teams are doing an exemplary job of managing themselves, but many still have not seemed to hit stride in this respect. By giving some concrete milestones, I am wedging myself in as a manager in a way I was hoping to avoid, but it seems to be the lesser of two evils. Figuring out where these milestones should go will be a topic for this weekend’s consideration and Monday’s work.

A third idea, on which I may or may not take action, is that I may need to create more explicit rubrics for my students to let them know what I think about how they are doing. They are right now conducting peer evaluations, using a painstakingly-designed rubric. I could adapt this to let them know how I see their team work, presentation skills, technical progress, and understanding of key HCI concepts. I suppose I should first set up their milestones, and then figure out how to best give them the feedback I think they need.

Moving forward, I am going to try to be more cognizant of my own feelings with respect to the critical feedback I give my students. If I’m not giving them the criticism they need, then I’m not doing my best job for them. I will try keeping some notes about my feelings and fears as I observe these status reports, and hopefully that will guide me.


As always, my wife is a font of wisdom. How she does so with the chaos of two young boys, I cannot fathom. In any case, in conversation with her I realized that I was probably trying a little bit too hard to try to undo the effects of years of brainwashing from our culture and ridiculous industrial educational system, and accomplishing this in half a semester may have been a little optimistic. This forces me to acknowledge my own fears, that if I comply with the system — as my students (potentially subconsciously) want — I will forget what it is that is so fundamentally broken about the system itself.