Planet Olin

The video of my DML 2012 lightning talk is up! My blog post transcript is not quite accurate, but it’s close enough, and the message is the same.

Looking back at it with a more critical eye — wow, I’m nervous, and it shows in the stumbles. Not the smoothest talk I’ve ever given (in fact, I remember shaking as I walked off the stage). I talk fast, but I’m understandable and relatively clear, which isn’t too bad — and there are audience reactions (which I remember with gratitude).

All in all, considering that I was running on close to no sleep fresh off a practically-overnight flight to San Fransisco while converting this talk from a 2-person one to a solo one on the plane, it wasn’t bad. (Sebastian was originally a co-presenter, but we hit SIGCSE so exhausted we decided he’d take the brunt of SIGCSE so I could breathe enough to do DML while he went back early to rest). Redoing an Ignite talk is tougher than a normal talk – it’s 5 minutes, slides auto-advance every 15 seconds – so you need to get your timing down. I was running this constantly on the plane, on the taxi… the video makes the slides look more out of sync to my talking than they actually are (the slides I’m actually talking about are a few seconds behind the video).

Need to get more of my talks recorded so I can do more comprehensive post-mortems of what I need to work on. Right now, I know timing, pacing, and fluidity of movement — I’m energetic and that shows, but I use the same movements and gestures again and again, and while I move across the stage, I don’t own it with the quiet confidence really good speakers have.

I’ll practice more.

Whooooo. We just submitted our draft paper to Frontiers in Education 2012. Here’s the abstract of “Work in Progress – From Sage on the Stage to Guide on the Side: Creating an open compendium of teaching transformation stories,” which is licensed CC-BY-NC unlike the rest of the content on this site. I’m not thrilled with the noncommercial clause because it doesn’t allow truly free use, but we’re slowly learning how to work the copyright-in-academia game.

After I get some sleep and figure out better ideas for file hosting (upload everything to github?) than my exhausted brain can right now, I’ll put the rest of the stuff up now that Sebastian and I have submitted the Author’s Addendum that insists that we keep the ability to offer this CC-BY-NC. We also need to make the open data much easier to access. Eventually I’d like to come up with an Author’s Addendum that lets us do CC-BY or CC-BY-SA. Lots of bugs to fix. But I digress, and here’s the abstract, and I’m going to bed.

Many professors are reluctant to transform their teaching practices from “sage on the stage” to “guide on the side” for understandable reasons. Facilitating student work in a potentially unfamiliar setting has a steep learning curve and requires professors to relinquish control of their classrooms without assurance their career evaluations will benefit. However, professors who do transform their teaching practices continue to report exactly the same concerns – so how does the shift happen? This work-in-progress paper describes early efforts to address this question through interviews with professors who have involved their classes in open communities, which require such a shift in teaching practices for successful student participation. We have also adopted a “radically transparent research” approach for this project, inspired by the radical realtime transparency practices of the open communities our interviewees work with. This results in public and collaboratively constructed artifacts with the potential to broaden awareness of and participation in engineering education research, while creating a compendium of teaching transformation stories that can be shared with other professors considering similar transformations to their own teaching practices.

I’ve gotten some people asking how I assigned the copyright to my interviewees for radically transparent research. Since it’s often not clear who owns the copyright to a research transcript by default, assigning licenses (open or otherwise) to content is nigh-  impossible until you untangle that, so it’s a vital first step in the radically transparent research process. It’s pretty simple, though; I want to run this by Purdue’s copyright lawyer, but here’s what I have right now, in please-steal-me template format. Usage should be obvious. We sent this out to subjects via email, directly in the email text, but you can do whatever you like.

INTERVIEWER: <put your name here>
INTERVIEWEE: <put their name here>
DATE: <fill this in>
LOCATION: <fill this in>

INTERVIEWER hereby irrevocably transfers and assigns to INTERVIEWEE in perpetuity, all right (whether now known or hereinafter invented), title, and interest, throughout the world, including any copyrights and renewals or extensions thereto, in the attached transcript of the interview recorded between us on DATE in LOCATION.

If you want something more for your email so it’s not all legalese, you can add…

That should do it. You now own the copyright to this; we don’t. It’s all your call what to edit, what to do, how to license it, and so forth. Let us know what you’d like to do with it.

• If you want to leave your name in or not
• If you want to leave the names of other people/institutions in and identifiable or not
• If you want to cut parts of it or not
• If you’d like to put this in the public domain, license it CC-BY, CC-BY-SA, or something else
• If you’d like to host the file somewhere or if you’d like us to do the uploading/hosting/etc for you
• If you want to scrap this transcript entirely and pretend the interview never happened :)

If we can figure out what you want to be released under what license by the end of DATE, that would be awesome — that gives us time to DO ACTION. Happy to do a call/visit/something if it would help!

Then sign it, ship it, and make sure you keep a (digital or physical) copy for your own records. That’s it. Note that this doesn’t get you out of going through your friendly local IRB if you’re doing human subjects research — but it certainly helps to have this as an artifact when you’re explaining the process to them!

Reading about cognitive apprenticeships brings up all sorts of fun moments. For instance, the ideal way to design an apprenticeship experience is to have students do global tasks early on, then local tasks later. Do something that lets them see the big picture (assemble a whole dress) first before focusing on detailed parts (cut out a piece for a dress).

