Post-conference happiness from FIE


We learn things at conferences! Here are some notes from the last one I attended (FIE, or Frontiers in Education, an engineering edu conference I attend most years).

I learned (via Margot Vigeant) that I’m not the only comic-drawing engineering education researcher. She’s doing visual work in the discipline, as is Lucas Landherr (who, like Margot, is a chemical engineer).

Also via Margot was a heads-up about Project Hieroglyph, an initiative at ASU that paired sci-fi writers with researchers to “provide not just an idea for some specific technical innovation, but also to supply a coherent picture of that innovation being integrated into a society, into an economy, and into people’s lives.” I couldn’t think of a better framing example for what I’m trying to do with my “alternate universe engineering/tech/computing education cultures” work, which is still in those lovely early stages of “I have no idea what I’m doing with this.” Stories. Stories are so important.

I got the opportunity to catch up with several friends, including James Huff (whose work on shame in engineering edu with Nikki Sochacka and Jo Walther is something I am so looking forward to) and Ana Rynearson (who is starting a new program at Campbell), and Allison Godwin (who has very good NSF CAREER award advice). And Rebecca Christianson and Siddharthan Govindasamy, who are wrapping up the 3rd year of the QEA experiment and have stories to tell, and and and and…

And meet new ones! It was a tremendous pleasure to meet Adam Masters, who is looking at makerspaces designed specifically for marginalized groups, and who I really want to collaborate with on the “alternate universe curricular cultures” thing at some point down the line. And Julianna Ge, who is pursuing the fascinating notion of “engineering thriving” (thesis: if you’re successful in engineering academics and are thoroughly miserable, we’re not doing a great job with engineering education for you yet). Which reminds me that I should introduce the two of them.

Oh, and I got to spend more time with the incomparable Tess Edmonds, which is always a great joy. She also was the third performer in the special session that Ian Smith, Samir Jain, and I did on an alternate-universe engineering culture where engineering is dominated by Deaf people, and hearing(ness) is seen as a disability… more on that later, I hope. But right now, conference happiness. And a lot of catching-up on email.


Wingsuits and giant eagles


I have an analogy for (ASL) interpreting from a Deaf user’s perspective that involves parachutes and squirrel suits and such. Ian Smith asked for it to be publicly available, so… here is a hastily written post. Perhaps someday it will be edited into something more eloquent; today is not that day.

Ok. So you know wingsuits (sometimes called squirrel suits after the flying squirrels they resemble), the skydiving suits with wings that let you kinda glide around? (If you don’t, here’s a video of one.)

That’s lipreading. It looks like flying, but really it’s more like… “falling, with style,” to quote Toy Story. To the untrained eye, squirrel suiting can masquerade as flying, but you can’t actually continue doing it. You have to bail out of it and activate your parachute at some point before you smash your head open on a rock.

Interpreters are like the giant flying eagles from the end of the Lord of the Rings. (And yes, that’s what it looks like on the inside after lipreading, sometimes. Not all the time, but… sometimes.)

Giant eagles can swoop in and pick you up — and when they do, you are obviously definitely not flying on your own. It’s all a bit, uh… bulky and noticeable, but also, you’re… not smashing your head open on a rock. And you can keep flying for a lot longer.

I haven’t really thought through the parallel analogy for captioning, but perhaps it’s like steering your fall over one of those giant fans like they have for indoor skydiving places. It shoots you upwards, it can work for “flyers” (hearing people) as well, but the captioning isn’t portable – it only shoots air upwards from that one spot.

Anyway. I explain this to my interpreters at conferences and such (it’s really fun to explain using ASL classifiers), and will also tell them that sometimes I will jump off their backs (so to speak) and squirrel-suit for a bit. It’s not a reflection on their skill (they can be the best interpreter in the world, and I’ll still do it!) or my need for the access they provide — it’s because that’s how I use all my tools/options with fluency.

I can get to some places with my squirrel suit that they can’t quite reach as giant eagles. When it’s working, it works beautifully — I’ll jump on and off really fast, and the choreography of a good interpreter/Mel team can be gorgeous when it works out.

Just for fun:

