Posts that are teaching open source-ish

Want to give Mel homework? Help me think of a visualization term project.


I’m taking my last (required) engineering course as a student this semester. It’s a course on visualization based taught by David Ebert and Abish Malik. Basically, dysentery  I’ll get credit for using my computer to make pretty pictures based on giant datasets. Shiny! It’s also my first-ever engineering course with an interpreter (Laurie), more about and I’m sucking up new technical ASL vocabulary like a sponge; this semester is unexpectedly full of opportunities to practice my signing. Double-shiny.

I’ve got to start thinking of a term project, and so far I have a few main ideas — but others are welcome, along with brainstorms on how to flesh them out. If I can get a firm idea before Sep 30, I can prototype an entry for the NSF visualization challenge. Project requirements are here, and my ideas so far are:

A dashboard for Hacker Schoolers which would track metrics of interest based on what people consider relevant to their “becoming a better programmer.” Particularly interesting, I think, might be a visualization for Hacker School facilitators – what ways can we use already public data to give them an overview of what many people are doing at once, with the ability to zoom in, compare, etc. as they want? However, I don’t have a clear vision as to what this might look like, so feature ideas/requests are welcome.

Visual ways to navigate intertwined narrative text for my dissertation, which involves people telling stories in response to other people’s stories (and then the original storytellers tell new stories in response to those responses… so they’re intricately tangled up).

Complex symphonic music as experienced with hearing loss, hearing aids, and cochlear implants. My interest in this area is pretty obvious, but this now seems like the most boring project of the three — I could be wrong, though!

Help me brainstorm, intarbrainz!

In other news: today’s class was mainly adminstrivia and an overview of visualization, which is one of many ways to (literally) “make things visible” — converting numerical, abstract data into a graphical representation. For visual learners (like myself), this is effectively translating into our native mental file format. For practically everyone, visualization frees up much of the cognition involved in processing massive amounts of numerical data, allowing us to use higher-level brain functions to ask and analyze interesting questions (I’d heard this before), and making us more confident in our decisions (I hadn’t heard this before). Some fun viz examples include Chris Harrison’s visualization of Biblical cross-references and a map of the US colored by distance to the nearest McDonald’s.

And with that, I’m off to my next meeting. It’s amazing how much more energetic and happy and just plain kind I am when I don’t pretend I’m hearing — telling people I’m deaf, having accessibility in my classes… even my brother noticed it (“You’re less grumpy with your hearing aids,” said Jason in the minivan last month).

 

 


Learning styles for programmers: active/reflective


This is the first in a series of blog posts based on my Hacker School workshop series, patient “Learning Styles For Programmers, visit this site ” which is in turn a software-focused adaptation of Rich Felder’s work on engineering learning styles. (As you read, click it will become obvious this post started as a transcript of a workshop.)

Learning styles are like personality tests… for education. There are a few different spectrums — active/reflective, sensing/intuitive, visual/verbal, global/sequential — that are helpful for understanding how you operate as a programmer, both in a learning and a teaching role (we tend to teach the way we like to learn). We’ll go through them one at a time, starting with active/reflective.

(Note: if you are a global learner — that is to say, you like seeing the “big picture” first — you may benefit from reading this short blog post on learning styles first to get an overview before diving into the entire series.)

Spectrum #1: Active vs. Reflective

Every mature learner acts, and every good learner reflects… just not in the same order. “Active vs reflective” styles refers to which one you do first: active learners act, then reflect. Reflective learners reflect, then act. An active learner will frequently say things like, “How are you going to know unless we just try it and start messing around?” or “Just start typing. We don’t need to read any more, just go!”  Active people tend to jump in, and then they reflect after they act. They do things, and then they look up and they go, “What the heck have I just done? What did I learn? I need to process this.” And then they process; the processing comes later.

A reflective learner, on the other hand, processes first. They are more likely to say, “Okay, hang on. Before we start this, let’s make sure that we have the pseudocode written. Have we read the language specification? And three textbooks? And maybe we should go talk with an expert, and…” (laughter from the room)