(Explaining the global-to-local progression of tasks given to tailor’s apprentices) “Reversing production steps has the effect of focusing the apprentices’ attention first on the broad outlines of garment construction as they handle garments while attaching buttons and hemming cuffs. Next, sewing turns their attention to the logic (order, orientation) by which different pieces are sewn together, which in turn explains why they are cut out as they are. Each step offers the unstated opportunity to consider how the previous step contributes to the present one. In addition, this ordering minimizes experiences of failure and especially of serious failure.” –Situated Learning: Legitimate Peripheral Participation by Lave and Wenger, p. 72

And I think: huh, that has some implications for computing education.

1. high level languages (python) first, instead of low-level (assembly, C)
2. teach release engineering first, instead of programming
3. wow, all sorts of stuff seems backwards now.

Sebastian and I make an interesting comparison of case studies. We’re both largely informally taught in software engineering (we’ve had a couple classes by now, but still — I’d say the bulk of our knowledge comes from outside-school) but had opposite sorts of informal educations in software engineering.

When I was 15, I started by learning C/C++ programming; I started small and low-level, and gradually climbed bigger and bigger and higher and higher in abstraction. I’ve never quite gotten the hang of putting together large and complex software projects; I still think in tiny pieces of code. I struggle to see outside the little box I first learned in. Then again, I didn’t realize I would go down the route of “software” as a field when I was younger — computers were a fun thing to play with, but I thought I was going to be an art major.

In contrast, when Sebastian was 15, he started as a release engineer, putting together Linux distributions; if that’s not a giant, complex, and high level project, I don’t know what is. When we first met, I could code circles around him. I think I might still be able to today, but the gap is definitely closing — in any case, he started high-level and with a global scope, then worked his way down through Python, into C, into embedded developent with microprocessors, and… seems totally fine. If you compare our 18-year-old selves in terms of “ready to be hired as a full-time software engineer without going through college,” he wins hands-down.

Looking back on this, I think I’d have liked to learn software engineering release-engineering-first, but that’s not an activity I would have recognized as “software engineering” when I started (“it’s not writing code! but software engineering is all about writing new code!”) — which goes to show you how much about software engineering I actually knew in high school.

Matt, Sebastian, Jan, Danny, myself, and a growing cast of characters from Berea College are working on (the) Craft of Electronics, a curriculum for “college-level electronics in a craft-first (and theory-sometime-later) format, through learning from, participating in, and contributing to the open hardware movement.” We decided that “we’re going to do it in the open from Day 0. Everything’s going to be open hardware, open source, open content, and done the open source way.”

This morning, Matt wrote an email (largely for Danny, a Berea student who is new to open source — but really for us all as reminders) explaining what “the open source way” meant in this context. It is one of the best “how to get started in this project practicing the open source way” explanations geared towards students I’ve ever seen, so I am simply quoting it below (but you should go read it in full).

The below is from Matt Jadud’s email to the Craft of Electronics mailing list.

1. BE BOLD.

As we discuss and begin development of material, do not be afraid to contribute. Do not continually ask for permission to suggest things, edit things, or throw things out. We will typically work with systems that automatically preserve the complete history of what we are doing, so that we can all be bold in making changes to our own and others’ work. Anything that doesn’t work well can always be reverted — and, hence, no change has even the remotest chance of being “damaging.”

Likewise, you are a full peer in this dialog (as are we all)… My point being: don’t hesitate to join in. It does not matter what you do or do not know; it does matter if you are silent, and that isn’t what we’re looking for. We’re currently just brainstorming and exploring as a lead-up to the summer work, and you should chime in anywhere and everywhere you think is relevant.

2. TOSW

Actually, I’ve just encapsulated most of The Open Source Way: http://opensource.com/open-source-way

1. We believe in an open exchange.
2. We believe in the power of participation.
3. We believe in rapid prototyping.
4. We believe in meritocracy.
5. We believe in community.

See the link, and that sums things up. I’ll stop blathering. Ah. One other.

3. RELEASE EARLY, RELEASE OFTEN

We’re going to be working in the open on this project. That means we’ll be discussing ideas before they’re “fully baked,” and the intent is that we will generate a better final product by sharing our thinking and work at every stage of development (as opposed to waiting until it is “finished.”) In fact, the explicit acknowledgement of this model is that nothing is every done, it is just due. We won’t be “done” with this course by September, nor will we be “done” with it in December. It will simply be due by September, and we have to deliver it and evaluate it over the coming term. Then, revision happens.

So, we release our work early (even if it is partial), and we release it often (or, continuously, if it is open). Hence, while we may debate things with vigor, and triage ideas like they’re going out of style, we know that whatever we come up with is just another step.

To summarize

These principles are typically different than any coursework you’ve done in the past. Dive in, contribute, and help us make this excellent. Likewise, the openness in this process means that anyone can join in the discussion and contribute. If you have classmates that you think would like to be part of the conversation, they should feel free to join, to whatever level they feel is appropriate.

I think that’s enough for now. When I have infinite time, I’ll turn this into a page on the website. In the meantime, it’s fine here, and we can point to it in the discussion archive for any other people who join us.

The mailing list is already home to some vigorous discussion about materials, learning objectives, and the like. If you’re interested in electronics education and how to transfer thinking about craft and learning techniques from the hacker movement into the formal academic space at the undergraduate level, please come join us – we would love company.