The Star Wars Ep II scene of Anakin jumping out of the shuttle is actually a fairly accurate portrayal of extroverted puppymel asking questions of a… somewhat less extroverted person, with the requisite ADHD losing-of-things.

And a conversation that happened amongst Deaf friends when I was explaining the analogy:

Samir: Why couldn’t my terps have swooped in to pick me up to take me to Mordor in the first place?
Mel: One does not simply walk into Mordor.
Mel: One requests reasonable accommodations, then works one’s way through an increasingly bureaucratic chain, then says “sod it” and walks into Mordor, because it’s easier that way sometimes.


How do I make my conference more accessible/inclusive?


I was recently asked how to make conference presentations more accessible to Deaf/hard-of-hearing attendees. Now, I have written a guide on that, but I’d like to broaden the question to include other forms of conference access. There are a number of good guides out there, so I’m not going to rehash them; instead, I will link to some of them.

Two more notes here – first, at least for my field (engineering education), I think the real question will be not so much how willing a conference is to enforce some of these things (either through requirements, design, or likely some combination or the two) as opposed to simply suggesting them as nice things for attendees to do. Quite frankly, if people don’t have to do these things… many don’t. A lot of them require advance planning and other aspects that are not part of academic conference presentation culture by default (finishing your slides before the day you present them? what?!!?)

Second, although the guides above focus mostly on disability-related access, remember that there are other forms of access and inclusivity that are important, too. Is your event affordably priced and/or does it have scholarships available? Is it at a location that is easy to travel to, stay at (are there wheelchair-accessible lodging options that aren’t super expensive?), eat at (will those with food allergies and vegans/vegetarians be able to find options)? Is it at an hour where people with day jobs and/or small children can attend? Is there childcare? A quiet room? Gender-neutral restrooms and buttons/stickers with different pronoun options? A code of conduct and the means to enforce it? Are you deliberately soliciting participation from a wide variety of people? There are a lot of ways to make events inclusive!

I’d also like to note: conference access is not my specialty, nor is it my area of expertise. I love conference planning, but I’d rather be on the program committee, etc. than the “diversity and access” board. In order to do this, other people need to do the diversity and access work, because I literally cannot participate in the conference without it. Until I’m able to completely trust it’ll be there regardless of what I do, I won’t be fully able to do other things. So. Please do this work so I can be on program committees and other stuff instead! Please.


Feedback on the FOSS projects course (RIT) from spring 2018


This is long overdue, but I finally sat down and processed through the course feedback we got last semester for our class on FOSS development. This post mostly consists of notes I want to remember for next time, but they’re public because… why not?

First, there were some things we didn’t have control over. An 8am start time for a computer science class? Yeah, not the most popular thing. (Though one student did like it!) Similarly, our course management system (dictated by the university) is nobody’s favorite thing. And our computer lab was not set up for groupwork — it was set up in a giant “X” shape with individual computer stations, and our interpreting team (Jess and Mo!) had to run circles around the entire room to go from student to student.

I’d love to have more control over our physical space and… uh, temporal time? (Honestly, for this class, it’s practically a studio course, so I’d rather meet once for a 3-hour work session than for 1.5 hours twice a week at 8am.) But sometimes that’s not an option.

I personally wish we’d had the bandwidth to discuss more current events in the FOSS world. We spent all our time focusing on the projects students were working on in class, with occasional mentions of how this or that lined up with an external community’s release schedule or conference timeline or whatnot, but being able to drop in asides of “today, on LWN, I read…” would have been a nice extra touch. That having been said, I was so overwhelmed during my first semester teaching at RIT that I’m totally fine with this not having been my first priority.

I also have one note about emphasizing a “high level view of open source communities before jumping into work,” which – I don’t recall if that was in appreciation of what we did and/or a request for more of it, but that’s something I want to iterate on being deliberate about next time around, too.

Similarly, we got high marks as instructors in terms of giving feedback, and doing so in ways that were incredibly tailored to their projects (which is what one does in a studio course). Students also enjoyed being able to choose their own projects, which is a central part of the course design (at least for me). Seriously, the number of student notes I have staring at me saying that kind of thing with multiple exclamation points and phrases like “SO AWESOME” is… pretty substantial. Learning how to find and scope and recalibrate on your own project is a hard skill that’s not often taught in universities, and they recognized that as a valuable skill — plus, as one student put it, “it allows students to work on a project they have motivation to work on.”