Ok, maybe that’s an extreme example. But reflective learners are at their best after they’ve had some processing time. That is one of the reasons I scheduled my Learning Styles workshop in the afternoon, after I gave a morning talk that briefly introduced the idea of learning styles (along with lots of other ideas).I wanted to give reflective learners a 2-hour break after my first presentation so they could digest the material before they came here. Reflective people don’t usually have questions right on the spot, but if I give them time to think about it, they come back with wonderfully thoughtful questions.

Reflective example: Stacey

A good example of a reflective learner is Stacey Sern, who is a Hacker School alumna. I talked with Stacey on a Monday once — early on Monday, talking about working together on a presentation. We chatted a little while, and then she said “Okay, that sounds great. I can think about that. Tomorrow.”

It wasn’t because Stacey was booked that day. Hacker Schoolers have extremely open schedules. But Stacey will need — honestly need — 24 hours to prepare herself to pair with you. It’s not a question of skills or confidence, because she has both; she just knows that she needs that time to get her mind in the right place. And once she shows up, she is so prepared. She has thought about the problem, scoped it out. But before that time, she will not be ready to pair.

Without knowing about active/reflective learners, it’s easy to stereotype Stacey as being a little slow, when in fact you would be missing out — she is a brilliant programmer. The code that she starts writing after 24 hours of pondering is clear, it’s crisp, elegant, it has lovely architecture, it’s way better than the stuff I start banging out on my keyboard immediately, because I’m an active learner, and so that’s what I naturally do.

Active example: Tom

Hacker School facilitator Tom Ballinger is also an active learner; show him some code, and he’ll immediately start pointing at it and thinking out loud. A lot of you (at Hacker School) have probably experienced Tom’s Instantaneous Code Reviews. Pretty incredible. But that also comes with the dynamic of “I have an idea, whee! Let’s try this path! Uh, okay, that didn’t work. Let’s try that one! Ok, that didn’t work. How about…” Tom shows you everything he’s thinking, including the dead-ends he’s running into, as he runs into them. In contrast, by the time Stacey gets to you, she’s already pruned the dead ends and figured out most of a pathway that will probably work.

Audience question: I can’t fit myself perfectly into this model. I do both active and reflective things. What am I?

That is a great point to bring up. These aren’t binaries, they’re spectrums. You can be 100% active, 100% reflective, and anywhere in between. So you could just be in between.

Also, this “learning styles” stuff is a framework — like all frameworks, it is not a perfect model of reality. (The only perfect model of reality is reality itself.) Rather, it is a tool that you can use for introspection. Do what’s helpful to you.

Audience question: But sometimes I act really active, and sometimes I act really reflective. Is that possible?

It is absolutely possible. If it’s helpful for you to understand yourself as switching back and forth between active/reflective — for instance noticing that you present as more active when you’re coding in language A and reflective in language B — then that’s what helpful to you.

Programming culture favors active learners

What might be happening — my guess, in fact — is that you are on one side of the spectrum, but you’ve learned to function on the other side. Our culture usually favors one side of a spectrum over the other. In the case of mainstream coding culture, the favored side is active learning. Think about programming interviews, where you’re given coding problems and asked to solve them on the spot. That’s incredibly biased towards active learners.

You can pretend to be a style you’re not, but it takes more energy

This means that many reflective programmers — especially the smart, successful ones — have forced themselves to act as if they’re active learners. It’s kind of like how introverts can pretend to be extroverted at parties — and then they go home and completely crash, because they’re drained. And active learners can learn how to act reflective — for instance, when they’re in school and get in trouble for not following instructions, or checking their work, or otherwise making careless mistakes because they skip things in their excitement.

Either way, it takes a lot more energy to operate outside your “native file format,” so to speak. But sometimes there are good reasons to do it. I personally find it helpful to acknowledge that it does take more effort to act like what you’re not, because then it’s a conscious choice you know the cost of, and you don’t end up feeling guilty that something easy for other people — raising your hand and speaking on the spot, for instance — seems so much harder for you.

