Andromeda Yelton

Across Divided Networks

LibraryCloud hackathon report: or, code as intersectional feminist critique

December 5th, 2014 · Uncategorized

Monday I was at a hackathon for the Harvard LibraryCloud API. So this was great, not only because it’s good for us work-from-home types to leave the house and talk to humans instead of just our cats, but also because I got there and there were a whole lot of other women in the room! This hackathon shared at least one organizer with the prior one where I was the only woman at the table, so I really appreciate that he took my vehement criticism in the best possible way and conducted obvious outreach.

Then he asked who was there for the tutorial, not the hackathon, and literally every other woman in the room raised her hand. *sigh* 1

What recourse does one have, really, but code as feminist critique? Hence: Intersectional LibraryCloud.

What you’re seeing on that web page are the most commonly used Harvard Library resources that match a given subject search. (The page is randomly seeded when you load with a popular topic, but do try your own!) The results are sorted by stackscore and highlighted with whether their subjects include terms commonly associated with women’s studies; African-American studies; or LGBT studies. (Thank you to Harvard librarian Vernica Downey for the cataloging help.)

With this page, I want to examine the question: when Harvard students and faculty develop their understandings of various topics, are those understandings informed by intersectional perspectives? (Answers are left as an exercise for the reader.)

This was the work of a day (…plus way too long shaving yaks to get it onto Heroku), so there are some issues with the code I’d love to see fixed. For one thing, I don’t handle substrings, so some subjects that should definitely be coded as matches, aren’t. For another, in my initial plan I wanted to look at disability studies too, but my first-pass layout doesn’t accommodate it and I don’t have a suitable set of subjects. This is an exercise for the reader too, though! Because I’ve got code, and you can hack on it: woo yeah intersectional librarycloud repo.

This is the sort of code that invites human-language commentary as well; would love to hear your thoughts.


  1. Subsequently a few more women showed up, so I ended up being one of 2 or 3. Yay? Also not exactly escaping my attention that all but about two people in the room were white, so if I were a woman of color looking to not feel isolated, game over.

→ 14 CommentsTags:

ebooks choices and the missing soul of librarianship

October 8th, 2014 · Uncategorized

We protect each library user’s right to privacy and confidentiality with respect to information sought or received and resources consulted, borrowed, acquired or transmitted.
American Library Association Code of Ethics

Yesterday I watched as Adobe Digital Editions told Adobe what book I was reading — title, author, publisher, year of publication, subject, description — and every page I’d read, and the time at which I read them. Adobe’s EULA states that it also collects my user ID and my general location.

I was able to watch this information be collected because it was all sent unencrypted, readable to any English-speaking human with access to any of the servers it passes through, in whatsoever jurisdiction, and also (if your wifi is unencrypted) the open air between my laptop and my router.

The Council of the American Library Association strongly recommends that… [circulation and other personally identifying] records shall not be made available to any agency of state, federal, or local government except pursuant to such process, order or subpoena as may be authorized under the authority of, and pursuant to, federal, state, or local law relating to civil, criminal, or administrative discovery procedures or legislative investigative power [and that librarians] resist the issuance of enforcement of any such process, order, or subpoena until such time as a proper showing of good cause has been made in a court of competent jurisdiction.”
Policy on confidentiality of library records

Your patrons’ reading information is already part of a warrantless dragnet. Because it has been transmitted in cleartext, the government needs no further assistance from you, your patrons, or your vendors to read it. Even were they to present you with a valid subpoena, you would be powerless to resist it, because you have, in effect, already written the information on your walls; you have no technical ability to protect it.

The American Library Association urges all libraries to…

  • Limit the degree to which personally identifiable information is collected, monitored, disclosed, and distributed; and avoid creating unnecessary records; and
  • Limit access to personally identifiable information to staff performing authorized functions; and…
  • Ensure that the library work with its organization’s information technology unit to ensure that library usage records processed or held by the IT unit are treated in accordance with library records policies; and
  • Ensure that those records that must be retained are secure; and
  • Avoid library practices and procedures that place personally identifiable information on public view.”

Resolution on the Retention of Library Usage Records

If Adobe Digital Editions is part of your technical stack — if your library offers Overdrive or 3M Cloud Library or EBL or ebrary or Baker & Taylor Axis 360 or EBSCO or MyiLibrary or quite possibly other vendors I haven’t googled yet — you are not doing this. You cannot do this.

