Posts that are engineering edu-ish

APA style and qualitative research methods resources in ASL


My friend Anna Murphy recently sent me St. Catherine University’s library resources on APA style — and they have ASL versions! Actual ASL with nice translations, not ”we signed the English word for word” versions. I think these are a nice high school or early-college intro for ASL users, maybe good for a first-year college seminar course. (I’ll ask Corrine Occhino about using them for ours, since this is a lovely set of matched bilingual resources.)

Joan Naturale also pointed me to an ASL companion to an introductory qualitative research methods textbook (Research and Evaluation in Education and Psychology (REEP): Integrating diversity with quantitative, qualitative, and mixed methods). ”ASL Companion,” in this case, means there are well-done chapter summaries in ASL with the blessing of the original author (Dr. Donna Mertens). This is a nice textbook, in its 4th edition from Sage, not some hastily cobbled together thing for the sake of having something signed. Good scholarship in good ASL is, sadly, scarce stuff.

This stuff is important; not only does it make these materials more accessible to those who are native users of ASL, it gives us a glimpse towards what scholarship in ASL might look like. And yes, there have been Deaf (and hearing!) researchers working on “academic ASL” for a while (and what that means is still up for debate). I’m new to the conversation and feeling my way into a world that people far smarter and wiser (and familiar with ASL and Deaf culture!) have created before me, with the hopes of contributing to it as well.

My question is: what would it look like to do this in engineering, computing, and in engineering/computing education? I’ve seen scholarship in ASL, but only for clearly ASL/Deafness related fields… signed linguistics, Deaf education, Deaf history and rights, and so on. I’ve seen stuff about ASL in other fields, but it was written in English. What does it look like to do engineering and computing work in ASL and/or in a culturally Deaf manner? What would culturally Deaf engineering look like?

And I’m pretty sure that look is a key operative word here, but it’s also going to sound like something — Deafness doesn’t mean the absence of auditory information! — and it’s also going to be a host of other things, because Deafness isn’t just about visuals; consider the DeafBlind community, consider all the tactile/kinesthetic richness of the world, consider — but I digress.

But what will Deaf Engineering (and Computing) be like? I don’t know. I’m aware that I’m continuing to write these blog posts in English, and I’m okay with that right now, so long as my actual published/presented outcomes on this front come out bilingually. In part I’m writing in English because this is my scribble pad and I’m a native English writer, and it’s what my thoughts come out most fluidly in (if I thought best in Spanish, I’d be writing in Spanish). But these kinds of resources are not just examples and resources for my future students; they’re building blocks for me of what might be, what things might look like. And I can also tell from watching them that they took tremendous amounts of work to create, so…

..examples. I leave them here as exercises for the reader.


I love the rhetoric in this guide to online conference accessibility.


Blogging things that have caught my attention, so I can close browser tabs.

This concise guide to online conference accessibility (from the Society for Cultural Anthropology) has such lovely prose. It links to a resource on in-person conference accessibility from the Society of Medical Anthropology, if you’re looking for that kind of thing as well. But — back to that prose…

In disability theory and activism… conversations about access seek to ensure that the widest swath of human variation can be a part of an activity, collectivity, or space. As a result, reflections on access bring into view unmarked forms of privilege that are built into material and technological forms.

Mmm. See that? Straightforward, incisive, and “this is what we do” rhetoric. Not wheedling, not othering those “poor disabled people” we should “help,” not painting it as some kind of charity cause or something that nice abled people do because they’re so nice. Just… okay, let’s be conscious, let’s bring the widest swath in from the start, and let’s attend to what doing so might make-visible to us. This is the rhetoric of a world where access is Already A Thing; this is the rhetoric of someone who doesn’t have to beg for a seat at the table; this is the way you speak when you are confident about how the world is, and who you are, and how we ought to be to others. let’s continue.

All speech should be at an easy-to-follow pace. No speed-reading! It’s not just inconsiderate when your remarks are too long and you rush through them; it actually excludes people from accessing what you are saying. Invite people in. Share your words and images in a way people can digest and enjoy them.