Sometimes deliberately working outside your style is a useful learning experience

As a learning exercise, you can deliberately try working in a style that’s not your normal style. Again, it’ll take more energy — we all have our preferred modes — but sometimes you’ll learn something new.

For instance, Stacey, the reflective learner I mentioned earlier, found it valuable to pair with people who were very, very active, because she wanted to stretch herself towards more active ways of being. She knew that it would be hard, and that she would not be at her best. And maybe what she learns from that experience is that being more active is difficult, but useful. Or maybe what she learns is that trying to act more active makes her so frustrated that she just doesn’t learn anything, and she had better stick with being reflective. But then she knows something new about herself, and she can choose what she wants to do in the future.

It’s like… I learned the hard way that I’m unhappy when I code in assembly. I can do it, but it makes me a very sad Mel. So now I program exclusively in higher-level languages. Nothing below C or C++, unless I have a really, really good reason to do it. Before, in college, I thought, “There’s something wrong with me. I can’t code in assembly.” So I forced myself, masochistically, to code primarily in assembly for an entire semester and the summer after that, because I thought I should be able to, because I’m an electrical engineer. And I was miserable! (laughter) Now I think “I can program in assembly, but I’m happier when I don’t, and there is nothing wrong with choosing to be happy.”

That’s the point of all these learning styles things, for me. Learning about who you are, what your ideal environment is, how you’re happiest working, so you can find and choose that happiness.

Spanning the spectrum: what does that feel like when you pair?

When I talk about learning styles, I often ask workshop participants to plot themselves across the active/reflective spectrum. Every Hacker School batch I’ve asked to do this has ended up with somebody at every single possible point on the spectrum. This means that at some point during your learning experiences, you’ll probably pair with someone more active than you, and you’ll probably pair with someone more reflective than you.

In fact, I would encourage that. It feels very different to pair with someone who is on one side of you versus the other. Try pairing with someone that is on either side of you to see what that feels like and what kind of dynamic that creates. What’s it like to be the more active one? The more reflective one? See whether you like it, and whether that might be a dynamic that you might look to have — or avoid — in your future programming life.

Pairing active with reflective learners can be a blessing or a curse. If you have an active person and a reflective person pairing, they can either balance each other out — the active person’s diving in and trying out code, while the reflective person keeps an eye out for longer-term, big-picture things — or they can clash horribly. Active people can seem reckless and careless to reflective people, and reflective people can seem slow and resistant to change through an active person’s eyes.

I fall into that trap too. When I paired with Stacey, and she said, “I need time, I need until tomorrow to think,” my instinctive active-learner reaction was “but, but… we could work on it, together, RIGHT NOW!” I had to catch myself and go “wait, she’s reflective… and if I can wait a day, she’ll have this beautiful thing that I can then be super-enthusiastic and active-learnery about with her, instead of trying to drag her along with my half-baked ideas now.” And that’s what we did, and it was great — it was the first Test Driven Learning workshop.

Audience question: I understand the descriptions, but I’m still struggling to identify myself. Is there a test for whether you’re an active or reflective person?

There isn’t a perfect test, but here’s one: take two minutes in silence, right now, to think about a learning experience you’ve had, that helps you form a hypothesis for where on the active/reflective spectrum you are.

(No, really. Do it. Set a timer. In the live workshop, I paused everything and had everyone sit and think for two minutes while I watched a clock.)

(Are you back now? Good.)

Now: this isn’t an absolute test, but the 2-minute wait tends to be a pretty decent litmus test for active/reflective learners. If you felt very, very uncomfortable with this — bored, even — you are probably an active learner. After the first couple of seconds, active learners generally start shifting around, thinking, “Ah, okay. When can we start again? Can I ask you a question?” (In fact, one active learner stood up 30 seconds into the “silent time” and quietly started whispering questions to me. I had to try very hard to keep from laughing.)