…ebook models make us choose. And I don’t mean choosing which catalog, or interface, or set of contract terms we want — though we do make those choices, and they matter. I mean that we choose which values to advance, and which to sacrifice. We’re making those values choices every time we sign a contract, whether we talk about it or not.
me, Library Journal, 2012

In 2012 I wrote and spoke about how the technical affordances, and legal restrictions, of ebooks make us choose among fundamental library values in a way that paper books have not. About how we were making those choices about values whether we made them explicitly or not. About how we default to choosing access over privacy.

We have chosen access over privacy, and privacy is not an option left for us to choose.

Because: don’t underestimate this. This is not merely a question of a technical slip-up in one version of an Adobe product.

This is about the fact that we do not have the technical skills to verify whether our products are in line with the values we espouse, the policies we hold, or even the contracts we sign, and we do not delegate this verification to others who do. Our failure to verify affects all the software we run.

This is about the fact that best practice in software is generally to log promiscuously; you’re trained, as a developer, to keep all the information, just in case it comes in handy. It takes a conscious choice (or a slipshod incompetence) not to do so. Libraries must demand that our vendors make that choice, or else we are in the awkward position of trusting to their incompetence. This affects all the software we run.

This is about the fact that encryption products are often hard to use, the fact that secure https is not yet the default everywhere, the fact that anyone can easily see traffic on the unencrypted wireless networks found at so many libraries, the fact that anyone with the password (which, if you’re a library, is everyone) can see all the traffic on encrypted networks too. This affects all the software we run.

This is about Adobe. It is not just about Adobe. These are questions we should ask of everything. These are audits we should be performing on everything. This affects all the software we run.

I am usually a middle-ground person. I see multiple sides to every argument, I entertain arguments that have shades of the abhorrent to find their shades of truth. This is not an issue where I can do that.

If you have chosen, whether actively or by default, to trust that the technical affordances of your software match both your contracts and your values, you have chosen to let privacy burn. If you’re content with that choice, have the decency to stand up and say it: to say that playing nice with your vendors matters more to you than this part or professional ethics, that protecting patron privacy is not on your list of priorities.

If you’re not content with that choice, it is time to set something else on fire.

→ 11 CommentsTags:

how the next meeting went

October 3rd, 2014 · Uncategorized

In June, I said that I wouldn’t be voting to approve the LITA budget, due to a variety of unaddressed concerns. At Annual, Cindi Blyberg ran an awesome meeting where we put off the vote, to give our Financial Advisory Committee time to update things before the fiscal year close. And then I forgot to update the blog about the subsequent meeting!

Well, the FAC did outstanding work, pulling together a budget that I solidly believe in, on very little notice. (I owe you all beers. A lot of beers. Zoe Stewart-Marshall, Andrew Pace, Susan Sharpless Smith: please be thinking what kind of beverages you like.) We approved it in August with very little fuss. I was pleased to vote for it.

You can have a look yourself if you like: FY2015 budget [.xlsx].

You’ll notice the bottom line here is a deficit. I’m bummed about that, because I’m concerned about LITA’s health, but mostly I’m happy about it, because it’s honest. I think the lines above it are credible estimates of what we’ll end up doing in FY ’15, and I would a million times rather be honest about the challenges of that, so we can plan for them, than sweep them under the rug.

And now the FAC is off and running on the FY ’16 budget, with a timeline that should allow for much more deliberation at leisure than FY ’15 allowed. (Note to self: you owe them even more beers.) And Board is pondering how to fill the holes. Your ideas, as always, are welcome.

Comments OffTags:···

what I’m looking for in Emerging Leader candidates

September 26th, 2014 · Uncategorized

One of my happier duties as a LITA Board member is reviewing Emerging Leader applications to decide whom the division should sponsor. I just finished this year’s round of review this morning, and now that my choices are safely submitted (but fresh on my mind) I can share what I’m looking for, in hopes that it’s useful to future Emerging Leader candidates as you develop your applications.

But first, a caveat: last year and this, I would have been happy with LITA sponsoring at least half of the candidates I saw, if only we could. Really the only unpleasant part of reviewing applications is that we can’t sponsor everyone we’d like to; I see so many extraordinarily talented, driven people in the application pile, and it’s actually painful not to be able to put all of them at the top of my list.