Notice the framing of “don’t you want people to understand, digest, and enjoy what you’re telling them about?” They’re framing access as something that also benefits the presenter (and it does). We don’t tell people to copyedit their writing because we assume a deficit on the part of readers; we tell people to do it because it makes their writing better and helps them communicate their idea more clearly. Of course readers would struggle to comprehend a page full of misspelled words and incomplete sentences; it’s not them, it’s the author. Of course attendees will struggle to understand rushed remarks; it’s not them, it’s the presenter. This is just… good communication practice.

The guide points at complexity without getting bogged down in discussing it (as I often do). For instance, while giving an example of how to make visual elements accessible to conference participants with non-normative vision, they discuss how “assumptions about race and ethnicity may come to the fore when you translate the visual into the verbal.” Do you describe people as “light-skinned” or “white”? What do these words mean? When do they make a difference?

Where and how do we become cautious of our desires to communicate in straightforward ways — “that’s a white woman” — and when does it become important to disrupt exactly that kind of straightforwardness? “Light-skinned, female-presenting… but we don’t know how this person identifies?” I appreciate the guide pointing at these kinds of questions, and then leaving us with this:

There is no simple answer that fits all cases, only important choices that demand reflection… The point here is to be conscious of ways that conference participants may or may not be able to access your presentation, and to create something that strives to include…

The final paragraph frames accessibility as an art of conviviality, and therefore as a way to follow the tenets of the anthropological disciplines themselves. This is a brilliant framing; “these practices are not other, they are inherent to being better at who we already are.”

Ultimately, accessibility is an art of conviviality, a means of acknowledging and incorporating disabled and nondisabled people alike. As an art of living together, it requires conscious reflection, creativity, and openness to difference. Thus, while practicing accessibility may be new to many anthropologists, its fundamental premises are at the heart of our discipline.


RIT FOSS projects: midterm praxis reflection assignment (feedback welcome!)


As part of the RIT FOSS Projects course this year, we are having students write a substantial mid-term reflection on praxis. Here’s the current version of the assignment – feedback welcome, of course! (For Spring 2018 students: both this version of the assignment and any edited/updated versions are acceptable for submission – you can choose which you’d prefer to do.)

Your praxis reflection consists of answers to the following questions, submitted to MyCourses in English and/or ASL in any format readable by your instructors (.txt, .odt, .pdf, .doc, and links to signed videos are all safe; ask about other options and we’re likely to say yes).

This reflection should be several pages long and reflect substantial amounts of thinking; it has the same point value as a two-week project sprint. Only you and your instructors will see your answers to these questions. Grading is 5% for each of the 18 mandatory questions, plus 10% for spelling, grammar, clarity of writing, etc.