Reflective learners, on the other hand, started to smile these blissful smiles. They physically relax. They exhale. Afterwards, they go “Oh, thank you. Thank you! You have stopped for a moment. I can process.” And it’s the reflective learners at my workshops who are always stunned — “wait, other people feel this way?” Because, like I said, our programming culture favors active learners… so we have all these reflective learners pretending to be active, walking around exhausted all the time, thinking they’re the only one and that something is wrong with them.

Audience question: are reflective people better at planning?

That is a pretty common way for it to manifest, but “active” and “bad at planning” are not quite the same thing — although I’m both active and ADHD, so that’s how it sometimes shows up for me! (laughter) Reflective does not mean the same thing as organized. I have meet reflective people who are not organized, as well as active people who are very organized.

However, active and reflective people do look different when they plan and organize. Active people will prepare to improvise — they’ll fill their pockets with the tools they need to parachute in and be reactive — whereas reflective people will tend to plan in the sense of thinking everything through before they do it.

Blogging at the end of a day, for instance, tends to work better for active people. Reflective people, if they blog, will blog at the beginning of the day to think about how they’re going to set it up. So they think about it and then they do it, and then they don’t have to really reflect on it anymore, because they did that beforehand. They know what they did because they’ve set that up, and they’re done, and they walk out the door and they go home.

Audience question: “Do time constraints make you behave more like an active learner?”

Great question. Time constraints can really bring some clarity to the situation and make both kinds of folks feel more stressed, but reflective people will get especially stressed out. They are not at their best when they’re asked to slam up things on whiteboards and type out code right on the spot in front of the interviewer, and they can feel that. It’s painful.

Dealing with active/reflective styles during a job interview

Now, if you’re an active learner and that’s your strength, then awesome. Play to it when you go interview. If you know you are reflective and that’s not how you’re going to function well, think about what you can do. Reflective people often have lovely products, portfolios, and polished deliverables. Think about ways that you can use those strengths to your advantage. How can you steer the conversation so it goes toward the portfolio you prepared? Can you talk with your interviewer and say, “Hey, this is the kind of programmer I am. This is the sort of environment that I excel in. You’re not seeing my best work in a rapid fire algorithm generation task, but let me show you what I can really do.”

That sort of insight is actually attractive and valuable, because it’s rare to see that in folks you’re trying to hire. If you think about it, your manager’s job is to figure out how to make you the most effective programmer you can be. If you tell them how you can be most effective, then you’ve done a lot of the job for them. If you know some the stuff about yourself and the implications that that has for your optimal work environment, tell them. It’s rare and impressive, especially for more entry-level programmers, to have that type of insight.

Learning strategies for active and reflective learners

Let’s talk for a moment about things that active learners and reflective learners can do. If you’re an active learner and you’re forced to sit through a lecture, you’re probably going to get really bored. So recognize that and give yourself permission to take really weird notes or mess around on your computer or to otherwise do something while you’re listening.

Similarly, reflective folks. If you need more processing time, you need more processing time, and you should take it. Be okay with not asking questions right at the end of a lecture or talk. Maybe have a strategy of asking for the speaker’s contact information: “That was a great talk, and I think my brain needs a little time to process it, because there were so many good ideas! May I email you with notes and questions once I write them up?” Also, tell your teammates! You can ask your teammates to pause and say, “Can we stop and think about this, take a coffee break, and come back in 15 minutes?” You’ll make other people function better because you’re forcing some of them to take breaks they don’t realize they need.

If you want more, Rich Felder has a funny case study and more tips for active and reflective learners, and my earlier blog post on learning styles had programming-specific tips.

Ironically, Rich’s says that it’s the reflective learners who have an advantage, because he’s a professor writing from within the context of school — where we are expected to sit still and think! So I think we have an interesting dynamic here in the programming world, because there are so many talented programmers who are very active. They did not do well in school because it was such a reflective-biased environment… so what do they do? While their reflective classmates got A’s and became CS professors, some of these active people dropped out of school and created a work environment that swings in exactly the opposite direction, and voila, we have an active-biased non-school programming culture. That’s a gross oversimplification, of course. But it’s interesting to think about it that way.