Students appreciated the repeated emphasis on stand-up presentations and getting feedback on speaking skills. Their presentations did noticeably improve during the course of the semester. Similarly, they thanked us for forcing them to write blog posts and critically analyze their own interactions with FOSS community upstreams. This is in reference to a homework variant where they had to submit a conversational artifact — an IRC transcript, an email exchange, a github comment thread, etc. — and their analysis of what happened in it. I like that homework variant as well, and probably will keep it.

We did get asked to be more explicit about our preferred means of communication. We gave students a lot of options as to how they could contact us, but they didn’t know which ones we wanted them to use — the answer was really “any of the ones we said you could use” or “you could have asked us which was fastest,” but it would also be easy to just list them in order of preference in the syllabus, so that’s a reminder to me to make things more explicit when I can, so students don’t even have to ask. Similarly, our office hours were extremely well-attended (we held office hours as an open FOSS work time) and there was a request for more opportunities for 1:1 meetings. Our response: “yes, you can always ask us for that, and people did ask – and get – that during the semester.” But again, making-explicit more is never a bad thing; it’s the reason I put a lot of thought into having text about disability accommodations, “if you’re having trouble with housing/food/finances, please let me know so I can help,” etc. in my syllabi, because even just asking can be extra work.

I grinned at one comment, which was about our use of Google apps for some aspects of the course — because “it’s not Free Software.” True! We had them all upload their slides into a shared Google Slide deck for sprint presentations, to make fast work of transitioning between presentations. We also had things like presentation sign-ups on a Google Doc. Could we have used Beamer and github? Yes. Would it have taken more time for everyone to climb that learning curve? Probably. Would I like to have a completely FOSS stack for this course? Yes. Do we have those tools right now, in usable state to pick up and go with (given the time Steve and I had as faculty to prepare)? Not at the moment. When there’s a good FOSS alternative, I’ll use it. Until that time, I’m willing to make the compromise of using infrastructure that is ready-to-go so students have more time to work on their FOSS projects instead of learning new infrastructure simply to use FOSS software for presentation slide decks.

All in all, I thought it was a pretty good first run for the course redesign. I’d like to teach this course again and iterate on it — I need to find a better way to keep course materials online and easily findable/editable for the future. If anyone has suggestions on how to do that, I’d love them; I’ve been thinking about porting as many of my course materials to, say, github pages (or similar) as possible, but struggle with the bandwidth to think about how to do that well — so if anyone wants a curricular design related semi-tech/semi-content project, let me know!


“What is Engineering” in the inaugural issue of Murmurations


Murmurations, an open access scholarly journal on emergence, equity, and education, launched today. It works towards “systemic social equity in education by giving visibility to the views that are normally hidden,” and I’m honored to be part of the inaugural issue — and to finally have a more formally published version of my “What is Engineering” comic from 2011. The PDF version that link points to has full image descriptions inline*.

This comic (or “graphic essay,” if you want to sound fancier… but really, comic) is one of the more accidentally popular things I’ve made since the long blog post in which it first appears. As of 2018, it’s been viewed 7.8k times, assigned as homework to students in classrooms I’ve never seen, made surprise appearances in South Africa (when my advisor Robin Adams met another researcher who asked if I was her student, then pulled a copy of the comic from their bag), and… wow.

You can view the full inaugural issue now — Murmurations itself is an experiment as to what journals, the review process, and many other things might be. For instance, what if authors stated their positionality at the beginning of each piece? I’d never previously seen someone outwardly declare they were cisgender in a piece that wasn’t centered around gender identity; it’s refreshing to declare things typically taken for granted (I’m still waiting for my colleagues to “out” themselves as hearing and abled, whereas I’m often expected to walk around proclaiming that I’m Deaf).

What if “reviewer” (we call them “reflectors”) comments and dialogues on earlier revisions of a piece could be viewed along with the published version? What if the piece could continue to evolve after publication? This is what I’m hoping for mine; it was done by a much younger and less trained version of myself, and I would love to do a substantial revision and re-drawing based on the feedback and reflections of others, so please chime in!