You will be scored on the quality of your reflection, not the behavior you are reflecting on (i.e. a thoughtful analysis of “in hindsight, I really messed up” will get a high grade, whereas simply saying “I did well” without explaining what you did well and why will get a low grade).

  1. In 1-3 sentences, summarize your overall project, as you currently understand it. This summary should reflect your evolving understanding of your project, FOSS contributions, and feedback from classmates/instructors so far.

  2. How has the summary above changed from the summary in your initial/simple project proposal (or, if you switched projects, the first time you summarized/presented it to the class)? Why/why not? What feedback and/or learning experiences have informed your writing of the current version? (minimum 3 sentences)

  3. What have you learned about your FOSS community and its culture and health, and/or individual contributors you’ve been interacting with so far this semester, and how does that affect your project plans for the rest of the semester? (minimum 3 sentences)

  4. What have you learned about your intended end-users so far this semester, and how does that affect your project plans for the rest of the semester? (minimum 3 sentences)

  5. Are your goals clearly defined (is it unambiguous whether you’ve achieved them or not), do you regularly measure your progress against them, and do you recalibrate them as new situations come up? Why or why not? (minimum 3 sentences)

  6. Are you using existing tools, libraries, and knowledge from others whenever possible, instead of reinventing the wheel? Why or why not? (minimum 3 sentences)

  7. How are you choosing tools? If some of them are new to you, are you giving yourself adequate time to learn them? Are you investing in tools and practices up-front that will make your life easier later on (i.e. automation of test/build infra, documenting as you go, etc.) Why or why not? (minimum 3 sentences)

  8. How are you getting feedback on your community contributions and/or development products, and from whom? Are these the right people? Why or why not? (minimum 3 sentences)

  9. How are you planning for the future in terms of making it possible for you and/or others to continue using or building on your work? Why or why not? (minimum 3 sentences)

  10. Rate yourself 0-5 on the following (0 = whoops, 5 = amazing), and give a 1-3 sentence explanation for each rating. Ratings are about you individually, not your team as a whole.

    1. Clarity of goals

    2. Technical progress towards goals

    3. Leaving a trail (code commenting, documentation, blogging, issue tracker usage, etc.)

    4. Engaging your users

    5. Engaging your FOSS community

    6. Adapting as things change

    7. Other (optional, please specify)

  11. What qualities does a good FOSS contributor and/or teammate have? List at least 3, with rationale for each. (Ex: “A good FOSS contributor/teammate is X, because Y.”) there is not a canonical right/wrong list; we are interested in seeing how you are thinking, not whether you guess the “correct” list of qualities.

  12. If you have teammates: how do you feel about the way your current team is working together? If you are working alone: who have you engaged with regarding your project so far, both within class and outside of it, and how do you think these engagements have been going? Be specific and give examples (ex: “we can resolve disagreements quickly; for example, last Tuesday we were debating whether to do X or Y…”) (minimum 5 sentences regardless of which option you choose.)

  13. What qualities do good development and/or learning goals have? List at least 3, with rationale for each. (Ex: “A good development/learning goal is X, because Y.”) Again, there is not a canonical right/wrong list.

  14. We acknowledge your goals can and should keep changing as your project progresses, but what are your current development and learning goals for:

    1. Sprint 3? (minimum 5 sentences or bullet points)

    2. Sprint 4? (minimum 2 sentences or bullet points)

    3. Sprint 5? (minimum 2 sentences or bullet points)

  15. What is the most unexpected or surprising thing you’ve learned about contributing to FOSS projects so far this semester? (minimum 3 sentences)

  16. What is the most unexpected or surprising thing you’ve learned about yourself so far this semester? (minimum 3 sentences)

  17. What is the one thing you could do this semester that would have the biggest impact on your approach to this course / your ability to contribute to a FOSS community / your development as a professional? (minimum 3 sentences)

  18. How will you approach the remaining sprints this semester differently than the sprints you have done so far, and why? (minimum 3 sentences)

  19. (Optional.) Any notes for us on how to run this class next year? We’re interested both in things we should keep/do again, and things we should do differently.

  20. (Optional.) Anything else we should know?


Liveblogging RIT’s FOSS projects class: initial questions for community spelunking


Stephen Jacobs (SJ) and I are co-teaching “Project in FOSS Development” at RIT this semester, which basically means “hey students, want to get course credit for contributing to a FOSS project?” The class is centered around 5 project sprints of two weeks each. The first 3 weeks of class are preparing for the sprint periods; the week before spring break is a pause to reflect on how sprints are going. Otherwise, class efforts will be centered around executing project work… (aka “getting stuff done”).