Teaching strategies for active and reflective learners

As I mentioned earlier, we tend to teach the way that we ourselves prefer to learn. The corollary to this is that we often find it easier to teach people with similar styles, and we tend to to be… less good, shall we say — at teaching people with styles different than our own, unless we pay attention to adapting to them.

I myself am an active learner. Hacker Schooler Bert Muthalaly is also an active learner, and during the workshop I called on him, unprepared, to give some anecdotes about his Hacker School experience. Active learners (if they’re not shy) tend to do better at this than reflective learners — improvisational audience participation keeps them on their toes. Active learners tend to be a lot more comfortable and good at saying things on the spot, asking questions right away.

As a teacher, my probes of active learners are designed to get them started. Sumana Harihareswara (also a Hacker School alumna) knows I’m super-active, so she will nudge me — “hey Mel, how’s the Hacker School book project going?” and BOOM! That’s the best way to get me working on that book again.

As a teacher, I also need to make sure my reflective students are learning. I would never, ever put a reflective person like Stacey on the spot like that. Instead, my probes of reflective learners are designed to encourage them to ship and share what they already have. “Hey, that’s a wonderful blog post. Could you summarize that in the middle of my talk tonight?” I also build thinking times into what I do, and make space for my reflective students to reflect. For instance, the 2-minute “think silently about a learning experience” litmus test from earlier in this post was an attempt to make some thinking time for reflective learners in the live workshop.

I’ll also frequently pose questions in my talks, then prompt people to think about them silently for 1-2 minutes. This is helpful for reflective learners, and awkward for speakers because it means you’re standing in front of everyone twiddling your thumbs for 120 seconds. But your audience is thinking, and they can’t think unless you shut up!

Sometimes I’ll do that silent thinking prompt for the reflective learners, then ask everyone to turn to their neighbor and share answers — that one’s for the active learners. And then sometimes I’ll ask if any pairs want to volunteer their answers for the whole group. This is a teaching technique called think-pair-share, and it’s a technique a lot of teachers learn, because when we’ve done education research, we’ve found that combination is effective. There’s something for everyone.

Another way I tried to get both styles into my workshop was the way I asked people to indicate where they were in the spectrum — there was a period of 5-10 minutes where I was not talking, because people were filing up and putting a sticker with their name on the wall to show where they were on the spectrum. The active people got to do something: write on a sticker, gather happily around the wall, help others put their stuff up, debate whether someone ought to be here or there — and the reflective people plopped their stickers on the wall and sat and pondered. Micro-breaks are good.

Pairing with active and reflective learners

This also applies to one-on-one things like pair programming, when you may not formally be teaching someone, but are mentoring or otherwise working with them. Give reflective learners the material to process beforehand — let them read your code in advance. If you’re reviewing their code, write notes on their code first, and send them those notes before you sit down to discuss it. Give them a list of questions to consider before you meet. Build in breaks and breathing spaces into your work time. Let them stop, go off by themselves, and read a book about your project until they’re ready to come back. And reflective learners, educate your partner to recognize and honor that you need these things.

In a way, it’s similar to extroverts learning to work with introverts. Your introverted friends love you, extroverts! They just need to recharge so they can be near you! Well… your reflective colleagues love you, active people! You just change direction so fast sometimes that they lose track of where you’re going, and how they can accompany you!

And when you’re working with active learners — let them run around! Give them things to respond to. Spit out answers fast, think out loud — they’ll often prefer something immediate and half-baked to something slow and totally baked, because they may not like the totally-baked thing you finish up, whereas if it’s half-baked they can jump in and help you shape it. It’s like the open source mantra of “release early and often.” Don’t worry about going down dead ends; they want to wander through that maze with you!

Next up:

That was active/reflective. We’re going to go through the other learning styles a bit more swiftly. I’m taking more time to unpack this first spectrum so you get the idea of how to play with these ideas. The next post in this series will be about sensing/intuitive programmers.

