Thursday, October 11, 2012

Sketching in the Computing Classroom

Once convinced by Sketchcamp San Diego that what you draw is good enough and that you should sketch anything and everything, the next adventure is deciding where sketching fits in your professional world. Thus, it was only a matter of time before I would explore how sketching could apply directly to computer science.

I could (but won't) write a treatise on all the opportunities for the professional computer scientist to sketch. Instead, let's ponder computing education.

Instructors, consider this - why not incorporate sketching into your classroom presentations? We know that humans are very visual creatures, but that doesn't mean that all visual presentations are good presentations (Death By Powerpoint comes to mind).  Why not sketch part of your lecture as you give it, especially if you present in a large impersonal lecture hall? Take a look at my previous post for an example of this in action.

Unless you are working out a formal proof, I put it to you that there are plenty of opportunities to draw instead of write on the whiteboard, blackboard, tablet. You have to work out the details, but if you are creative enough to come up with other classroom innovations, as are many of my colleagues in the computer science education world, then you are up to the challenge of adding sketching to your pedagogical portfolio.

No, wait. Let me take back part of that last point. I'd love to see someone work out how to sketch a formal proof. Not only would it be terribly exciting but it would rock many people's world. Just think of the positive effect you could possibly have on those students who currently struggle with the abstraction of proofs.

Then there are the possibilities for collaborative sketching for software engineering students. The yawns and complaints (and subsequent below standard results) with which countless students approach the requirements gathering and specification development process are legendary. Not only do they miss the point, they can be disengaged, and just plain old lousy at client interaction. It takes practice, after all, to be a good listener and communicator.

What about reinventing the "Reqs and Specs" process to include team problem solving with the users present? Applying sketching techniques already used in the professional world, students can iterate on data interpretation and problem identification. Together they will produce a graphic illustration that captures the evolving conversation. What a great opportunity to break down barriers, achieve consensus and clarify intention.  I suspect the sketching approach to specification development would suck in students and their client users alike.

No comments:

Post a Comment