From the syllabus (http://bit.ly/rit-foss-projects-syllabus-2018):

This course is a studio-centric experience designed to immerse students in the praxis of FOSS (Free and Open Source Software) communities. Notice that we focus on praxis, which is a conscious enactment of practice deeply informed by theory. In other words, it’s important to be practitioners who can think about their shared practice.

Notice also that we talk about the praxis of FOSS communities, which includes but is not limited to software development — ways of communicating, collaborating, designing, testing, marketing, budgeting, meeting, etc. are just as much a part of FOSS (and software engineering) praxis as writing code. You will be creating FOSS software, and you will be engaging with the rhythms, relationships, and routines of an established FOSS community with a complex set of sociotechnical dynamics that exist independently of yours. It is our hope that this course will help you navigate the kinds of delightfully messy, large-scale, long-term projects that you will encounter out in the real world.

I’ll be liveblogging the class, as one does. Right now, students are working on their project proposals, which is a big messy task that involves spelunking into existing FOSS communities, figuring out what’s up, and thinking about what’s possible to accomplish during the course of the semester. During our last class, we collaboratively brainstormed a list of starter questions we want to find out while doing that initial community spelunking. I was impressed by how much the students were already thinking about sociotechnical dynamics (instead of just starting to myopically look at the code in isolation), which makes me super happy.

Here’s what we came up with, in thematic clusters.  You can think of these as guiding questions for a spelunking quickstart such as http://blog.melchua.com/2010/10/08/possesa-fri-5-minutes-of-improvisation/ (basically, if you only had a few minutes to get a sense of whether you wanted to contribute to a FOSS project, what questions would be the highest-priority ones to ask)?

  1. What are we gathering around?
  2. What are the goals and the roadmap to get there?
  3. What’s the purpose of the project? Do they have use cases?
  4. Why should I want to contribute?
  5. How do I find people and information and ask for help?
  6. How do they communicate? Do they have forums, chatrooms, mailing lists, etc. and how can I start lurking?
  7. Who’s leading it and who’s working on it?
  8. What is the governance/leadership structure? How do decisions get made, and how fast?
  9. Do they have local meetups and/or online ones I could attend?
  10. How complete are the docs?  Where do I go and what do I Google if the thing I want isn’t in the docs?
  11. How thoughtful have people been about the contributor experience (and do I want to have that contributor experience?)
  12. Do they have a code of conduct? How good is it?
  13. Do they have contributor guidelines?
  14. How well do they Onboard?
  15. How can I help and what skills do I need? (Can these questions be answered easily?)
  16. What does the code activity look like?
  17. What’s the infrastructure?
  18. What is the license? (Make sure it’s actually a FOSS project.)
  19. What and when was the last commit to a core repo?
  20. What/when was the latest release and how is it working?

What goes through my mind on the first day of teaching as a faculty member


Today is my first day of teaching as a faculty member. I am nervous, woke up early (read: couldn’t sleep), and forgot to eat breakfast because I was so nervous I ran out the door without grabbing the food I’d planned. I spent way too much time stressing out about what I should wear so I would look not-like-a-student, but not like a boring professor (whatever that means), while still being comfortable, while… actually, I’ll just wear the same outfit I’ve worn for all my interviews in grad school ever and just leave off the jacket, because… I know it looks good, or at least the colors don’t clash. Okay.

I feel so very underqualified, and am constantly wondering “who thought it was a good idea to let me do this?” I know this is an emotional reaction and not a logical one because I’ve been teaching undergrads since 2004 and my rational brain is telling me that, by all signs (including lots of overwhelmingly positive student comments through the years), I’m pretty good at it. But. Still. Feelings.

I’m struggling with the feeling that I should redo all the course materials!!!! for the stuff that I’m inheriting, to… y’know, make it better! As if, somehow, revising my syllabus would change students’ lives!!!! Intellectually, I know that actual student gains from a last-minute couse overhaul would likely be minimal, and that the more likely outcome is that everyone would be confused, I would die of exhaustion, and zero other work would get done. I’m making peace with doing an okay-ish job of super-quick teaching prep that leans heavily on material I’ve inherited from the past, and then being really awesome and present in the classroom when I’m with my students. My teaching isn’t going to save the world. (At least not this semester.) And I’m learning (wrestling with) how to be okay with that.

Did I mention that I feel underqualified? And that I don’t want to mess it up? And that I’m worried — even if it’s a slight worry — that I’ll somehow fail students, and everything, and everybody, and… thereby demonstrate that I am Not Ready To Be A Grownup? I mean, I didn’t even take this class in undergrad! Again, not logical responses; rationally, I can teach this, but… my lizard brain is telling me to flee and stress-eat cookies and ice cream. Which I might do tonight regardless.

I have been told that all these feelings and thoughts are completely normal. And I think they are, and I’m not worried (I mean, okay, I am worried, but I’m not worried about being worried). But I wanted to write this down on my actual first day of teaching as a faculty member, so that (1) someday, when other new faculty look at me with the same kind of mild panic in their eyes as I have now, I can point them to this post and say totally normal, I felt this way too… and also (2) so that if I do end up going down in a fiery explosion and turn out to be the WORST TEACHER EVER, I can say “I told you so.”

I’m gonna hope for (1). We’ll see how this all goes.


Seeing myself in the (literal) mirror at NTID’s IT office


Some of you already know (and my previous blog post has hinted) that I’m working in a Deaf environment for the first time in my life — the Center on Access Technology (CAT, pronounced like the animal and signed as an acronym) in Rochester, NY. There’s far too much to say about this — I am glad to be here, it’s an incredible learning experience, and I often feel like a stranger in a strange land… but if there’s anything my training in writing and qualitative research has taught me, it’s the power of vignettes and thick descriptions of small moments. So that’s what I’ll start to share. This one is a very small moment, but it was one of the first things that struck me.

So I’m a new faculty member, trying to figure out how one connects to internet, printers, and so forth, as one does. I’m hitting snags, so I walk over to the IT office inside NTID (basically, the Deaf college within RIT). As I’m waiting for the IT staffer to fiddle with my laptop and fix my connectivity issues, I look around. It’s an IT office, full of familiar-looking cords and bins and tables of acronyms pinned to the walls. I see the student workers perched in front of monitors, typing into a ticketing system.

And then I notice that all of the desks facing the wall have mirrors on that wall, behind the monitors. And my first thought is “oh, that’s nice – I guess it makes the room look bigger.” And then one student walks up behind another and begins to sign, and the second student turns around to smoothly engage them. And I suddenly remember: they’re all Deaf, too.

Like me, they can’t hear footfalls from behind. Like me, they would startle from their monitors with a sudden touch on the shoulder. The mirrors let you see someone approaching from behind, a gentle nudge of motion in your periphery, the visual equivalent of footsteps walking up. And all of this is set up so matter-of-factly, just… how it is, of course we put mirrors behind our monitors! and not as some odd flustered accommodation that treats me as a conundrum in the hearing world (“well, Mel can’t hear footsteps, because she’s deaf, so what do we do?”).

I’m used to having my existence in hearing spaces not forethought (“it never occurred to us that a deaf person might be interested in this event, so we didn’t make it accessible”). I’m used to having laborious forethought be the best-case scenario, where I’m a solitary trailblazing oddity (“we’re open to setting up captions for this; can you do the setting-up in your copious amounts of free time?”). It is strange to be in a place where my individual existence doesn’t need to be forethought, because the space has already been created and inhabited by — and expects to see more of — people like me. It is strange to, at least in this one significant way, not be the Other.

Of course, it’s more complex than that. Even NTID is by no means fully accessible (likewise with Gallaudet). The Deaf (and hard-of-hearing) communities are not homogenous; not everything meets everybody’s needs. I’m not just Deaf, I’m lots of other things as well, and many of those things are still unexpected, unanticipated, not-forethought. There’s a lot of solitaire trailblazing work to do here still.

But dang. A world that is accessible to me regardless of whether I’m there or not? A space that stays Deaf-friendly without me, whose Deaf-friendliness is not dependent on my constant nudging and performance of my life as a reminder that people like me exist? Approaches and solutions that go beyond the things my friends and I can think of on our own?

Whoa.


The CAT Lab Abstract Sorting Hat, Version 0.1


Another post based on stuff I came up with for my lab on the spur of the moment. I know I’m probably reinventing many wheels here, but one reason I’m posting this is so that when I stumble back across wheels others have made later on, I can bring mine out to play as well.

Last week, I had the pleasure of embarking on a spontaneous research discussion with several undergraduate students in our lab (and oh my gosh, everyone, it’s really fun to sign about research because of how much you can play with space*). For context: our lab has historically built things, and publishing papers on the things we build is a fairly new concept. The students are working (some for the first time) on poster abstracts for an upcoming conference, and one had asked for feedback on their draft. I realized it was a teaching moment, rounded up everyone who wasn’t busy, and proceeded to do a group-run workshopping of the first student’s abstract (which, by the way, is a clever museum access system that I’m pretty eager to see written up).

In this particular moment, I realized that the biggest gains were to be had in helping the student realize what they had already said. There were some great ideas in the first draft — in fact, most of what they needed was already there. The trouble was that it was all jumbled up; context trailed into conclusion with a detour through a sentence full of technology-related acronyms. So I made a quick reference to Common Things Your Abstract Might Be Trying To Do, a.k.a. The CAT Lab Abstract Sorting Hat (below) and we went sentence by sentence through the current draft, sorting each bit into its respective house(s) — I mean, uh… sections.

I apologize for the Harry Potter metaphor, but it could have been worse. (Contextpuff! Problemdor!) Examples are paraphrases from our discussion today — I’ve removed details so as to not ruin surprises for their eventual publication.

The CAT Lab Abstract Sorting Hat, Version 0.1

1. Context. What is the situation you are designing within? Start with things your audience will recognize. (Example from today: Museums often include audio-recorded or live spoken-language tours to teach visitors about the history and context of the exhibits they are viewing.)

2. Problem. What is the challenge you are addressing? Be conscious of how you frame the problem, especially if you are working with access-related technologies. (Example: Deaf and hard-of-hearing (DHH) visitors to museums don’t have the same level of access to spoken/audio-recorded tour information. In our framing, it is important that the problem is not that we are DHH, it is that museums have not considered visual access and have therefore left out DHH audiences.)

3. Prior work. What have you and others done in the past to address the problem? What work are you building upon?

4. New work. What is the new contribution you are describing in this specific publication? (Example: our lab has built device A to address problem B; in this paper we describe the new features we just added, namely C and D.)

5. Technical details (optional). if you are utilizing specific technologies that you would like to note, they go after #4 (which describes what the solution does). In the context of a lab full of excited engineering/CS undergrads, I added a note that oftentimes, these details are not important for the abstract compared to what we might usually be inclined to put down.

6. Implications / “so what” / (ASL:for-for)? Why is your work important – what could it change? What would happen if the problem you described in #2 was solved? Be as specific as possible (“allow native ASL users to study STEM topics using their native language” is better than “helps DHH students learn”).

End of the CAT Lab Abstract Sorting Hat, Version 0.1

It’s wonderful to watch students just… be around the lab, working on things. As someone who didn’t get to grow up in this (American Deaf) culture or with this language (ASL), I’m learning a lot from them in just… how to… be. People. Who sign. About engineering. I wonder if this is how new Olin faculty feel, landing as teachers inside a culture they were never students within.

*regarding playing with space to discuss research: even if we weren’t getting into the actual content of our papers, the papers themselves lent themselves to spatial setup. The relative lengths and positions of paragraphs and sections (with accompanying facial expressions denoting emotions about various parts), cutting and pasting and twiddling phrasings and words – I’ve thought about editing spatially even before I learned to sign, but watching students (who are more fluent signers than I am) basically collaboratively editing a document in their shared imagination in mid-air — man, that was pretty cool.


Lab research setup email: creating Zotero accounts


I like sharing reusable text I come up with. In this case, part of setting up research infrastructure for my lab includes getting everyone into a citation management system and giving us a way to share reading notes. I don’t have anything against EndNote or Mendeley (and may someday switch, if massive advantages become apparent), but this email is written for Zotero.

Hi, folks – you should have invitations to create Zotero accounts. The only action item you need to take now is following that link and creating an account, which should take a few minutes. You can safely ignore the rest of this email right now, but read on if you want more information/context.

Zotero is a reference management system. It’s useful for keeping track of reading notes and bibliographic information (which we’ll need for our references section every time we write a paper). Other systems include Endnote and Mendeley; there’s no huge advantage of one over the other, but Zotero is (1) familiar to the librarians at RIT and (2) something I already have a lot of notes in, so I’m starting us out with this.

Zotero is free and open source. When you create an account, you’ll probably be prompted to download and install the Zotero browser extension. I prefer to use the standalone desktop software, but that’s your choice.

Right now, the group library is empty. That will change as I begin writing the literature reviews for our ASEE papers. Feel free to add any citations of your own, and/or to start your own individual Zotero libraries (mine is huge; as I find things in it that may be useful to CAT as a whole, I will copy them into the group folder as well).

I have my own conventions for taking notes in Zotero in ways that are easy to write papers from later  – if you really want to, you can read about it here (http://blog.melchua.com/2015/01/28/how-i-use-zotero-to-take-research-reading-notes/) but I am also happy to show you my system any time we sit down to work together.

Here’s to better research infrastructure!

–Mel


Things that have made me happy lately: qual methods companion resource in ASL, my upcoming review of wake-up systems


These are random things that have made me happy today.

The first is that there is an ASL companion to a qualitative research methods textbook (focused on education and psychology, to boot!) I am already fascinated by the design and translation choices they have made in figuring out what it even means to have an ASL qual methods textbook… how multiple signers in the introduction switch between freezing in black and white when it’s not their turn, and becoming full-color and in-motion when it is, so your eye immediately knows who it’s following. How they’ve translated the phrase “chapter author” not as [chapter write-person], but rather as [chapter sign-person] — “they who have signed the chapters” rather than “they who have written down text for the chapters,” because the “text” is in ASL. These little subtle things that tell you that… yes, this is another culture; this is a different world. (Or in my framing: this is an alternate ontology.

Second is that I am giving my portion of a technology review lecture series (1) on ASL and (2) with a fairly decent dose of snarky humor. My topic? “Wake-up systems for DHH sleepers.” I plan to cover…

  • Cheap Hacks for People With Residual Hearing: makeshift and wholly mechanical scoop and rattle amplifiers for phones (put them on big hard hollow things or in cones made of hard materials… like hotel ice buckets!) Also, reasons why these setups may not be the greatest for smartphone users and/or profoundly deaf deep sleepers like myself.
  • Sonic Alert’s Sonic Boom, which emits ear-splitting shrieks at modifiable frequencies, flashes lights (or rather, intermittently turns on and off power to an electrical outlet embedded into its side), and rumbles a bed-shaker. (And, in high school when I had it close to my CRT monitor, it degaussed my monitor. Anyone want to check out a cute little EMP source?) Also, a brief overview of the sleep cycle, and how this device, while highly effective at actually waking one up, is terrible for waking one up pleasantly.
  • Philips Wake-Up Light: awesome, but expensive-ish, and… let’s talk about the usability of the physical design, shall we? (And the choice of bird sounds as the wake-up recording, which… to me, are setting options of “silence,” “other silence,” and “more different silence.”)
  • Philips Hue system as a cheaper and more hack-ish way to replicate some of the functionality of the wake-up light

Gotta work on my content, draft, translate, and rehearse this. It’ll be fun.


Reading effectively: how my practice evolved from engineer to scholar


I came across Reading Effectively via a tweet by Sara Hendren (thanks, Sara!) and it spurred me to reflect on how I read as a scholar, how I have learned to read, and how I want to continue developing these skills both for myself and those I mentor/teach. Specifically, I’m writing from the perspective of someone who was trained in a STEM field (electrical/computer engineering) and then worked in tech before returning to academia and being plunged into the world of theory.

I thought I mostly knew how to read “theory” when I started grad school. After all, I would read non-technical books (!!!) from fields like anthropology (!!! look at how cross-disciplinary I’ve become!!!) and they would kinda make sense, you know? Maybe it was slow and hard and I had to look up some words on Wikipedia, but… fundamentally, I thought I kinda got it. Wasn’t hard. I mean, I was an engineer. I just… needed to read more stuff.

Now I am pretty sure I don’t know how to “read theory,” and am fumbling my way through complex webs of thought that are larger than what my brain will ever be able to hold. It’s fun. It’s grueling. I love it. And my reading as a scholar is very different from the way I learned to read as an engineer.

There are a lot of similarities. In engineering school (and then at work), I learned that sometimes, reading was slow and hard. Whether it was code, documentation, a technical paper, or a detailed email, sometimes you had to pick through and parse, and backtrace, and look up things that were being referred to (what was that code library for, again?) and sometimes the history of things was important because this part was compatible with an earlier version of thing X, not the current version. I learned that speed was not a metric of success; I learned that sometimes, wrestling with my reading yielded fruit I’d never seen on the first skim through it. I learned to keep an eye out for boundaries and limitations (

I learned that speed was not a metric of success; I learned that sometimes, wrestling with my reading yielded fruit I’d never seen on the first skim through it. I learned to keep an eye out for boundaries and limitations; this device was only tested up to such and such a speed, this wiki page was last updated N months ago and surely the codebase has evolved since then… nobody has done A, or B, or C, and so I could contribute there. These are all useful patterns I continue to employ as a junior scholar.

However, my reading as an engineer (that’s what I’m going to call it for now, since that’s what I was at the time, although this isn’t how all engineers read nor how engineers have to read) is, at its core, different from the reading I do as an engineer-who-is-a-scholar… and specifically, who has spent time in more social-science and arts and humanities environments and methodologies and discourses, and who is super aware that she is still learning it as a new and unfamiliar world.

Here’s the difference.

As an engineer, I was working hard to figure out what the text meant, and this was a task that I could do. Because there was a meaning — singular — to be extracted. The author had thought of a math proof, noted it carefully down, published it, and now I had that in my hands and my task was to… unzip the file, so to speak — unpack and install the archive of their thought into my brain, perhaps adapt it slightly to its new environment. And later I could build upon it. But as a reader, my task was fundamentally to understand the thing (singular) that the author said. And oh, maybe that thing they said had been built-upon later, superseded, whatever… but if so, it would be a fairly simple historical march of continuous improvement towards… uh… I don’t know. Betterness!

Now, as a junior scholar… I’m still working hard, but I’m now trying to get glimpses of what the text could mean. To whom, and how, and why… and where, and how it could mean different things, and which meanings I wanted to pull out and relate to, and how things I did and said and wrote could open different possibilities for what the text could mean. Writing is part of reading. Discussing is part of reading. Breaking from the page in frustrated exhaustion, slumping into a friend’s couch, and having a random thought strike me differently while staring at their bookshelf over dinner… also part of reading.

This is not a finite task; this is not a task that I can do in the sense of completing it and being-done — but it is a practice that I can engage in, and it is a practice that mandates socialization. In my engineering-model of reading, reading-with-others was a means to sometimes get to the same end point (understanding the author) faster, but if I were smart enough and had enough time, I could do exactly the same thing alone. In my current junior-scholar-model of reading, reading-with-others is fundamentally different from reading alone. My interactions with others become part of the text we work with (yes, yes, you can make jokes about this); any “end points” I come up with are decisions I’ve made (I will stop because we’re going to submit this paper; we will stop when the semester ends etc.) — and they’re less periods than semicolons, pauses that can be picked up again at any time in the future, whether we do or not.

The article that spurred these thoughts seems to speak to the latter kind of reading, seems to assume that — well, yes, that is the kind you’re doing. But for some fields, that’s not how scholarly reading works. That’s not our practice. Maybe for good reasons, too (if the end goal is “make the device run, NOW,” you may not need to exhume the racial context of the time period during which the documentation was written in order to accomplish it). To someone with a different disciplinary practice of reading, this article feels really, really weird. And I’ve had to learn my way into it, and I will constantly be learning my way into it — I’m old enough now that new things I encounter will never become my “native” ways of being; even if the new ways become more dominant, I’ll always have had a practice (or absence thereof) for that thing before.

And the people I will teach and mentor into scholarly reading will, by and large, also be non-natives — just because of age and experience, since I teach college students, faculty… not tiny ones. And so I will be conscious of that, when I teach people how to read, and as I keep on working on my own practice. I’m not from here; I can’t assume I know; don’t get complacent, stay awake.