This blog post series would not exist without the persuasion and gracious editing of Hacker Schooler (S’14) Maia McCormick, who convinced me to do better than “let’s just dump transcripts on the intarwebz!” Thanks, Maia — and everyone at Hacker School who exhorted me for the past year to record this talk! Further edits/questions/suggestions are very, very welcome; comment away!


Stephen’s question: how do you tutor fellow researchers in programming?


Stephen recently asked for advice on how I’d teach programming using Python to fellow academics. Specifically, anesthetist an English major and a Materials Science (Matsci) researcher — smart people deeply into their own disciplines… who happen to not have had programming experience. Here’s what I said; if you have more comments/advice for Stephen, leave them in the comments.

Showing them the fundamentals in a common way, then diverging into their disciplinary interests, sounds about right. If they’re both completely new to programming, you’ll have a little while before they really branch off.

If you want a common starter text, Think Python may be good for this specific case. Just skip the sections related to graphics (Turtle at the start, Tkinter at the end). I also enjoy (and under different circumstances, would recommend) Learn Python The Hard Way and Dive Into Python, but the former is more geared towards web development and the latter is for people who have programmed in another language before.

For your English major friend, one of the exercises gets you into Markov analysis/generation of texts. This should be a fun place to play with poetry. The Markov Bible is a hilarious example of the sorts of things that can be done, and people have written entire books on text processing with Python.

For your Matsci friend, who you said was interested in data analysis, Allen’s next book starts playing with things like census data — that exercise should start being doable around the same time as the Markov analysis, because they’re both fundamentally about “read from a file, do math, spit out to a file.” They’ll probably want to jump off into SciPy at some point to make plots and crunch more complex data.

For a fun change of pace and/or an intro session and/or while people are installing software on their machines, you can try CodingBat exercises. The Boston Python Workshop’s exercises for Friday and Saturday are a tiny manageable collection. This also gets them into the habit of test-driven development (which is also a good approach to curriculum design, although I need a new name for it because Test Driven Learning is already taken).  CodingBat problems are very basic, so this only applies for the first few sessions before it’ll get too easy for them.

I would structure your learning sessions primarily as pair programming time. They’ll learn from each other’s approaches, debug/unstick each other naturally, and learn how to cleanly structure and communicate about code. If you have them pair-program their way through the book, you can spend a chunk of your time writing your own dissertation while being on-call, as in passive pair programming.

Whatever you do, teach them fundamentals of software engineering as you go along — commenting, testing, and version control specifically. Software Carpentry has good resources for this sort of thing. With the same rationale, take the first session and have them make and use github accounts while working through their starter exercises for the sake of everybody’s sanity. This gets them in the habit of working in public, which is important if you ever want to…

…introduce them to a broader community of programmers, which you should do as quickly as possible. Whether that’s “hey folks, join this Python mailing list” or “let’s go to a local Python meetup and get you asking questions — I’ll go to your first one with you and model this introducing-self and question-asking thing in programming-land” or whatever you have around in your neck of the woods, it’s basically the act of teaching them to learn from people other than you. And then… they’re off, and they don’t need you any more to keep learning and doing what they want to do. It’s a great job, making ourselves obsolete.

Hope this helps, and good luck.


Test Driven Learning: setting learning goals for yourself, Software Engineering edition


Stacey asked me for a refresher on Test Driven Learning for Hacker School, prescription so here we go.

Test Driven Learning is a software engineer’s articulation of Wiggin & McTighe’s Understanding by Design framework after being strongly influenced by Ruth Streveler’s ”Curriculum, ascariasis Assessment, sickness and Pedagogy” course at Purdue.

Many software engineers are familiar with the process of Test Driven Development (TDD).

  1. Decide on the goal.
  2. Write the test (“how will you know if it’s working, exactly?”)
  3. Make the code pass the test.
  4. Celebrate.

 

Test Driven Learning (TDL) simply says “it’s the same thing… for your brainnnnn!”

  1. Decide on the goal (“learning objective”).
  2. Design the assessment (“how will you know if you’ve learned it, exactly?”)
  3. Go through the experiences/etc. you need to pass your assessment.
  4. Celebrate.

 

