ICER Day 1: An Unexpected Foray into Learning & Design

A Layout

Synchronicity can be a freaky and wonderful thing. Within the first two hours of the ICER conference today I realized that I had not left Design behind (see my last several posts), and that a book I am currently reading (and will eventually post about) on egotistical versus empathic people in the corporate world was directly relevant to pedagogy and computing education.

The keynote speaker today was Scott Klemmer, who, in spite of what that link says, has just moved here to UC San Diego, apparently split between the Cognitive Science and Computer Science departments. He was originally trained as a designer and it showed as he took us on an interesting adventure around UI design from the back end - code in other words. He started out with the statement "View Source is a great example of UI design". That got my attention - to spend the next hour talking about the UI (UX) aspects of something users never see (code) but computer scientists see day in and day out. How very very cool.

In contrast to the industry-oriented conference I reported on a few weeks ago, ICER is an academic conference. Thus, Scott's talk was loaded with wonderful theoretical backup, explanations, references and citations, thought provoking ideas and suggestions that researchers love to roll around in. It was great.

So when Scott said "intuition is a difficult thing to teach students" it was the opening volley into wide ranging but highly focused and well supported discussion about using examples to aid learning, to generate creative design, to generate effective design, to arrive at quality prototypes while building group (i.e. team) rapport. One theme: sharing and adapting examples is good technically and good for learning purposes. But in a much deeper way than you might think. The discussion then rolled on into the role of peer assessment in design and how it can be used in software tools. Drool.

One of the interesting areas Scott has worked on is researching single vs. parallel design development. We know (the "research We" for those not used to the lingo) that people become ego attached to their own ideas and are loath to let go of them, even sometimes to their own detriment. It is called Functional Fixation and was written about back in 1945 by a guy named Dunker. But, we are learning that this ego attachment is reduced significantly if people develop multiple ideas in parallel. It becomes much easier to hear critique and drop one idea for another if you have several ideas to compare and contrast. As opposed to if you have only one idea and you are completely invested in it's success or failure.

Lots of very practical application along with some wonderful theory - established theory and theory being built. Some of what Scott spoke about was targeted at formal pedagogy but I can easily see it adapted without too much effort to an industry setting. For example, he spent some time on how to incorporate self-assessment and peer assessment into the development of designs and prototypes in the computing classroom. One of the big challenges, as educators are all too painfully aware, is that novices aren't always very good at providing useful feedback. Even when the faculty supplies an assessment rubric as guide, all sorts of issues arise - if the rubric is too specific, it can stifle creativity and lead students to just check off the boxes without any deep thinking; yet if the rubric is too abstract it can lead students to have no idea what to do with it and either flail or provide random, not very helpful, feedback.

Here comes the useful research note that provides insight into not only the classroom, but the business world too (I refuse to say "the real world", because schooling is real; where ever you are at any moment in time is your real life).

Novices have a very hard time with abstract rubrics. The question becomes how to operationalize a rubric for the particular level of students you are working with? (CS1, CS2, an upper division course)? We have research about how novices become experts and how along the way they gradually become more able to deal with abstraction. Thus, the rubric that works for a sophomore level software engineering class is probably not the same one you'd use for a senior level software engineering class or for a newly hired software engineer or for a seasoned developer.

A technique, one that Scott is working with, is to create the rubric such that up to a certain point it is fairly concrete (i.e. you can get 90% of the possible points) and after that it is more abstract (you want an A, then you have to go above and beyond). What he didn't discuss, but where my thoughts were going, was that you could take the same (or similar) rubric and start shifting that abstraction point downwards as you work with more advanced students or professionals.

Fascinating idea to consider. Fascinating idea to strategize, design, prototype, implement.