TL;DR – if my work in open source has helped you in some way, please donate to the Ada Initiative, which supports women in open technology and culture. Not convinced yet? Here’s why I donated.
There’s a world out there to patch. I love the universe of open technology and culture where I’ve built much of my career and friendships. It’s a wonderful world that can be wide and welcoming — but it also has horrific bug reports of sexual abuse and gender discrimination, along with many more that haven’t been reported out of fear and shame. I’ve lived a few not-so-good stories myself; some I’ve told, some I haven’t. What saddens me most, though, isn’t the bad stories that have happened; it’s the good ones that never will — stories of women and men working together to hack the universe in marvelous ways. If we want to see these stories happen, we’ve got to make a world where they can happen, a world where it’s safe for them to happen. Don’t WONTFIX that ticket; do something. When you care about something, you want to make it better.
We change the world with millions of tiny patches. I’m a grad student; money is tight, and my $64 contribution represents half a month of groceries. I was initially ashamed of my “tiny” contribution, even if it’s a nontrivial one for me. Then I remembered: our world of open technology and culture is built one patch, one line, one edit at a time — and that’s precisely why it’s powerful. It brings billions of tiny, ordinary moments together to transform the world. If we teach it for our code, we can preach it for our giving. If you’d buy me a drink, or treat an open source newcomer to dinner, send that $3-$20 to the Ada Initiative tonight.
Someone’s got to integrate these patches into a whole… and it’d be nice if they didn’t burn out in the process. Honestly? I support the Ada Initiative because it does this work so I don’t have to. I’m young and energetic, but I’m often wiped out just being a woman in open technology and culture. It’s not just physical and mental exhaustion; it’s emotional and psychological, which is worse. And being an activist is harder still. Do I agree with everything the Ada Initiative says or does? Nope. But it’s a job I want done, and I don’t want the job. This is why we hire maintainers for Free Software; we give them the gift of bandwidth so they can help us contribute more for a project with less effort by supporting and connecting our patches with the bigger picture. Val and Mary are good maintainers for feminism in our open universe — and I’d like more. After all, it’s a big world out there that we’ve got to work on.
The last day of their fund drive is tomorrow. (I’m coming late to the game; summer travel + school year start + RSI = no internet for Mel.) But it wasn’t too late for me to throw in my $64 patch this morning — and it’s not too late for you to contribute your patch today. If my work in open technology and culture has touched, helped, or inspired you in some way, please help me pay it forward and create a supportive, welcoming environment for everyone in the open world.
EduPsych for Python Hackers 2.0 is about to go live in Toronto in 45 minutes, which means it’s time to upload slides! Questions, comments, etc. welcome as usual. This is an expanded, revised version of the previous EduPsych-For-Hackers talks I’ve given, so if you’ve seen both, I’m curious what you think of the changes.
Also: my parents will be in the audience for the first time (since I started speaking over half a decade ago), so they get a special call-out on slide 29.
These are rough, incomplete notes from my getting started in open source session at Hacker School, cribbed from chat notes taken by attendees (thanks, folks!)
We started with a replay of the 5 minute exercise wherein participants dump me in the middle of an open source project I’m clueless about, and watch me think-aloud as I desperately try to figure out what’s going on — basically, “how does an experienced hacker evaluate an open source community?” This time I had 10 minutes, so I got pretty far checking with out Ogre3D (which looks great).
Our first big goal for the session was lurking. You can find projects on a topic by searching the internet for “[topic] open source” (or “[topic] Free Software,” or so forth). When you have a few potentials, ask yourself:
Is this project alive? Are code commits recent? Are mailing list messages recent and responded-to in a timely, helpful manner? Are people using this software? (Do you want to use this software? Can you figure out how?)
Is this a community I want to be part of? (Do they treat each other well?) The people are more important than the code; they’re the ones who make the code, and with release cycles that average 6 months, the code moves so fast that your relationships are what will really orient you.
Where do they hang out and do their work? (What chatroom — usually in IRC — do they use? Do they have a bugtracker or some other giant shared to-do list for the project?) Once you find out where you can overhear things, you can figure out who you’re overhearing, and then start contacting them directly: “I’ve seen you answering questions on X; can you help me navigate X?”
Most projects have communication methods for code and not-code, and for asynchronous and synchronous work. Try to lurk all four. The table below may help.
Synchronous Code: git commits (announced by a bot in chat, sent to a feed, etc)
Synchronous not-code: chat (typically IRC)
Asynchronous Code: issue/ticket/bug tracker
Asynchronous not-code: mailing lists or forum, AND wiki
Our second big goal for the session was introducing yourself. This usually happens by sending an email introduction to the developers mailing list, then referencing that email (find the URL of your message in the mailing list archives) during initial chat conversations with people. Maggie brought up “submitting a pull request as your intro letter,” which is a great idea. What this means is that your introduction email should explain how you are:
already in the middle of doing a specific helpful task
and what you’re asking for is help doing that specific helpful task.
This sounds intimidating until you realize “something useful to help” can be very, very small. For example, Rebecca emailed tent saying that she’d been working through their documentation and had ideas for how to improve the clarity of the particular docs at a certain URL (specific helpful task!) and was wondering where to submit her changes (help me do it!). Jade emailed GIMP offering to test patches (specific helpful task!) and asked which branch and patches would be most helpful to verify (help me do it!). None of these tasks involve deep knowledge of the code; that comes later. They involved “writing in English” (not a problem for most Hacker Schoolers) and “compiling C” (not an impossible thing to learn, especially when you’re surrounded by programmers eager to teach).
It’s helpful to pair with someone and peer-pressure (positively!) each other to ship your intro emails.
Here’s the transcript of the seminar “Psst: wanna eavesdrop on my research?” [materials] I delivered on Thursday about applying Free Culture / Open Source practices to qualitative research (for the engineering education department at Purdue, hence the disciplinary focus). I’ve edited in some context for readers who weren’t there, and anonymized audience comments (except Jake Wheadon’s interview — thanks, Jake!) and the transcript cuts out before the last 2 audience questions, but otherwise this is what happened; click on any slide’s photo to enlarge it.
This will be a slightly strange seminar; I’ve had at least half a dozen people e-mail me and say they can’t be here but would like to catch up later on. So we’re interacting here and it’s being recorded by Boilercast and transcribed by Terry over there.
The title is long and fancy and we’re going to ignore that.
I’m Mel. I think you all know me. I’m a Ph.D. student here in engineering education and one of the things I do is qualitative research, because it’s fun. I also come from the hacker world, the open source, open content world where there’s this radical transparency culture that defaults to open and share everything about what they’re doing.
This is Terry. She is a CART provider and the one responsible for typing super, super fast on our shared transcript document. The URL for the live transcript is on the slide for those of you who are following along on Boilercast. You should know that all of the recordings and the documentation and so forth we’re producing in the seminar will be open data. That means a couple of things.
First of all, the document that Terry is transcribing in is a collaborative text editor and you can type and annotate and fix spelling or whatever you want. It will be the canonical record of our discussion. The second is, as we’re recording this, no names will be taken down. So it’s not going to say I said this and you said that and this person said that other thing. It’s just going to be “person in room” said words. If you want to be off the record, if you don’t want Terry to type down what you’re saying, say that before you speak and she will stop typing for a moment, or if you see something in the document you can go and delete the stuff you said if you don’t want it on the record. The document will be available for editing right after the seminar as well. I probably won’t read and post the final version until sometime after dinner. So you can also take out stuff you said afterward if you don’t want to be captured here. The ground rules are also in the document.
This is what we’re going to be doing today. It’s a bit of an adventure. I’ve been playing are something called radically transparent research. There’s a website and it’s out of date and once I finish my papers I’ll fix it. What radically transparent research refers to is this: what if we did engineering education research, or any kind of qualitative research, as if it were an open project? Make the data open, the analysis open in terms of both being publicly available and open to anyone who wants to participate, and not having a delineation saying “these are the official people” on the project and “these are not.”
What would it look like if we defaulted to open instead of defaulting to closed? So what we’re going to do is we’re going to do a little RTR — radically transparent research — project right here in this room. We’ll be collecting data, going through the licensing process, seeing what analysis looks like, and dissemination — we’ll get back to that. We’ll see a few examples of other projects that RTR is being used in and then we’re going to loop back and and do an instant replay of “okay what the heck just happened?” I’m hoping as we go through the steps they’ll seem fairly logical, but then when we go back and compare them to the normal way of doing qualitative research they’ll start seeming really weird and the implications of the pieces lining up will start piling and piling and piling.
(Note: this was a 45-minute talk, so for the sanity of feed readers, I’m going to say “click to read more” here.)
I had the privilege of spending several days last week at Georgia Gwinnett College with professors Nannette Napier and Evelyn Brannock, alumni of our 2011 Professors’ Open Source Summer Experience (POSSE) cohort. They work you hard, these Georgia profs — within the first 24 hours of my landing in Atlanta, I’d spoken at 3 classes, had lunch with Science and Technology faculty and a meeting with the dean, gone on a library tour, hosted a Google Summer of Code application prep session, and delivered an all-college Tech Talk on humanitarian free/libre/open source contribution as a career stepping-stone. [slides]
In addition to a stroll around the CNN Center and Centennial Park, Evelyn and Nannette introduced me to tomato aspic and fried chicken livers at The Colonnade. The former is a virgin bloody mary in gelatin format and is… edible. The latter is a very, very good idea (om nom NOM). Then there was Magic Bread, a basket of sweet, malty, butter-laden pillows of goodness. They are supposedly called “yeast rolls.” I like my naming better.
On my last day there, I spoke in front of a group of K-12 (mostly middle-school) teachers in for a Saturday workshop on computing while middle school girls played with Scratch and Lego Mindstorms next door. Of all the moments I had in Georgia, this surprised me the most; the workshop was jam-packed, fast-paced, INSPIRE CHILDREN go go GO! and normally I’d jump right in and surf that wave of hyper, even ratchet the speed up a notch — but this time, the wave rushed through me and then past me — and I was aware of it but not swept into it; a strange experience for me. I heard how fast people were talking. How little they were breathing. These were teachers with no technical background who’d been suddenly asked to teach computing. I wondered what that pressure felt like, having to teach kids something you didn’t know and had no time to learn. What could I give them, if what they really needed was more time –
And suddenly I was being introduced (fast! high-energy! She has INSPIRED CHILDREN go go GO!) and I was up front, and pulled a chair and sat and looked at them and breathed –
I remember only vaguely what I said; this talk came from a different place; a quiet place, a gently rooted one. I told them stories of the 15-year-old girl I used to be. I spoke about uncertainty and shyness, needing to watch and be safe, having my fears and hesitations accepted as a valid thing and held so I could address them in my own time. About creating space and letting go and knowing you’re fine even if the world is yelling faster! you’re behind! and how wrenchingly difficult it is to stand there and create a peace amidst the pressure. About the patience needed to let playfulness and ownership emerge and intertwine. About giving yourselves permission to show those around you — especially the kids — how a grown-up learns new things in an unfamiliar space. I sat up there, speaking slowly, looking into eyes. I had the strength of gentleness and all the time in the world, and I could share it. The room’s energy relaxed and softened, and it felt — in a very small way — like hugging a tiny corner of the universe.
Yeah. Like I said, it was the strangest thing. I’ve felt this quiet power once before, during my last brief remarks on a 2010 panel at UIUC. I don’t know what this space is or when I will be back, but I suspect that silence (one of my biggest fears) is guardian of its doors. I’d like to stand here more, though. It feels… right. It’s very difficult, and I’m not sure if I would say I’m happy when I’m there, but I am more… me. So I will continue learning towards that.
Thanks, Georgia. Thanks, Nannette and Evelyn and GGC. Thanks, tiny corner of the universe — you hugged me back.
(Disclaimer: I’m transcribing my own talk about a week after having given it, but I am deaf, so I’m typing this out through a combination of residual hearing, remembering what I said last Thursday, lipreading myself in the video, and reading slide content. It’s probably 98% accurate; patches welcome on Universal Subtitles.)
A friend and fellow PhD student asked for points of advice on starting a research blog, mentioning his hesitation to put “non-polished” stuff out there because he’s used to getting everything peer-reviewed. Here’s my reply.
1. It’s a blog. It’s not supposed to be peer-reviewed. It’s often going to be crap. (Think lab notebooks and memoes.) Put a disclaimer at the top, big and bold, that THIS IS ROUGH and SUBJECT TO CHANGE and whatever else makes you feel comfortable that people will read your work as you intend it to read — as rough stuff you’re kicking around — and do it.
2. Publicly accessible is not the same thing as heavily publicized. If you start a blog (on wordpress.com or whatever), in the beginning nobody will know about it, and nobody will find it, because the average person doesn’t wake up one morning and think “ooh, I wonder what would happen if I typed in a random URL like random-person-research-blog.wordpress.com…” — point being that your early readers will be the people you send links to, so they’ll be friends and colleagues you choose to share with (I’d love to be one, for the record) and they’ll pass the link on to people *they* trust with context of their own, and so forth… so you can think of this as making it much easier for your friends to share your work with their friends.
4. I think that’s most of it, really. And I will actually go blog these posts up quickly now.
5. Oh — that brings me to my last point. Emails make great blog post starters. Anytime you send a work-related email that gets into a decent explanation, think “could I blog this if I changed a few details for anonymizing?” This one did.
Description: I’ve taken two years of graduate courses in engineering education. I save you $50k in tuition and hundreds of hours of reading and give you the short version for Pythonistas who care about education and outreach.
The slides for my talk are below; video will be coming soon at this location (it’s not up yet, but I’ll update this blog when it is). [Edit: it's up!]
After the talk, I was asked where to go for more information about the Dreyfus Model for Skill Acquisition and how to counteract the phenomenon that people at the more experienced levels don’t remember what it was like at the less experienced levels. The Dreyfus brothers wrote several things about their model; the most often-cited is the book Mind Over Machine. It’s a good book, but their ideas about skill acquisition evolved as they wrote about it — so if that’s what you’re focused on, I would look to their most recent 2008 essay on mastery (doc) for a description (also, it’s freely available online). Here we find some clues as to why experts often forget how to teach novices.
The first clue is the notion that an “immediate intuitive response… characterizes expertise.” You no longer think about the decisions you’re making, you just do — and if pressed to explain why you did what you did, it’s difficult; you can’t describe rules you didn’t use. It just “feels right.” That’s really the gist of it; unless they’re very conscious of their actions, it’s easy for experts to forget that not everyone can “read” the surrounding context as fluently as they do.
The literature on situated cognition and cognitive apprenticeship describes this a bit more fully. Brown, Collins, and Duguid’s paper “Situated Cognition and the Culture of Learning” talks about (on page 37) how many times, practitioners won’t be able to even execute their normal work outside of context; they won’t be able to remember or describe things when they’re standing outside their workplace (it’s so much easier for me to type a new Python program off the top of my head than to stand in the center of a room and recite it out loud). That’s because our mental representations are embedded in the context of our workspace (fancy word: “indexical representations”). In the “history” portion of my presentation, I talked about how (according to one paradigm, anyway) learning is situated — but by the same paradigm, once you’ve learned knowledge, the knowledge stays situated too!
Going along (this is from p. 34 of the same paper), when we transfer an authentic, situated task into the classroom and transform it into a sterile, context-less thing, we create problems for both learners and teachers (if the teachers are experts). The experts don’t have the context they rely on to navigate their tasks intuitively; they’re stuck with rulesets they no longer use. The novices, on the other hand, don’t get the chance to learn how to navigate the richness of a real-world context. When we do this, we usually say we’re “cutting out the noise,” but that “noise” is actually a large part of the point; people need to be learning in context. This is like handing someone a Wikipedia page on A Midsummer Night’s Dream and saying “I’ve just saved you so much time — now that you’ve read the plot, you don’t need to go see the play!”
Several counter-actions to this are possible. First, just being aware of this phenomena — having the Dreyfus stages as a tool with which to think about your own skill level and the skill level of your students — is tremendously helpful. Donald Schoen describes this sort of thing as knowing-in-action and reflection-in-action, ideas that are themselves useful to read about; his essay “Knowing in action: The new scholarship requires a new epistemology” is a good starting point, especially pages 29-32 (from “Turning the Problem on its Head” until you reach “Project Athena at MIT”).
Now you’ve got experts teaching in the context they’re skilled at navigating, aware that they see the world differently than their students, and reflecting on their actions as they go along (or at least that’s what you’re trying to have, anyway). So how do you teach — what strategies do you use to structure and design experiences in the classroom? For this, I’ve found the framework of cognitive apprenticeships a useful one. “Cognitive Apprenticeship: Making Thinking Visible” is a good starter and has teaching examples embedded within it.
To bring this all together in an example that really happened during PyCon: let’s say I’m Aleta Dunne, the maintainer of planeteria, and I meet someone named Mel Chua at PyCon, and she’s interested in poking around the code and maybe submitting a patch.
The first thing I’ll do is to stay in this context. I’m going to take Mel to the actual code instead of trying to talk about it only abstractly and from a distance.
Second, I’ll think about where I fall on the Dreyfus scale here… perhaps I don’t feel like I’m an expert yet, but maybe I’m proficient.
Then I’ll think about where my “student” falls… hrm, this Mel person is pretty new to this particular codebase, but she seems to have seen some code before. She can’t yet prioritize what chunks of code are important here, though — that’s a sign that she might be an advanced beginner.
Aha. As a proficient person, I can prioritize what’s important — and as an advanced beginner, Mel can’t yet. So prioritizing problems is something I will probably need to scaffold her on as we progress. (For those who saw the talk: Aleta is thinking about bringing “prioritization” into Mel’s zone of proximal development, because Mel can’t do it without Aleta — yet — but perhaps Mel can do it with Aleta’s help.)
Let me start prioritizing tasks and reflect-in-action to figure out what I am doing — the underlying rules I’m using. Why do I think this ticket might be a good one to work on compared to the other tickets I can see? Okay — now… can I explain a bit of that logic to Mel and see if I can help her walk through a similar thinking process for a second ticket?
…and so forth. It’s not a perfect example, but you start getting the idea (I hope) of how these tools-to-think-with can blend into your actions in a teaching-learning-doing space.
There are benefits to this for the expert-teacher’s performance as well. Further on in that paper by the Dreyfus brothers I linked to earlier, they go on to speculate that for experts in a state of flow, “all of the brain’s activity is focused solely on performance so nothing new is learned” (emphasis mine). Therefore, to move towards mastery, they say that…
“It appears that the future master must be willing and able, in certain situations, to override the perspective that as an expert performer he intuitively experiences. The budding master forsakes the available “appropriate perspective” with its learned accompanying action and deliberatively chooses a new one. This new perspective lacks an accompanying action, so that too must be chosen, as it was when the expert was only a proficient performer. This of course risks regression in performance and is generally done during rehearsal or practice sessions.”
In other words, to answer the question original question directly:
Experts can teach better by backing out of their instincts and deliberately stepping into different patterns with awareness, bringing their students along for the ride.
This is difficult to do (and experts don’t do this often) because it often makes them perform worse and look dumber.
Therefore, to teach better, get over the fear of looking dumb — and when you do that, you’re on the track to mastery.
I attended Allen Downey’s PyCon 2013 workshop on Bayesian Statistics Made Simple; his slides and code are available online (free and open, of course — go Allen!) Bayesian thinking (“given these results, how likely are my hypotheses?”) is powerful, simple, and a mind-flip for folks like me used to frequentist statistics (“given my hypotheses, how likely are results I don’t yet have?”). The Python library Allen developed for his book makes it easy to nest multiple levels of specifications describing our assumptions; since I find typing out clean, modular code consumes far less mental RAM than manipulating abstract math symbols on paper, that suits me just fine. We went through basic problems such as:
If I’ve seen N enemy tanks with the following serial numbers (and assume enemy tanks are numbered sequentially starting from 0), how many total tanks does the enemy probably have — and how does my guess change as I see more tanks?
If I have the results of a repeated coin-flip, what is the probability that the coin I flipped is fair? (Hint: it depends on how you think the coin may be unfair.)
If Alice scored higher on the SAT than Bob, what is the chance that Alice is smarter than Bob? (What assumptions do we make about the SAT, test-takers like Alice and Bob, and the nature of intelligence?)
The budding researcher in me took notice when Allen presented examples of more things one could do with Bayesian statistics. For instance, b
y looking at my dataset from a first experimental sampling run… say I interview students and find 3 students who love thermodynamics, 2 who hate it, and 15 who don’t know what it is — I can start making inferences about:
How many other opinions about thermodynamics might be out there that I didn’t get in my first trip to the field?
How many more students will I need to interview before I have X% confidence that I have gotten Y% of the existing opinions about thermodynamics expressed?
What’s the proportion of students who love, hate, etc. thermodynamics — or rather, what’s the probability that, in the entire population of all students I could ever interview, X% will express this opinion? (In my first sample, 10% of students loved thermodynamics. What’s the probability of the “real” proportion of thermodynamics-lovers in the general student population being 10% — versus, say, 50% of students loving thermodynamics and me just unluckily missing them? How would my confidence in making the claim “10% of students love thermodynamics” increase if I interviewed more students?)
…all given certain assumptions, of course, such as assuming my sampling is really random — maybe the thermodynamics-lovers were all at a thermodynamics conference when I went looking, or assuming students will express a clear, “truthful” opinion on thermodynamics to me for some value of “truth,” and… As with all modeling techniques, these guesses are only as good as my model. But the neat thing about Bayesian statistics is that it’s easy to tweak facets of my assumptions and see what changes in predicted results ripple out from it. So it’s a thinking tool that’s good to have, in any case.
I also picked up pedagogy from Allen’s workshop. It was immediately clear to me how he had used his in-progress book and research blog on the same topic to scaffold the construction of his workshop, and that was a lesson in and of itself; all three share the deliberate, incremental, self-teaching style I associate with Allen (who was one of my professors in college). Although we both believe in transparent science, our teaching styles are vastly different; Allen leads large groups down a well-marked trail, scaleable and reproducible, moving with the clean efficiency of experience. He’d be an excellent MOOC professor. I like scattering my groups loose to wander in a rawer pasture, building discussion around surprising things people stumble into — a different improvisation every time depending on who’s there. Both styles have their pluses and minuses, and Allen’s an old hand at his style whereas I’m barely a journeyman in mine. I come from teaching full-week, all-day workshops and semester-long classes, where team dynamics and wandering comfort can evolve and distributed group improvisation is wonderful once you get past the initial discomfort hump. But Allen’s marked-trail style is more expected — and certainly more efficient — for short workshops like the ones we had, so I’ll try to adapt my materials more to that teaching technique next time I have a 3-hour workshop to run.
Speaking of which — I succumbed to exhausted sleep too early last night to post materials from my workshop; I’ll need to find some time in the next 36 hours to do so (note to self: the perfect is the enemy of the good).
Why do pianos sound different from guitars? How can we visualize how deafness affects a child’s speech? These are signal processing questions, traditionally tackled only by upper-level engineering students with MATLAB and differential equations; we’re going to do it with algebra and basic Python skills. Based on a signal processing class for audiology graduate students, taught by a deaf musician.
I’ve pulled the code snippets and some graphs into the slides so that you can walk through the entire thing by working through the slide deck (below). You can also find all the code (with many inline comments, and some more details that didn’t get into the slides) on github.
Tutorial attendees will note that the vocoder demo is still forthcoming — I’ll make a blog post when that’s up and update this post to link to the vocoder demo when the time comes.