Side comment: it is a strange feeling to look at page proofs of my writing every time it happens; the words look so much more polished, formal, and final than they ever felt during the writing process. Layout is powerful.


ASLCore: affordance theory, or “thing-inform”


Okay. In my last post, I danced around happily exclaiming about how cool the ASLCore project is for engineering and computing (and all the other fields it covers — philosophy, art, biology, literature, physics, etc.). In that post, I used the stress/strain curve (and its related group of concepts and their respective signs in ASL and words in English) to explain a bit of our process.

In this post, I want to discuss one of my favorite parts of working on ASLCore, which is that it leads to great conversations about what these words are, what these terms mean. These conversations happen both within the ASLCore team and outside it.

For instance, Mitch Cieminski (hearing, non-signing friend and colleague) and I were talking this week about affordance theory in the context of some of their work. During our conversation, I showed Mitch our new sign for “affordance.” (Crucial note: our intent is not to be prescriptive or say that our sign is the “correct”one — it is to offer it to the ASL community as an option, and let people choose whether and how to take it up and play with it, because this is how language works: organically, communally.)

Now, unlike some other technical terms, there’s no universalized set meaning for what, precisely, “affordances” are in English (or any other language, as far as I’m aware). If you’re new to the concept, check out the Wikipedia page, and you’ll rapidly find that the jury is still out on precisely what it means for something to “afford” something else; are we using Gibson’s definition? Norman’s? Someone else’s? (Can any of these definitions really be viewed as formal definitions?) The design fields have been debating this for a while, and I don’t think we’ll resolve that debate of anytime soon. One reason I am really proud of our signs for “affordance” and “afford” is that they feel (to me) as if they capture the shared essence of the concept represented in that discourse… without attempting to come down on one side or another of the definition debate.

The sign for “afford” (which is a verb) comes from an ASL sign that is often translated into English as “to inform.” It is directional, which means that it can be signed in ways that indicate who is informing whom. If I signed it starting from me and towards you, it can be translated “I am informing you.” If I signed it towards myself, that might be translated as “inform me,” or “let me know.” You can use it in many ways, but it’s typically set up as going between two beings/persons – person X is informing person Y.

Our sign for “afford” takes that same sign’s motion and handshape — but instead has it come from a thing (here, represented by an invisible object held in the signer’s other hand).  It’s what the object tells us. It’s what the object lets us know — about itself, about how we might use it, and so forth. For an object to afford something is for it to be informing us via how it exists as an object (as opposed to, say, having separate documentation telling us how we ought to use it).

The noun form — what an object affords — is an “affordance.” The sign adds the possessive marker (how we would indicate concepts like yours, mine, ours, etc.), which assigns the affordances as belonging to the object, and also changes it from verb to noun. Again, roughly speaking — the concept is that of the things that the object tells us about itself. (“See that object? See how it tells us things about itself? Those things it tells us — they are affordances.”)

Mitch caught on immediately as to how we could play with the concept of “affordances” via playing with the sign. Would it, Mitch asked, be signed differently if I talked about what an object affords me, as opposed to what an object affords someone else? Yes, I answered; I’d just change the directionality — the object informs me, or informs you, or informs them, and you can tell which one I mean by which direction I make the sign in. We both grinned, because this is how affordances work — an object’s affordances are relative to whoever might be using it. (An infant car seat affords sitting for my friends’ tiny children — but it does not afford such for me as a full-grown adult who wouldn’t fit.)

Thing-inform; what it is that the thing informs us of. Affordance.

Flash back to the ASLCore team discussion several weeks earlier, where I was attempting to explain the (very abstract, philosophical, and ponderously worded) formal definitions I had found to the translation team, using objects around the room as examples. A chair affords sitting. The loop on my water bottle affords my picking it up and dangling it on my finger; as does the handle on this mug, but this smooth-sided glass does not have this affordance. This door handle affords pushing, and also opening the door — but in a different way than that doorknob, or this plate on a swinging door.