That’s it. Really.

Step 2 is the part most people flub. With software tests, you have a compiler/interpreter forcing you to be precise. With learning assessments, you don’t — but you need exactly the same level of precision and external execution. If you asked a group of external people (with appropriate expertise) whether you’d passed the assessment you set for yourself, there should be no disagreement. If there’s disagreement, your assessment needs a redesign.

A good assessment is a goal that helps you stretch and reach it; sometimes it encourages you to do more. But sometimes it also gives you permission to stop doing stuff – you’ve written the code, you’ve delivered the talk, they met the criteria you set —  and now you’re done. You can absolutely set a new goal up and keep on learning. However, you’re no longer allowed to say you Haven’t Learned X, because you’ve just proven that you have.

Here are some rough-draft quality TDL assessments you might start with, and a bit of how you might improve them.

I will learn Python. (What does that even mean? How will you know you’ve learned it?) I will complete and pass any 50 CodingBat exercises in Python. (But I could do that by solving 50 really easy problems.) Only 10 of those 50 problems can be warm-ups, and at least 20 of them must be Medium difficulty or greater. (Does it matter if you get help with the problems?) Nope, I can get as much help as I want from anyone, as long as I could explain the final solution to another programmer.

I will get better at testing. (What do you mean by “testing”?) I write a lot of code, but I’ve never written tests for any of it. I hear the nose framework is nice. (What do you mean by “better”?) Well, I’ve never written a test at all, so even going from 0 to 1 would be an improvement. I could use nose to write tests for 3 different pieces of working code I’ve already written. (Do these need to be big or exhaustive tests?) Nope, I’m just trying to learn what writing tests is like, not get full test coverage on my code… at least not yet. Even if I write a 3-line test that checks out one minor function, it counts as one of the 3 tests. (What does it mean for a test to be “done”?) When someone else can check out and successfully run my code and my test suite on their computer without needing to modify either bit of code, it’s done.

I will understand how databases work. (By “understand,” do you mean the mathematical theory behind their design? Or how to actually implement and use one?) Oh geez, the latter. I don’t care about the math so long as I know how to interface with a database. Any sort of database. (So you need to make a demo.) Yeah, but that’s not enough; I can blindly type in code from a tutorial, but that doesn’t mean I’d be able to field questions on it. (What could you do about that?) I will give a presentation to fellow Hacker Schoolers demonstrating a small database interaction in code I have written. That’s an easy binary to check; either I’ve given the presentation or I haven’t.

Thoughts, questions, ideas? Got your own example TDL assessment (at any stage of revision), or ways to improve the ones above? Holler in the comments.


Chua’s 3 criteria for Radically Transparent Research (things sound silly when I put my last name on them)


Aha! This is the best version so far of my criteria for Radically Transparent Research (website really needs rewriting; it’s currently a mess of writing from my first year of grad school), and which is basically “a methodology for producing Free Scholarship.” I know, I know, there all tons of Open Research movements and projects out there; I’m trying to write an examination right now and will loop back and check in with them again after I pass it, ok?

  1. The work is public and freely accessible.
  2. The artifacts (data, analysis, etc.) used to create the work is also public and freely accessible so that it can be studied and peer-reviewed by communities of practitioners.
  3. The work and its artifacts can be freely modified and distributed so others in these communities can benefit from and build atop it.

“Chua’s 3 criteria for RTR” (or whatever less-silly name I can tack on that later) comes directly from a Free Culture + Academia mashup. From academic-land (specifically, the scholarship of teaching and learning), we have Lee Shulman’s 3 criteria for scholarship (paraphrased):

  1. It is public
  2. It is peer-reviewed by the practitioner’s community
  3. It can be used by that community as a stepping-stone towards future work

From Free Culture, Richard Stallman’s 4 criteria for software Freedom:

  1. The freedom to run the program, for any purpose.
  2. The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
  3. The freedom to redistribute copies so you can help your neighbor.
  4. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