Okay! That said…

Things I want to see

  • People who have gotten things done.
  • People who haven’t just done an excellent job with duties as assigned, but who have perceived a need and initiated something to solve it.
  • People who have marshaled resources and buy-in, even though they are (as is the case for most EL candidates) in a junior position, or outside a formal hierarchy.
  • Letters of recommendation that speak to the things you can’t credibly address about yourself (communication, leadership skills), using specific examples.
  • Since these are specifically LITA Emerging Leader candidates, I want to see some kind of facility with technology. I’m very open-minded about what this is, but it must go beyond standard office-worker technology proficiency. I want to see that you can use technologies to create things, or that you can create technology. Tell me about that time you set up an institutional repository, or crafted a social media strategy, or did a pile of digitization, or used your video editing skills to launch your library’s marketing campaign, or automated some kind of metadata workflow, or taught yourself Javascript — seriously, I don’t care what technologies you’re using or whether you’re using them in a technology-librarian context, but you have to have some sort of technological proficiency and creativity.

Diversity is a specific (and large) part of the rubric I’m asked to use, and I’m going to give it extended treatment here. First, not gonna lie: most people in the pool are white women, and you have an uphill battle to prove your understanding of diversity if you’re one of them. (I am also a white woman, and the same goes for me.) Second, I’m not looking for evidence that you care about diversity or think it’s a good thing (of course you do. what are you, some kind of a jerk? no). I’m looking for concrete evidence that you actually get it. Tell me that you wrote a thesis on some topic that required you to grapple with primary sources and major thinkers on some diversity-related topic. Tell me about the numerous conference presentations you’ve done that required this kind of thinking. Tell me about the work, whether paid or volunteer, that you’ve done with diverse populations. Tell me about how you’ve gone out of your way, and maybe out of your comfort zone, to actually do something that deepens your awareness, develops your skills, and diversifies your network.

If you belong to a population that gives you special insight about some axis of diversity (and many white women do!), tell me about that, too. I don’t give full credit for that – I’d still like to see that you’ve theorized or worked on some sort of diversity issue – but it does give me faith that you have some sort of relevant insight and experience.

There are many kinds of diversity that have shown up in EL apps and there’s no one that matters most to me, nor do I expect any candidate to have experience with all of them. But you need to have done something. And if you really haven’t, at least acknowledge and problematize that fact; if you do this and the rest of your application is exemplary you may still be in the running for me.

Things I do not want to see

I had 20 applications to review this year. I am reviewing them as a volunteer, amidst the multiple proposals I am writing this month and the manuscript due in November and the course and webinar I’ll be teaching soon and my regular duties on two boards and helping lead a major fundraising campaign and writing code for a couple of clients and the usual housework and childcare things and occasionally even having a life and, this week, some pretty killer insomnia. Seriously, if you give me any excuse to stop reading your application, I will take it.

Do not give me the excuse to stop reading.

Some things that will make me stop reading:

  • If your application is in any way incomplete (didn’t answer all the questions, missing one or more references, no resume).
  • Significant or frequent errors of grammar, spelling, or usage.
  • Shallow treatment of the diversity question (see above).

I also might stop reading overly academic prose, particularly if it reads like you’re not 100% comfortable with that (admittedly pretty weird) genre. I do want to see that you’re smart and have a good command of English, but communication within associations is a different genre than journal articles. Talk to me in your voice (but get someone to proofread). Particularly if you’re a current student or a recent graduate: I give you permission to not write an academic paper. (I implore you not to write an academic paper.) My favorite EL applications sparkle with personality. They speak with humility or confidence or questioning or insight or elegance. A few even make me laugh.

I would prefer it if you spell out acronyms, at least on their first occurrence. You can assume that I recognize ALA and its divisions, but there are a lot of acronyms in the library world, and they’re not all clear outside their context. If you’re active in CLA, is that California or Colorado or Connecticut? Or Canada?

Some information about mechanics

Pulling back the curtain for a moment here: the web site where I access your application materials does not have super-awesome design or usability, and this impacts (sometimes unfairly) how I rate your answers.

Your answers to the questions are displayed in all bold letters. This makes it hard to read long paragraphs. Please use paragraph breaks thoughtfully.

Your recommenders’ text appears to be displayed without any paragraph breaks at all, if they’ve typed it directly into the site. Ow. Please ask them to upload letters as files instead.