We went through several translation options. Was an affordance something that was “possible” to do with a thing? No — it would be possible, albeit awkward and painful, for me to sit on my water bottle, but I would not say my water bottle afforded sitting in the way that, say, a chair does. Did “to afford” mean “to permit” or “to allow”? (This had been my previous closest sign for the concept.) No, that didn’t feel quite right; we needed something stronger. Was it what was “all right” to do with the thing? No, this wasn’t so much about social acceptability; weapons clearly afford harming people, but it’s often explicitly not ”all right” to use them to do so in most situations. 

(We also punned bilingually. Until we settled on the current sign, we occasionally used the phonetic equivalent of “Afford-Dance” as a placeholder — the signs that you’d use to mean “afford” as in “afford the cost,” and “dance” as in “dance to the music.” The room was full of winks and grimaces, snark and linguistic play.)

Was an affordance like a feature? asked the translation team. Did something need to be a product in order to afford things, did it need to be a final product, or could a design or prototype or an object that was not designed by humans also have affordances? (Yes; a chair affords sitting, but so does a fallen tree stump in the woods.) How was the notion of affordance related to our earlier discussion of the functions of a product? (Later, we would discuss how a software function in the context of computer programming was both related to and distinct from this notion of the functions of a product.)

The team pushed my understanding of the topic, of the term, of it usage, of its interconnections. I’ve written papers using affordance theory, and I had never thought so hard about what it means for an object to afford something, or what an affordance was, or was not — I could no longer take the term for granted. Creating language is hard, folks! Creating language is hard, and it’s one of the most wonderful kinds of hard I’ve ever experienced.

Anyway. We went off on this for a while, and then at some point, someone signed so, it’s what the thing tells you about itself? and I swiveled around, electric: that, THAT! Yes! It’s what the thing tells you about — how you can use it, what it’s for… 

And so they tweaked it, and then – thing-inform. Afford, the verb form. And then the noun form… what it is that the thing informs you of – affordance(s).

We had a sign. I was so happy that I think I actually jumped for joy. I definitely fist-pumped, and a bunch of (hearing) friends who knew affordance theory got all-caps, multiple-exclamation-points text messages during the next break that WE HAD A SIGN FOR AFFFORDANCE!!!! because I was… uh… maybe just a little bit excited. (There’s a reason why my name sign comes from the image of a puppy’s tail enthusiastically wagging.)

So that’s the story of “affordance” and “afford,” as best as I can tell it. I want to write this out for so, so many other signs as well — most of them have a story like this, and a meaning packed in, that is hard for non-signers to understand. I want to share with my non-signing friends some of the complexity and richness of what we are doing, in this world of engineering and computing ASL — because I hope you’ll start to see how Deafness and Deaf culture and signed languages in engineering might be something marvelous to learn from, not something to pity or treat as a mere “accommodation” or “support” to help people “catch up” (which implies that they are “behind” to start with, which is not the way it has to be).

I want you to see this with the sense of play and joy and wonder and intensity we brought to it; I want you to see why it is beautiful — so you will want to see and use this language, too.


ASLCore: stress/strain curve zoom levels


This is partly a follow-up on my post on why I can’t (yet) teach engineering in ASL (short version: lack of technical vocabulary). This month, I’ve had the great pleasure and honor of working with one of the teams tackling that problem – ASLCore. I get to spend three weeks this summer working on engineering and computing vocabulary as one of their content experts; so far I’ve been there for two weeks, with a third week coming later in July. As of this writing, the first few signs have started to appear on the website — most are not there yet (we have several hundred), but Kai, our wonderful film/web guru, is working nonstop to continuously edit and add the new ones.

It’s one of the most fun jobs I’ve ever had. My role is to teach engineering and computing (the latter with my friend Ian Smith) to a team of amazing ASL masters — Deaf linguists, actors, translators, and poets — and watch them turn my fumbling non-native signs into vivid, clear, visual renderings of technical ideas. We created both signs and expansion videos of how and in what circumstances to use which sign for what concept — for instance, for signal processing, the sign for “frequency” in the time domain is different for the sign for “frequency” in the frequency domain.

