Posts that are teaching open source-ish
Providing conference childcare isn’t difficult or expensive, and it makes a huge difference for parents of young children who might want to come. If your community wants to (visibly!) support work-life balance and family obligations — which, by the way, still disproportionately impact women — I urge you to look into providing event childcare. I don’t have kids myself — but a lot of my friends do, and someday I might. I’ve seen too many talented colleagues silently drop out of the conference scene and fade out of the community because they needed to choose between logistics for the family they loved and logistics for the work they loved — and there are simple things we can do to make it easier for them to stay.
A good number of conferences have already started offering free or low-cost childcare on-site, and Above All Human is one of them. (Above All Human also used a Code of Conduct, another simple way to shift conference culture towards inclusivity and diversity.)
I talked with Scott Handsaker, one of the conference organizers, to ask how they set it up. It was easy. There was an existing daycare facility nearby, so trained staff, equipment, space, and insurance were all taken care of. All Scott had to do was negotiate the price, which ended up being $30 per child. Out of 1,000 people in attendance, roughly 10-15 used childcare, for a total price tag of $300-$450 per day.
The resulting slew of publicity was tremendous. Scott mentioned they were late in organizing childcare — too late to advertise it on the conference website — so they only had a little time to message via email and social media. Even so, childcare was the #1 thing people tweeted about leading up to the conference. (“This [twitter search] nowhere near captures the volume of tweets or the sentiment,” Scott wrote.) In fact, that’s how I found out about Above All Human in the first place — a former classmate raving about childcare on social media. This is the sort of exposure you want for your event, brand, and community. Financing conference childcare was snapped up by Slack as a low-cost, high-impact, high-visibility corporate sponsorship opportunity.
If your conference location doesn’t have childcare on-site, talk with nearby childcare providers or a local college with an education/teacher-training program. You’re looking for care providers with training in early childhood education or some similarly related field, medical knowledge (CPR/AED etc), and enough experience to take care of insurance and logistics, which often involves negotiating directly with the hotel or other conference location about space and setup.
Some conferences have written documentation on their childcare setup. GovHack wrote a behind the scenes look at childcare for their conference, and YOW stands as a good example of how to promote it.
Right now, determined conference committee members can pull something together for their own event by taking advantage of resources like these, as well as tapping into the informal network of conference organizers who’ve coordinated childcare in the past. However, that network can be hard to find — so as more and more events attempt to do this, we can share notes and work to make it easier. A great next step would be to compile more writeups about the childcare-at-conferences process and to list events that have had it and are willing to talk with other events who are interested. Eventually, we could create a series of templates and guides for how to email daycare providers, how to advertise, what insurance to secure, and so forth. If you know of existing resources or efforts, please let me know and I’ll add them to this post.
Edit: Reader-provided resources so far…
- David Nelson Adamec noted that PyCon, a major programming language conference, provides childcare: https://us.pycon.org/2016/sponsors/. “I like that they call out “Company X is our childcare sponsor”, making it a cool thing to be and encouraging others to follow suit,” says David. He also noted that http://geekfeminism.wikia.com/wiki/Childcare has more general tips for organizers.
- Sara Melnick noted that SIGCSE, a major CS education conference (academic) provides a kids’ camp, almost like a parallel conference for children: http://sigcse2016.sigcse.org/attendees/kidscamp.html
- Bonnie Tesch submitted MoMiCon, an academic gathering deliberately designed as a conference format experiment designed for mothers with young children. Some very cool design ideas here.
- Anne Lucietto noted that childcare isn’t the only need — sometimes adult care is needed as well.
- Peter Barszczewski noted that the same setup applies to hackathons.
Preparing to teach a class where you “don’t know the material” is tricky, especially when the thing is so big and so vast that you can never truly be an “expert” in it. If you think about expertise as knowing all the things, that is. If you think of expertise as the ability to be productively lost, that changes the entire game — the trick is how to help your students get through the same sort of territory.
I don’t have an overarching framework of strategies, but we do have a few things to share from the Teaching Open Source world. I wish we had a better write-up of our overall philosophy, but it wasn’t sufficiently developed (that’s something I’d love to work on with others… later… after… thesis…) but you can infer a bunch from some of our artifacts, so here you go, in order of least interesting to most interesting in my heavily biased opinion.
1. We have generic project-helpful activities.
We have a number of learning activites that (1) are highly likely to be useful for students regardless of what project topic they are on and (2) have clear criteria for successful completion, aka they are assessable. Analogous college-type things might be stuff like “make a test plan for your object” or “determine the appropriate formulae for predicting the behavior of your material” (I’m obviously making these examples up in a domain — materials science — I don’t know much about).
2. We have specific tool walkthroughs.
We also have activities that are walkthroughs of specific skills/tools common to most projects, often on a known setup (in the case below, a dummy server). This would be things like “do this intro exercise to use the Instron for the first time with our pre-cut samples.”
3. We have activities about critiquing the work of others (not other students in the class — this is not about peer assessment).
Moving into more interesting stuff: we also have activities that are about looking at other people’s work — not making new things, but critiquing existing things, to start developing a sense of how experts see things. In college, that might be: “Look at these pages from 3 lab journals, compare/critique; what makes the good ones good, the bad ones suboptimally helpful?” The reason it’s not peer critique is that you want to curate the examples to be rich and to have a range of things you can pull out in the discussion. (For those of you with qualitative research backgrounds, you can think of this as artifact analysis.)
4. We have resources (not just live demos) that lay out expert thinking.
We have think-alouds, where (more) experienced people demo their thought process being “productively lost” and then unpack it to newcomers, so they can start comparing metacognitive strategies. Every time you think out loud to students with their project, you’re doing this — but sometimes making artifacts is helpful, too. Also, accessibility is super-important for this… if you’re making videos, caption them. If you’re including images, describe them, and so forth. (My images are screenshots of the linked webpages, so I didn’t put image descriptions.)
5. We frame their mindset explicitly.
We have documents that explain the state of mind / viewpoint / psychological priming we want students to take towards things.
My friend and research colleague Todd Fernandez writes: I know the ODF (Open Document Format) is generally the preferred format from an open documents standpoint. My question is whether you [and other Free/Libre groups] would consider .txt files in Unicode and .csv (comma-separated value) data files considered equivalently open?
First of all, I can’t answer for FSF or other groups — so what you’re getting is the Mel answer to “are .txt and .csv files open?” This email reply is getting so long that I’ll turn it into a blog post.
The Mel answer is “yes.” I consider .txt files in Unicode and .csv to be “open.” In fact, I personally prefer to use them over ODF, which I’m rarely able to open with the software pre-installed on most computers I encounter.
In the paragraphs that follow, I’ll get into more detail behind my reasoning. To define “open” and “free,” I’ll loosely use the Open Source Definition (OSD) and the Free Software Definition, noting that these were created for software and need to be adapted for a discussion on file formats.
In discussing these file formats, I’ll cover .txt first, since .csv builds on top of .txt. The file extension”.txt” can mean a lot of things, and each of those things has different levels of open-ness (from a more legal-ish open standards standpoint, see definitions above) and accessibility (from a “how many people are able to read/write them on their computers with their current software” standpoint). I personally care about both.
ASCII and ANSI
You asked specifically about Unicode, but “.txt” can also mean ASCII, which is/was an American-developed standard for text information. I’ll start here, since ASCII was where Unicode began (in fact, ASCII’s 128 characters are Unicode’s first 128 characters).
ANSI X3.4-1968 is the document describing this encoding. It is a standard that’s widely used and published, lots of programs can access it, and you can use it in your programs without too much effort and without licensing costs (as far as I can tell; I can’t easily find the exact legal status). Basically, if I translate the Open Source Definition from software to file formats, I can’t find evidence that ANSI X3.4-1968 itself contradicts any of its criteria. I know this is different than proving that it absolutely meets all these criteria, but this is good enough for me.
As an interesting side note: ASCII is an ANSI standard (American National Standards Institute, hence the ANSI- prefix on its standards document). ANSI’s definition of “open” is about “do stakeholders have access to the consensus decisionmaking process that forms the standards?” and “are licensing fees and getting permission to use the standard at a reasonable and not overly burdensome level?” rather than “are there no licensing fees and permissions needed at all?” The latter corresponds to part of the 4 requrements for “freedom” according to the FSF, so it’s possible for something to be “open” according to ANSI but not “free” according to the FSF.
It would be interesting to go through and do a more rigorous look on whether ASCII’s legal/licensing criteria meets the Four Freedoms. I’m not a lawyer, but I’d be interested in what a lawyer would say.
“.txt” can also mean UTF, or Unicode Transformation Format; this is what your email asked about. The “A” in ASCII stands for “American,” and “American” in this case meant “monolingual,” meaning that if you wanted to type something outside ASCII’s 128-character, heavily-biased-towards-American-English set, you were flat out of luck. Unicode took the first 128 characters of ASCII, then… kept on going. Unicode is a more internationally-savvy superset of and successor to ASCII.
UTF-8 and UTF-16 are two Unicode variants in common use. The numbers refer to the number of bits per character, which you can think of as “UTF-16 has more letters in its gigantic international meta-alphabet than UTF-8.” UTF standards are developed by the Unicode Consortium, which I keep mistakenly typing as the “Unicorn Consortium” (which would be kinda awesome).
Unicode’s copyright permissions language seem very, very similar to the 4 requirements of the FSF for freedom. Since ASCII is a subset of Unicode, this makes me even more comfortable saying that ASCII is also “open.” However, I am not a lawyer, nor am I using “open” in a legally rigorous sense here — remember, I am a non-legally-trained engineer going “yeah, I don’t see anything that contradicts the definitions made for Open and Free software, if we were to translate it to file-formats-land.”
CSV is a format that’s layered atop plaintext (ASCII, UTF, whatever). In other words, you use plaintext to write a CSV document. CSV itself is not formally specified, which means it’s a free-for-all, and… you can use it for whatever, because you’re pretty much making it up. It’s just that you’re just making it up in the same way lots of other people have made it up.
Then again, “official standards” are just a group of people who have made things up and have agreed to stamp the label of “official” on their work; it’s still a social construct that depends on how many other people agree with them. (I can make something an “official” standard according to Mel, but if nobody else agrees with me, my standard is useless.)
Anyway, I’m not sure if that qualifies CSV as “open,” but it’s certainly not “closed.” To me, CSV is just as open as whatever underlying plaintext (.txt) format it’s using. But again, I’m not a lawyer, don’t work for the FSF, etc. This is just one hacker’s opinion, and I’d love to hear what others think.
Debbie Chachra’s newsletter described what she told undergrad summer researchers in engineering education about their work today, and it struck me deep as someone who’s been an open source newbie and a perplexed undergrad researcher — and then grown into the sort of person that (terrifyingly!) is in the position to mentor both.
[Undergrad summer research] is not a job; the money they get is a stipend, not a salary. Its purpose is to carve out the space and time for them to participate in the program, not to pay them for the work they do… The reason why they get stipends and not salaries is twofold: one, because the summer is intended to be a learning experience above all, and two, because it’s basically impossible to do research to order. You can be directed to do specific research-related tasks, but actually exploring an area, being engaged, and coming up with insights is not something you can turn into a checklist, not least because if you could do that, it wouldn’t be research.
Research can pretty much only be done by people who are intrinsically motivated; that is, interested in and committed to what they’re doing, and not just doing it because they have to. Most of the students have had jobs and all of them are familiar with doing assignments for class; none of them have had an experience like this. So start by trying to get this across to the students: “You are not minions. You are not workers. You are not robots. You’re going to bring your whole heart and mind to what you do.”
This has been my failing — in both roles — many times. As a newcomer to open source and research, I showed up and expected… a job. That’s how you earned your stripes, right? That’s how you showed humility, and willingness to learn… you had to pay your dues. It’s what I had always been taught. And so I showed up in OLPC’s IRC channel and asked Jim Gettys to tell me what to do. I followed SJ Klein around the office like a puppy, beamed gratefully when Chris Ball gave me something to do. I sat in Cynthia Breazeal’s lab waiting for Cory Kidd to tell me… something. Waiting for orders.
It took a long time for me to realize that all these people were waiting for me. I didn’t know they wanted me — I thought they wanted my interchangeable labor-functionality. But no, they were waiting for an idea I didn’t know I was supposed to originate. How could I have known this was the culture, the expectation? I’d never been in a FOSS project before, never been in a lab — my family had never experienced these things. I’d never witnessed a student interacting with a hacker or a researcher. I had the “try things, make them happen!” paradigm, but only in my schools — I thought it was a thing you could do only in those special spaces like IMSA or Olin. I hadn’t been in schools like that quite long enough for that worldview to sink deeply enough into my marrow that it would transfer into all the spaces I would ever walk into.
Then I got a little older, a little more experienced. Failed a lot, learned from it — learned enough that others started seeing me as someone who could teach them. And I tried to impart this worldview shift of “you are not a robot,” but — as we often do when we are tired and under-resourced, I fell back into my habits. I would tell people what to do; I would scaffold a bit too tightly, I would… set expectations. When there’s no room to fail, there’s also no room to fly. I failed my way into becoming a better teacher, a better research supervisor, a better mentor of hackers, time and time again.
When we teachers think about the people who have taught us how to teach, we usually think about our own good teachers. I also think about the students who graciously allowed me to fail them, and stuck around long enough to keep loving me through learning how to be a better mentor to them. I am trying to make my learning worthy of the cost they had to pay for me to grow.
My thoughts from an online discussion with other female Olin engineers on this NYT article on “how to attract female enginers,”, edited for context. In particular, we brought up the (well-worn) claim that women don’t want to “just focus on the tech stuff” and want to “do sociotechnical/humanitarian work that makes a difference in the world.”
I’ve built my career as a “technical community person” who “thinks beyond the technology,” and as a teacher and researcher of learning environments — so this may come as a surprise to people who know and have worked with me. But if my teenage self had had her way, I would have VASTLY preferred to “just focus on the tech stuff.”
As a kid, I wanted to choose the privilege of being oblivious and keeping my head down and immersing myself into the beauty — the sheer beauty! — and joy of STEM for STEM’s sake. I didn’t become an ECE to work on educational computers or hearing aids or anything like that. As my friend (and former roommate) Kristen Dorsey said, “I just geek out about nerdy stuff, OK?”
But I couldn’t “just geek out about nerdy stuff.” The environments where I was trying to “learn about nerdy stuff” were sociotechnically broken in a way that made it hard for me (as a disabled minority woman, among other things) to join in. If I wanted to even start being part of the technical community, I had to start by fixing the technical community — patching the roof and fixing the plumbing, so to speak — before I could even walk inside and start to live there. And when I patched the leaking roof, I patched the roof for everyone, and other people who needed non-leaky roofs to be in the community could now… be in the community as well!
For instance, I got really, really good at facilitating meetings because it was the only way I had to make meetings accessible to me — when other people facilitated meetings, they’d often forget I need to lipread, so… I just quietly started leading them myself, and ended up making meetings work better for everyone. And I found that when I drifted towards “humanitarian” projects, the people there were much more conscious of sociotechnical things and more likely to have already-healthy environments, so I would have less leaky roofs to patch, and less resistance when I tried to patch the roofs — and people actually recognized and valued roof-patching labor instead of looking down on me for not writing code full-time.
After a while of patching roofs and unclogging toilets and plastering the rotten drywall, I got a reputation in industry for being really, really good at open-source software/hardware (technical) community facilitation. It’s almost as if I could only enter the makerspace as a janitor. And part of me resented that, but never said so. But, I told myself, at least I was in the building. And I saw that my “janitorial” work made it possible for other people to enter the building and do the things they wanted to do — which were often the things I wanted to do, too! — and so I thought: okay. That’s okay. At least somebody gets to do it. I can see my gift to the community doing so much good, that I will give up my desire to learn and do the technical things — so I let my own STEM learning slide. I am good at “community work,” and I did come to genuinely love it, over time.
But if I had the choice, I would have never gone into “community work.” I would have chosen — if I had the choice — to focus on “shiny tech stuff” that… didn’t save the world at all. If my teenage self had had her way, I would not do community-facilitation-anything, I would not be thoughtful about women or minorities or disabilities or any underprivileged group in engineering… I would be oblivious to all my privilege. I’d be a kernel hacker, or an embedded geek, or something “hardcore technical,” Because I could be.
But I didn’t have the wherewithal (or the desire) to shovel all the stuff out of the way that I would have to do in order to do that. If you think of “caring/environmental labor” as a sort of tax some people have to pay in order to get to “learning/doing technical things,” my tax rate has always just been too frickin’ high.
So I have been “the full-time community person who is ridiculously good at tech stuff that she no longer gets to do,” instead of “the technical person who understands and listens to and cares about inclusion and community.” Because I cannot not patch a leaky roof. But I have always wondered what I might have grown up into, if I had learned STEM in an environment that was ready for me — without me having to fix it first.
Last year, I wrote a post asking people to donate to the Ada Initiative and support women in open technology and culture. I said:
We change the world with millions of tiny patches… 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. –August 30, 2013
Why do we need to do this? Well, being a woman in open technology and culture is like riding a bike on a street made for cars, where rain and dirt get kicked into your face, and you are constantly, painfully aware that if you have any sort of collision with a car… the car will win. Yes, this is happening in our world, to our friends and to our colleagues; it’s happened to me personally more times than I care to remember. The farther you are from the straight white male difficulty setting, the rougher the terrain becomes.
And quite honestly, we’re busy. I’m busy. You’re busy. This isn’t our job — we have so many other things to do. I mean, we’re all:
- remixing music
- playing with code
- writing science fiction
- co-authoring open content articles
- redesigning user interfaces
- <insert your favorite open technology and culture activity here>
And guess what? There are so many people who want to join us. So many people who want to help us do all this work, but don’t, because they know that work — the good work — is likely to come with a lot of really, really awful stuff, like this sampling of incidents since last year (trigger warning: EVERYTHING).
The less time women spend dealing with that stuff, the more time they have to help us with our work. And the more people will want to help us with our work. I mean, would you want to accept a job description that included the item “must put up with demeaning harassment and sexual jokes at any time, with no warning, up to 40+ hours per week”?
Making our world a good environment for all sorts of people is, in fact, our job — or at least part of it. The folks at the Ada Initiative have made supporting women in open tech/culture their entire job — supporting it, supporting people who support it, and basically being the equivalent of code maintainers… except instead of code, the patches they’re watching and pushing and nudging are about diversity, inclusion, hospitality, and just plain ol’ recognition of the dignity of human beings.
They want to support you. With better conference environments, training workshops and materials, and really awesome stickers, among many other things. (Did you know that the Ada Initiative was one of the first woman-focused tech organizations to actually say the word “feminism”?)
So please, donate and support them, so they can support you — and me, and all of us — in supporting women in open tech/culture.
Now, my own contribution is a bit… sparse, financially. I’m a grad student earning less than $800 a month, and I’m waiting for my paycheck to come in so I can contribute just a few dollars — but every little bit helps. And there’s another way I can help out: I can bribe you, dear readers, to donate.
Remember that “active vs reflective” learning styles post I wrote in August? Well, there are 3 more: sensing/intuitive, visual/verbal, and global/sequential. I’ve got them all transcribed here and ready to go. And if we reach $1024 in donations to the Ada Initiative under the Learning Styles campaign within the next week, I will release them under a creative-commons license.
What’s more: the first 3 people who donate $128 or more to this campaign and email me their receipt will get a free 1-hour Skype call with me to discuss their personal programming learning styles, and will be featured as case studies on one of those three posts (I’ll link to your website and everything).
Donate to the “learning styles” campaign for The Ada Initiative now!
I’m going to gradually share my dissertation proposal here as I migrate it to github and into LaTeX – I’d love reactions, comments, questions, etc! The title is “a poststructural perspective on engineering and technology faculty as learners,” which will hopefully make sense after the first 2 paragraphs.
Faculty are learners, too.
We often think of engineering and technology faculty as teachers. As facilitators of student learning, they hold certain philosophies about teaching and learning that shape their interactions in the classroom. However, faculty are also learners themselves, students of the practice of “teaching engineering and technology.” As engineering education researchers concerned with research-to-practice transfer, the ways we think about faculty-as-learners likewise shape the ways we try to impact their practice. Making this thinking more visible within the engineering/technology domain is of interest to engineering and technology faculty members, faculty development professionals, and adult learning researchers.
My dissertation draws on the traditions of cognitive apprenticeship and narrative within engineering education research to explore poststructuralism as one possible perspective on faculty-as-learners. Poststructuralism is a paradigm that constantly seeks a “making-strange” and unsettling of habitual narratives. A poststructural view challenges us to remain in the discomfort of liminal (in-between) spaces where everything is constantly troubled and nothing ever really settles. This study demonstrates a concrete method for engaging faculty members in that liminal space. Through it, I anticipate contributing to our ability to articulate and value faculty explorations in chaotic territories such as large-scale curriculum redesigns, new program formation, and other places where valuable growth occurs but is rarely put into words.
How can we think of faculty as learners?
I will briefly describe several qualities of faculty-as-learners, compare and contrast them to the qualities presented in existing literature, and explore why it may be valuable to make these qualities visible. Note that by comparing and contrasting my approach to other studies, I am not making statements about the relative quality or validity of their work. I am also not saying that these ways of viewing faculty-as-learners are not present in any existing literature. I am simply using differences and similarities to more clearly articulate certain assumptions about faculty-as-learners that are present in this project.
They are situated in the community of practice of teaching their discipline.
The first quality of faculty-as-learners is that they are situated in a community of practice (Wenger, 1999), that of teaching their discipline. By making sense of the activities of other practitioners around them, they develop the skill of reflection-in-action (Scho¨n, 1983) and use this metacognition and self-monitoring to improve their own practice. Existing engineering education change initiatives have used this cognitive apprenticeship (Collins, Brown, & Newman, 1987; Collins, Brown, & Holum, 1991) approach to build Faculty Learning Communities (Cox, 2004) and other communities of practice to encourage rigorous research in engineering education (Streveler, Smith, & Miller, 2005). Understanding faculty as situated and communal learners helps explain the limited success of an “information dissemination” approach (Siddiqui and Adams, 2013) to research-to-practice transfer. If faculty change their teaching practice primarily in response to direct interactions with colleagues (Fincher, Richards, Finlay, Sharp, & Falconer, 2012) and not print materials, it’s no surprise that journal papers continue to go unread (Borrego, Froyd, & Hall, 2010).
They are adult learners.
The second quality of faculty-as-learners is that they are adult learners. They have rich histories of experience to draw upon as well as expectations of agency (Vella, 1997). This quality allows us to portray faculty as narrators, highly capable and interdependent agents who both read and co-author the stories of “how things are done” within their culture. The Disciplinary Commons initiative (Tenenberg & Fincher, 2007), which scaffolds faculty through a dialogic process of creating teaching portfolios for their existing courses, is an exemplar of validating faculty as adult learners. Initiatives that treat faculty as mere empty “buckets” to be filled with “information about teaching,” such as information sessions dedicated to lecturing faculty about why they should not lecture, may have a limited impact because of this epistemological disjoint.
They learn by engaging in liminal experiences.
The third quality of faculty-as-learners is that they often learn by engaging in liminal experiences where their activities do not fall into a cleanly articulable structure, and can therefore be described as poststructural. In fact, the liminal experiences of faculty are often explicitly about dismantling old structures and remaking new ones, such as the founding of a new college (S. Kerns, Miller, & D. Kerns, 2005) or degree program (Katehi et. al., 2004), dramatic overhauls of an existing curriculum (Mentkowski, 2000), or the creation of experimental classes.
The trouble with liminal experiences is that they stand outside the realm of structure, including the structure of validation and reward. Our existing academic system rewards faculty for engaging in liminal spaces for their research, so long as they are able to publish papers about it afterwards. However, the examples listed all impact teaching, a form of scholarship that is underdeveloped and unrecognized (Shulman, 1998), with a correspondingly slow speed of change. Mann’s (1918) calls for engineering educators to improve student retention, make undergraduate workloads reasonable, and increase hands-on training still sound as relevant today as when he wrote his report nearly a century ago. Our calls for transforming engineering education (National Academy of Engineering, 2005; Institute of Medicine, National Academy of Sciences, & National Academy of Engineering, 2007; McKenna, 2011) will similarly go unheeded unless we find ways to understand and articulate the ways faculty learn and work in these liminal spaces.
By having engineering and technology faculty work with their stories of liminal experiences, this study addresses the following research question: How can the interacting narratives of engineering and technology faculty inform our understanding of faculty as learners?
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, 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), 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).
This is the first in a series of blog posts based on my Hacker School workshop series, “Learning Styles For Programmers,” which is in turn a software-focused adaptation of Rich Felder’s work on engineering learning styles. (As you read, 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!
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 recently asked for advice on how I’d teach programming using Python to fellow academics. Specifically, 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.