Speaking of which: I use Pages. On a Mac. Your .docx file will probably look wrong to me. If you’ve invested time and graphic design skills in lovingly crafting a resume, I want to see! Please upload your resume as .pdf, and ask your recommenders to upload their letters as .pdf too. (On reflection I feel bad about this because it’s a famously poor format for accessibility. But seriously, your .docx looks bad.)

Whew! Glad I got to say all that :) Hope this helps future EL candidates. I look forward to reading your applications next year!

→ 4 CommentsTags:

jQuery workshop teaching techniques, part 3: ruthless backward design

September 18th, 2014 · Uncategorized

I’m writing up what I learned from teaching a jQuery workshop this past month. I’ve already posted on my theoretical basis, pacing, and supporting affective goals. Now for the technique I invested the most time in and got the most mileage out of…

Ruthless backward design

Yes, yes, we all know we are supposed to do backward design, and I always have a general sense of it in my head when I design courses. In practice it’s hard, because you can’t always carve out the time to write an entire course in advance of teaching it, but for a two-day bootcamp I’m doing that anyway

Yeah. Super ruthless. I wrote the last lesson, on functions, first. Along the way I took notes of every concept and every function that I relied on in constructing my examples. Then I wrote the second-to-last lesson, using what I could from that list (while keeping the pacing consistent), and taking notes on anything else I needed to have already introduced – again, right down to the granularity of individual jQuery functions. Et cetera. My goal was that, by the time they got to writing their own functions (with the significant leap in conceptual difficulty that entails), they would have already seen every line of code that they’d need to do the core exercises, so they could work on the syntax and concepts specific to functions in isolation from all the other syntax and concepts of the course. (Similarly, I wanted them to be able to write loops in isolation from the material in lessons 1 and 2, and if/then statements in isolation from the material in lesson 1.)

This made it a lot easier for me to see both where the big conceptual leaps were and what I didn’t need. I ended up axing .css() in favor of .addClass(), .removeClass(), and .hasClass() – more functions, but all conceptually simpler ones, and more in line with how I’ve written real-world code anyway. It meant that I axed booleans – which in writing out notes on course coverage I’d assumed I’d cover (such a basic data type, and so approachable for librarians!) – when I discovered I did not need their conceptual apparatus to make the subsequent code make sense. It made it clear that .indexOf() is a pain, and students would need to be familiar with its weirdness so it didn’t present any hurdles when they had to incorporate it into bigger programs.

Funny thing: being this ruthless and this granular meant I actually did get to the point where I could have done real-world-ish exercises with one more session. I ended up providing a few as further practice options for students who chose jQuery practice rather than the other unconference options for Tuesday afternoon. By eliminating absolutely everything unnecessary, right down to individual lines of code, I covered enough ground to get there. Huh!

So yeah. If I had a two-day workshop, I’d set out with that goal. A substantial fraction of the students would feel very shaky by then – it’s still a ton of material to assimilate, and about a third of my survey respondents’ brains were full by the time we got to functions – but including a real-world application would be a huge motivational payoff regardless. And group work plus an army of TAs would let most students get some mileage out of it. Add an option for people to review earlier material in the last half-day, and everyone’s making meaningful progress. Woot!

Also, big thanks to Sumana Harihareswara for giving me detailed feedback on a draft of the lesson, and helping me see the things I didn’t have the perspective to see about sequencing, clarity, etc. You should all be lucky enough to have a proofreader so enthusiastic and detail-oriented.

Later, where I want to go next.

Comments OffTags:

counting keynoter diversity in libraryland

September 17th, 2014 · Uncategorized

Recently I mentioned to someone that the library speaker circuit is male-dominated, and she was surprised to hear it. It’s certainly a thing that feels overwhelming from the inside — I’ve been part of a 40% female speaker lineup in front of a 90% female audience — but maybe it’s not as much of a thing as I think?

Well. I counted speaker diversity at LITA Forum once; I can count keynote speakers at big library conferences too.

The takeaway: not as bad as I thought gender-wise but still pretty bad for a field that’s 80% female — except, oddly, library technology does better than the average. On the other hand, if you’re looking for non-white keynoters…it’s pretty bad.

In national-scale US/Canadian library conferences…

  • 43% of speakers are female.
  • 74% of speakers are white, 14% black, 7% Asian, 4% Hispanic.