Signs also need to link and flow together in ways that make them usable for visually discussing technical topics. Among other things, this means that two signs that will frequently appear together must be easy and smooth to sign together, both physically (hand shapes should be similar/efficient to transition between) and in the ways we use them to visually represent related concepts. A good example of this would be how we revised the sign we’d been using for “stress” (as in stress-strain curve) when we realized that it depicted the concept at the level you would see with the naked eye, but that all the other signs describing points on the stress-strain curve depicted what happened on the molecular level. We didn’t want to switch to the naked-eye magnification (zoom-in) level for one sign only, but have molecular-level signs for everything else; it would be confusing, similar to the effect of counting “one, two, tres, four” (counting in English and switching to Spanish only for the number “three”). Instead, we revised the sign for “stress” to fit the magnification level of the other signs in that conceptual cluster.

We also came up with naked-eye zoom-level signs for most (but not all) of the same concepts, so signers would have the option of depicting (for example) elastic deformation either at the molecular level or the level we would typically see with our own eyes in the lab or out in the world, with an object bending or stretching past the point where it ceases to spring back to its original form. (Since the molecular-level sign set was complete, but the naked-eye level sign set couldn’t be completed because of how human hands can and can’t move, the molecular-level set became the default conceptual signs, and the naked-eye set became supplementary/explanatory.)

“Stress” is also a good example of a sign that seems to have an English-ASL equivalent already, but which we wanted a technical sign for. There is a sign that’s often used as a translation for the English word “stress,” but that one word in English doesn’t always refer to the same concept — the word “stress” in English often means an emotional state, as in “to be stressed out” or “to be under a lot of pressure.” Engineering stress on a material refers to a totally different thing; the material is not psychologically freaked out by the forces applied to it, as far as I’m aware… or at least that’s not generally what we mean by that phrase in engineering. (I won’t go down the new materialist / posthumanist rabbit holes for this particular discussion.)

The ASL sign that’s often used for the English word “stress” portrays a force pushing down on a surface, so it’s a good conceptual fit for the physics concept of pressure, as in force-over-unit-area. In engineering — primarily in mechanical/materials engineering — we do talk about stress (on a material/object) with the same units as we use to discuss pressure, so our team did discuss just using the one existing sign to mean both concepts. But we ended up deciding we wanted to distinguish them, because we use the two English words (stress vs. pressure) in a different context within engineering, for different purposes — it’s the stress/strain curve, not the pressure/strain curve (the latter phrase is not allowed as a synonym for the former in English).

The translation team asked what the difference was. I had to think about it for a bit, but then explained that we often talk about pressure as being applied to an object, whereas stress in this context is more about the material that the object is made of, and we discuss much of that at the molecular level… so maybe the sign should also be portraying things at the molecular level, and then…

Anyway, you can see how we might have gotten there — and that’s just one example of the kinds of conversations we’d have throughout this process. It is fun.

The idea is that bringing together Deaf expertise in an academic field with Deaf expertise in (American) signed language will lead to — finally — linguistically, culturally, and conceptually accurate ways to express some of these ideas. We also have interpreter consultants who help us see how those signs might be used in spoken-instruction classroom situations, as well as a behind-the-scenes team doing the heavy lifting of logistics, filming, editing, annotating, and keeping the entire team happily stuffed with coffee, cheesecake, and granola bars. I can’t thank them enough for letting me be part of this.

I got a chance to try some of the new signs out with friends at the annual American Society for Engineering Education (ASEE) conference. And… and… they work. I signed an explanation of version control to a group that included non-technical ASL interpreters (who didn’t know what version control was) and technical friends (who knew what version control was, but don’t know ASL). The interpreters translated the everyday signs, and then when we got to one of the new (technical) signs, my friend Todd Fernandez blurted out — and in some cases, explained – precisely the right word to fill in the gaps. Typically, for that level of technical precision when I am signing, I have to fingerspell endlessly (and my fingerspelling is terrible) and otherwise keep on pointing to or borrowing from English. But that night, I didn’t. And it felt amazing.

I want to unpack more of these signs for my non-signing, English-reading friends so you can see a little bit of why I’m so excited by this process. More on this in my next post, where I’ll work on unpacking just a single word.


Why I can’t (yet) teach engineering in ASL


I’m a Deaf engineering professor. I want to teach my engineering college classes in ASL. This is a goal I have for the next couple decades of my engineering faculty career — to teach my way through all the core undergraduate engineering courses, plus the required undergraduate ones in my field of electrical/computer engineering (ECE) — in ASL.