See the connections between Shulman and Stallman? I don’t imagine this is the final or best statement ever (and look forward to seeing what future version comes up), but it sounds pretty good to me right now.


Call for ideas: help design a “Gender/Race/Class” class on “interrupting the discourse that perpetuates inequity”


Our “Gender/Race/Class in engineering education” class has an “open topic” period that I’ve volunteered to help design… which means I’m going to Ask The Internet for help. (Hi!)

Based on our class discussion just now, for sale we are interested in tackling this question: How do we interrupt the discourse that perpetuates inequity in engineering education? (Subquestions: who has access to this discourse as a listener? A speaker? What is that access based on — gender, recipe race, class… age? geography? language? disability? intersections of any subset of that? What strategies do we have for doing this dialogue-interrupting work in professional and personal contexts?)

The course will be Monday, November 18, which is 2 weeks from now. We’re mostly PhD students in engineering education (technical backgrounds, social science research interests, lots of future engineering professors who care deeply about teaching). We have 3 hours in class, plus the ability to ask people to read a reasonable amount (<100 pages, English) before class. I’d love to hear thoughts, especially half-baked ones, on:

  • “learning objective” suggestions — in other words, what do we want to learn during the course of the 3 hours? (Can be fact-based, skill-based, emotion-based, perspective-expanding-based…)
  • “assessment” suggestions — given those learning objectives, how will we tell (at the end of the 3 hours) whether we’ve learned them, and how well? Does not need to be a test; could be questions for reflection on our own, etc.
  • Reading suggestions — scholarly or not. (For instance, Alice Pawley has offered to let us read her CAREER proposal on feminist engineering — a short, highly competitive grant for junior scholars whose committee was probably not used to getting “feminist” proposals.)
  • Activity suggestions — discussions, games to play, short bits of theatre to act out and/or improvise upon, provocative question prompts, etc…

Potential inspiration: our guiding question/framing about “interrupting discourse” came from a discussion on “how do we talk to people about this?” and an interest in intersectionality, especially with disability/access. I’m personally curious about the history of opening these dialogues in STEM: who (tenured? white? male? western?) started the conversations about women in physics, minority races in computing, wheelchair-accessible chemistry labs, etc — and when, and how, and what were the responses?

Comment away! I will post readings (or reading notes, if readings are not freely available), discussion questions/guidelines, and a story of what happened in the class once we run it — basically, whatever I can do to make the experience we’re creating here available and reusable by more people.


EduPsych for Hacker Schoolers v.1.1 (presentation slides)


Once again I have the (incredible) opportunity to be at Hacker School playing around with my “edupsych for hackers” material… I’ve never revised and re-delivered a talk so often, see and it’s good to be forced to see how this material improves with age and experience.

Differences between this and the PyCon Toronto version include the cutting-out of Bloom’s Taxonomy (it’s cool, decease just not high-priority), medstore the separation of nearly all the Felder-Silverman Engineering Learning Styles material to a separate workshop for tomorrow, and dropping the emphasis on (making fun of) academia’s complicated verbiage, because… that’s not the point.

The slidedeck is at http://bit.ly/hackerschool-f2013 and embedded below. Someday, I want to get this talk taped and transcribed.

Edutalk f2013 from Mel Chua

If a broke grad student can do it, you can too: donate to @adainitiative and patch the open world to be better for EVERYONE.


TL;DR – if my work in open source has helped you in some way, disorder please donate to the Ada Initiative, viagra dosage 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, salve 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: revised, expanded, updated


EduPsych for Python Hackers 2.0 is about to go live in Toronto in 45 minutes, troche 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.

Ok, off to hyperventilate!

PyCon Toronto 2013: EduPsych Theory for Python Hackers 2.0 from Mel Chua

Hacker school: introducing yourself to unfamiliar open source projects


These are rough, purchase incomplete notes from my getting started in open source session at Hacker School, sildenafil 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:

  1. 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?)
  2. 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.
  3. 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 yourselfThis 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:

  1. already in the middle of doing a specific helpful task
  2. 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.