In national-scale US/Canadian library technology conferences…

  • 57% of speakers are female.
  • 71% of speakers are white, 0% black, 21% Asian, 7% Hispanic.(Ouch. I did not want to type that zero.)

A nice surprise

I honestly didn’t expect library tech to do better than the average, gender-wise. This is partly a function of tiny little sample size – only 14 keynoters. But it’s also a reminder that a few people can have a lot of leverage. A big part of what you’re seeing here is that code4lib decided to care: code4lib members went out of their way to nominate female keynoters, and keynoters who can speak to feminist issues, and in the open vote that ensued, the two winners were female. LibTechConf organizers went out of their way to solicit diverse speakers, too. And either of them alone tips the scale to majority female keynoters in libtech.

Thanks, code4lib and LibTechConf. You’re awesome.

Sumana Harihareswara

Sumana gave a killer talk at Code4Lib 2014. This made her one-third of all keynoters of Asian heritage in libraryland last year, and the only Indian-American. Yikes.


I was looking specifically at keynote speakers — the ones who get invited, paid, and put on a stage in front of the full audience. The ones we showcase as representatives of our values and interests; the ones we value most, metaphorically and literally. The ones we ask.

Not everyone uses the term “keynote”; I also counted “opening/closing general session”, “plenary”, and (in the case of ALA Midwinter, which lacks all of those things) “auditorium speaker series”.

I looked at the most recent iteration of the following conferences:

AALL, AASL, Access, ACRL, ALA Annual, ALA Midwinter, ALSC national institute, ASIS&T, code4lib, DLF, LibTechConf, LITA Forum, MLA, OLA Super Conference, OLITA Digital Odyssey, PLA, and SLA. (YALSA’s Symposium doesn’t seem to have keynoters.)

That’s pretty much what I thought of off the top of my head, biased toward libtech since that’s where I have the most awareness. Happy to add more and update accordingly!

Reminder: why I do this

This is what I ask: when you walk into a room, count. Count the women. Count the people of color. Count by race. Look for who isn’t there. Look for class signs: the crooked teeth of childhoods without braces, worn-out shoes, someone else who is counting. Look for the queers, the older people, the overweight. Note them, see them, see yourself looking, see yourself reacting.

This is how we begin.

– Quinn Norton, Count

→ 2 CommentsTags:

jQuery workshop teaching techniques, part 2: techniques geared at affective goals

September 17th, 2014 · Uncategorized

I’m writing up what I learned from teaching a jQuery workshop this past month. I’ve already posted on my theoretical basis and pacing. Today, stuff I did to create a positive classroom climate and encourage people to leave the workshop motivated to learn more. (This is actually an area of relative weakness for me, teaching-wise, so I really welcome anyone’s suggestions on how to cultivate related skills!)

Post-it notes

I distributed a bunch of them and had students put them on their laptops when they needed help. This lets them summon TAs without breaking their own work process. I also had them write something that was working and something that wasn’t on post-its at the end of Day 1, so I could make a few course corrections for Day 2 (and make it clear to the students that I care about their feedback and their experience). I shamelessly stole both tactics from Software Carpentry.

Inclusion and emotion

The event was conducted under the DLF Code of Conduct, which I linked to at the start of the course material. I also provided Ada Initiative material as background. I talked specifically, at the outset, about how learning to code can be emotionally tough; it pushes the limits of our frustration tolerance and often (i.e. if we’re not young, white men) our identity – “am I the kind of person who programs? do people who program look like me?” And I said how all that stuff is okay. Were I to do it over again, I’d make sure to specifically name impostor syndrome and stereotype threat, but I’ve gotten mostly good feedback about the emotional and social climate of the course (whose students represented various types of diversity more than I often see in a programming course, if less than I’d like to see), and it felt like most people were generally involved.

Oh, and I subtly referenced various types of diversity in the book titles I used in programming examples, basically as a dog-whistle that I’ve heard of this stuff and it matters to me. (Julia Serano’s Whipping Girl, which I was reading at the time and which interrogated lots of stuff in my head in awesome ways, showed up in a bunch of examples, and a student struck up a conversation with me during a break about how awesome it is. Yay!)

As someone who’s privileged along just about every axis you can be, I’m clueless about a lot of this stuff, but I’m constantly trying to suck less at it, and it was important to me to make that both implicit and explicit in the course.