Right now, this is not possible.

This might seem strange, because — I’m Deaf! I sign! I’ve taught engineering at the college level for years! But nope: being an expert at teaching a topic and being fluent in a language… does not mean you’re automatically able to teach that topic in that language. You need to be fluent in that topic, in that language.

And for that to be possible, vocabulary needs to exist. You need ways to efficiently express disciplinary concepts in the target language (in this case, ASL). Vocabulary is a key part of language; language has to be there for communication to happen; communication must happen for teaching to occur. And right now, I don’t have (good) signs for basic concepts such as “voltage,” which is an idea so fundamental that I can’t teach elementary school electronics without it, let alone college-level classes.

Now, I can (and do) teach engineering voice-off, signing, but I’m not using ASL when I do so; I’m using a signed form of English (which some people would call PSE or contact sign). I’m basically transliterating, with the occasional insertion of ASL grammar and a couple of classifiers. I’m not voicing, but you could read an entire English engineering lecture off my lips. In other words, I’m teaching in “English, with hands.”

ASL is not “English, with hands.”

We need vocabulary. We need ways to express these ideas within Deaf language and Deaf culture — ways that are efficient, that don’t require tons of expansion every time. In English, we say “voltage,” not “the electric potential difference between two points.” The latter is a definition, not a term. Similarly, I can explain voltage in ASL (perhaps as “electric pressure point point compare”), but I need a sign for the concept, and other concepts like that. If I can’t, I don’t have a professional vocabulary. It is akin to restricting technical communication to Basic English or Up Goer Five. If someone used the phrase “funny voice air” instead of “helium,” we’d figure they didn’t know what they were talking about, because there’s a word for that.

We also need ways to express these ideas within this language, not just ways to refer to the concepts as expressed in another language, as with fingerspelling. Yes, short fingerspelled words can turn into lexicalized signs, like “bank” and “OK,” and in this case perhaps “amps,” but what do we do for “semiconductor” or “bypass capacitor” — abbreviate? “SC” is already “South Carolina,” and “BC” is birth control, and I’d like to use my brain for things other than figuring out sentences like “You’ll need a BC in P to smooth the MC input V.” Or if we break the English word into components and then sign those, we get things like “tiny administrative person” for “microcontroller” (micro-controll-er). And then I flinch again, hard.

At that point, we’re just pointing to the English. If I wanted English, I would use it. I want ASL.

Every other Deaf engineer I know does this exact same thing. The moment we begin discussing technical topics, our signing shifts — hard — towards English. Perhaps we flinch a little and apologize to each other for using mouthing (and only mouthing/lipreading) to distinguish between “electric,” “battery,” and “circuit.” Perhaps we comment that, yes, signing “tolerate” (as in “to put up with, to bear”) is a poor sign for “tolerance” (permissible variation in a measured value). But we do not have other ways to do this. Not yet.

Fascinatingly enough, this has happened before — in engineering and computing and other college-level STEM fields, even — with spoken languages. There are plenty of examples of decolonizing the language of (collegiate/professional) instruction — I recently learned that Japan is doing this, for instance — but my favorite example is Hebrew and the War of the Languages. When the first Jewish (later Israeli) universities were being established, they knew that Jewish culture was amazing, and that Hebrew was a rich and beautiful language with a deep, deep history and multiple ways of expressing the concept of “God” — but no way to express the concept of “computer.”

And guess where a lot of their professors had trained? Germany. Austria. All their notes, all their books, all their training on… say, computers — they were obviously not in Hebrew, because there was no Hebrew word for “computer.” But yeah, it was a little problematic to be teaching programming… at a Jewish university… in German. And so, rather than capitulate to “eh, I guess we have to teach in German,” they built up the Hebrew language so that they could have technical discussions within it. They enriched their language and their culture instead of switching to another. This took a tremendous amount of work — many people, over many years, working to create a world where it was possible to teach computing in Hebrew. And now they have it.

That’s what I want for ASL and engineering (and computing, and technology). It’s going to take a long time. Probably the rest of my career. (“Congratulations, you’ve found a lifetime side project.”) It’s going to take a lot of collaboration with a lot of people and a lot of work and it’s never going to be done, because languages are never done. It’s going to be a lot of awkwardness and stumbling experimentation and a lot of new engineers brave enough to go out into the world not just with technical skills, but with language (ASL) to communicate those skills, and we’ll have a lot of short-term inefficiencies compared to “but why don’t you just teach it in English or signed English?” — but look: we’re going to make a world.

It does not yet exist. That’s why we need to make it.


Parents have visited, semester winding down


Freewrite/braindump/linksave.

My parents came to visit me in Rochester this weekend, which was nice – and not only because I got to eat out more than I usually do. I like how my relationship with my parents has been slowly evolving into one between adults, one of whom happens to be the child of the other two.

They came to Imagine RIT, which is a huge student (and non-student) project display festival. It’s massive. Massive. And it’s also the largest-scale interpreting setup I’ve ever seen to date — interpreters everywhere, stationed across campus, ready to walk over to whatever exhibitions needed them. Seeing DHH folks in a mix of both presenter and visitor roles was also quite nice.

I’m still navigating how to interact with groups of people when some of them know me as “a person who speaks” and the others know me as “a person who signs” — which language do I use when? — but it was also nice to watch my parents interacting (fairly smoothly!) with signing DHH people. Mostly I stood back and watched them chat with each other, but a few times I dropped in (signed) comments and it felt pretty smooth. (But generally, it would feel weird to sign to my parents through an interpreter… about as odd as if they spoke Chinese through a translator to me. The presence of other people is what allows us to use those combinations of modalities and moderations with each other.)

The semester is winding down, and I’m staring at the research projects that remain. I am quietly excited about some of them, eager to be challenged by others, and (honestly) hoping to find ways to redirect yet others towards other people as quickly as possible before I’m locked into something I don’t actually want to commit to – the work of how to say no and frame that no in ways that actually work for others. (It seems silly when I write this, but… the intellectual and emotional labor associated with that last part are tremendous sinks for me right now. Tremendous.)

I’m still trying to… maybe not “rediscover” my scholarly soul, but to keep a scrawny, struggling flame alive. I want to read things. I want to just sink into ideas and learn and think, and sometimes it feels like there’s so much friction around all of it I want to give up on it all. Still working on this.

And then random links I don’t want to lose. I found an old newsletter from Erik Kennedy about Magic Ink, which is a lovely longform piece on interface design that would probably make for a nice inflight reading at some point. And then there are the things I want to read and do, like the Chinese chicken soup recipe my mom just sent me (yep, we ate this as kids).

Okay. Back to… things. I feel like these posts are me surfacing for air and gasping; this space (online, text, long-form) is still where I can most easily breathe. And I need air, and company, in spaces where I can breathe… well.


Presenting at RIT’s Interdisciplinary STEM Ed Research Forum


I was one of the presenters yesterday at RIT’s Interdisciplinary STEM Ed Research Forum, so I’m posting my talk abstract here mostly for posterity, and because I’m too worn out at this point in the semester to say anything clever about it.

Title: Technology, Engineering, Computing, and Hacker/Maker Curricular Cultures: Alternative Universe Edition

Abstract: What is engineering? Who is a maker? What does it mean to be a technology professor? Questions like these point at the underlying ontologies of a group’s curricular culture, or their shared basic assumptions regarding teaching and learning, including how one should act, think, and feel in educational situations. My work engages with curricular cultures in postsecondary TECH (Technology, Engineering, Computing, and Hacker/Maker) education, a.k.a. “the making of people who make things.”

One aspect of this work is, quite literally, world-building and alternative universe creation. By bricolaging technical work with narrative interviews, ethnographic observations, science fiction, and the visual and performing arts, I create… not science fiction stories, but engineering (tech, computing, and hacking/making) education fiction — or rather, things that start as engineering fiction, as well as tools for making them into engineering nonfiction.

In this talk, I’ll discuss the prototyping of alternate TECH education universes and cultures with two case studies: (1) what if computer science college courses were modeled after hacker/maker community praxis? and (2) what if engineering education had been historically led by Deaf people, and hearing engineers were a minority? As with most cross-cultural encounters, seeing other possibilities for TECH cultures helps make us aware of the assumptions we’ve embedded in the discipline thus far, so we can decide what worlds we want to build going forward.