Tomorrow, how ruthless and granular backward design is super great.

Comments OffTags:

jQuery workshop teaching techniques, part 1: pacing

September 16th, 2014 · Uncategorized

I’m writing up what I learned from teaching a jQuery workshop this past month. I’ve already posted on my theoretical basis. Now for the teaching techniques I used, drawing on my past teaching experience, to get mileage out of that inspiration. Today: pacing!

Pacing (macro-scale)

I covered the same material, conceptually, that I’ve taught before as a one-day Python workshop (itself borrowed from the day-and-a-bit Boston Python Workshop, but I broke it into 90-ish minute segments, with breaks in between (some of them long), over a day and a half. I think the down time is critical; people’s brains get full and they can’t absorb new material. Crucially, this also let me put functions on day two. They’re the hardest new concept, and they build on everything that’s gone before, and my intuition told me that giving people a chance to sleep on things would help. Informal student feedback suggests I was right.

Pacing (micro-scale)

Boston Python Workshop does a long self-paced intro that covers all the concepts, then a long interactive lecture that reiterates and formalizes them, then a long practice session. This is great for accommodating students at a variety of levels (and people do come to these with tremendously varying background), but wrong otherwise. The two-hour lecture is too much infodump, and students don’t really know if they’ve understood it until they get to the practice phase.

Worse, in my experience most people are poor judges of whether they understand new material; “I’ve seen this before” feels enough like “I understand it” that people don’t realize how serious the gaps in their mental models may be until they actually have to do independent work. If the practice session isn’t until after all the material has been introduced, most students will have spent most of the lecture building later concepts on top of flawed understandings of earlier concepts, so by the time they get a chance to correct things they’ll have an awful lot to correct (and the difficulty in doing so is more-than-linear with the accumulation of new material).

I wanted to expose problems with mental models quickly so students could self-correct before having gone too far astray, so I did much shorter mini-lectures interspersed with hands-on practice. (This dovetails, of course, with the paper on test harnesses from yesterday.) The army of TAs was great here, meaning that people who needed help usually got it immediately (and many students pointed this out specifically as a helpful feature of the course – thank you again to all the TAs!).

Comments OffTags:

What I learned teaching jQuery (part 1)

September 15th, 2014 · Uncategorized

On August 11-12, I taught an Introduction to Programming Concepts via jQuery course at the DLF/Code4Lib unconference at the George Washington University. I was playing with several theories in developing this course:

  • Porting to jQuery so that it could be 100% browser-based: familiar environment, no installfest, maximizes time available for actual programming concepts.
  • Porting to jQuery so that it could be 100% visual (on which more below).
  • Simply giving up on the idea of getting true novices to the point of being able to write real-world-applicable code in a day-and-a-half workshop, and focusing instead on building a foundation that makes existing code-learning resources more intelligible, and leaves students with enough good feelings about code that they’ll be inclined to learn more.

Bottom line: I think it worked really well!

Today I’m going to talk about my theoretical inspiration for the course; upcoming posts will cover teaching techniques I used to operationalize that, and then future plans. (Look, there’s a jquery workshop tag so you can find them all!)

yo dawg i heard you like tests…

The whole workshop was, in a sense, a way to play with this paper: “A fresh look at novice programmers’ performance and their teachers’ expectations”. Its jaw-dropping result was that providing novice programming students with a test apparatus for a programming task quadrupled the number of subtasks they could successfully complete (students without the tests completed an average of 0.83 out of 4 tasks, compared to 3.26 for students who could check their work against the tests — in other words, students without tests didn’t even get one subtask working, on average).

Well gosh. If tests are that effective, I’m obligated to provide them. This is consistent with my intuitive observations of the CodingBat section of Boston Python Workshop — being asked to write provably correct code is the point where students discover whether their existing mental models are right, and start to iterate them. But the CodingBat interface is confusing, and you need to sink some instructional time just into making sense of it. And, honestly, with a lot of conventional intro programming tasks, it’s hard to tell if you’ve succeeded; you’ve got a command-line-ish interface (unfamiliar to many of my students) and a conceptual problem with abstract success criteria. I wanted something that would give immediate, obvious feedback.

Hence, jQuery. Manipulating the DOM produces instant visual effects. If you were asked to make a button disappear, it’s super obvious if you succeeded. (Well. Possibly assuming sightedness, and (with some of my tasks) possibly also non-colorblindness — I stayed away from red/green semantic pairs, but I didn’t audit for all the forms of colorblindness. I need to mull this one over.) And as it turns out, when you ask your students to add a class that changes a bunch of things to have a kitten pic background, it’s also super obvious to you as the instructor when they’ve succeeded (wait for it…wait…“awwww!”).

My hope for this class was that it would provide students who were genuinely novices at coding with the conceptual background they needed to get mileage out of the many intro-programming learning options out there. As Abigail Goben notes, these courses tend to implicitly assume that you already know how to code and just need to be told how to do it in this language, even when they brand themselves as intro courses. People will need much more practice than a day-and-a-half bootcamp to get from novice to proficient enough to write things they can use in everyday work, so I want to get them to a place where that practice will feel manageable. And for the students who do have some experience, hopefully I can introduce them to a language they don’t know yet in a way that has enough meat not to bore them.

Tomorrow, teaching techniques I used to get there, part 1: pacing.

→ 2 CommentsTags:

Why I support the Ada Initiative. (You, too?)

September 10th, 2014 · Uncategorized

I need to talk to you about emotion

I need to talk to you about emotion. From a brilliant Code4Lib lightning talk by Mark Matienzo.

I got involved with codes of conduct by accident. People were saying on Twitter that ALA should have one, and I didn’t want it to be one of those good ideas full of tweety energy that go nowhere, and called their bluff and set up a google doc, and everyone else realized this made me a leader before I did.

One of the things that happens when people see you as a leader on this topic is you start to be a keeper of stories. People come to you, out of nowhere, and tell you about that time when someone was creepy. Or someone was drunk. Or someone didn’t keep their hands, or lips, to themselves. Or someone made them feel violated, blindsided, and maybe they smiled and kept the peace because that’s what women are taught to do, and maybe they didn’t understand until later what they should have said, how they should have said it. And maybe no one watching even understood how serious the problem was. Because we’re all taught, all of us, that women are not the protagonists of the story — we’re the love interest, the sassy sidekick, the prop there to raise someone else’s stakes. It’s easy not to see how hurt someone has been if you think the story is about someone else.

Stories change when you identify with a new protagonist. To me, a subtext of discussions about codes of conduct, and so many other issues that arise in social justice discourse communities, is this: we make new statements about who is the protagonist. Whose stakes matter. Whose perspective observers should take. With whom to empathize. We claim our own positions as protagonists in our stories, and demand that others do as well.

I find my work on the Ada Initiative advisory board compelling in large part because there are so many stories, so many emotions — people who have been treated in ways no one should be treated, people who have to waste energy on issues many of their colleagues don’t before they even get to the work they all share, people walking around with these raw and gaping and secret wounds. I want us all to be protagonists. I want us all to be able to spend our energy on love and intellect and creativity, not on responding to harassment, or to the threat of harassment, or even the implicit fear of it.

So that’s why I support the work of the Ada Initiative: because codes of conduct legitimize marginalized people’s own understandings of their (our) own experiences, and give them (us) concrete ways to push back when their (our) lines are crossed. Because AdaCamps give us environments where we don’t have to be the only woman in the room, and therefore space to be all the other things we are, too. Because Ally Skills workshops give men a framework for seeing the ways women’s lives can be entirely, invisibly, surprisingly different, right in front of them, and strategies for enacting their values.

And that’s why, along with Bess Sadler, Chris Bourg, and Mark Matienzo, am providing a $5120 matching grant for donations from libraryland toward the Ada Initiative’s yearly fund drive. From today through the 15th, we’ll match every dollar pledged through the Ada Initiative’s library-specific campaign page, up to $5120.

If you’re happy that your favorite library association (e.g. ALA, DLF, Code4Lib, SAA, Access, In the Library with the Lead Pipe, Evergreen, Open Repositories, and OLA) has adopted a Code of Conduct, the Ada Initiative deserves part of the credit. If you liked Valerie Aurora’s keynote at Code4Lib 2014, or you’re looking forward to her Ally Skills Workshop at DLF Forum, or you think it’s cool that several library technologists have been to AdaCamp, please consider donating to the Ada Initiative, so that it can keep doing all those things (and hey, maybe more!).

Or if you just like feminist stickers. We can set you up with those, too.

Thank you.

Comments OffTags: