Grief is a hard-wrought thing; it’s always churning around, tugging at emotions already teetering on your inner precipice. And even amidst wonderful things, it has power.
I lost my Dad last year, right before Thanksgiving. Of course, this was on the heels of barreling forward into a world full of earth-shattering, openly accepted violence positioned alongside the election of a man and accompanying administration that built their success upon pathological lies and the myth of American “greatness”. The latter, sadly, wasn’t surprising. Vehement violence, xenophobia & islamophobia (which are, of course, inextricably tied to racism), ableism, transphobia, homophobia, misogyny (& let’s be really real — misogynoir), and the denying of basic human rights is something that the multiply marginalized, that those marked Other, know all too well. We know it with an acridness that has almost become acquired taste. Still, we fight.
So I faded away from social media bit by bit, threw myself into work, and strove to Be Strong™. (Because how often are black women told that we must do this? Be unshakable when peppered with burden?)
But there’s power in narrative — Nicole Cooke’s brilliant “Pushing Back from the Table” reminded me of this; it’s the only article on my desk right now, so marked and circled and highlighted that it’s hard to tell where her thoughts end and my own scribbles begin. So I’m writing this for the black academics who’ve come before, and those who’ll come after — be whatever you must be to survive this. Break down in the restroom when you need to. Lean on folks when you need to. Share your stories with those you trust. Let yourself be human (and remind yourself that it’s okay to feel lost — that these challenges, and your response to them, do not define you.)
“We can talk about badges, for example, we can talk about going to a coding boot camp for an eight-week program. But at the end of the day, do employers value that? Or does an employer still value a degree from a university that they recognize and respect? That’s a question of prestige, and no amount of technological innovation right now really gets at that prestige question.”
[insert ‘yas’ gif somewhere here]
First of all – Y E S. Second of all – let’s drill down into this further:
Raise your hand if you’re tired of hearing discourse that treats technology like an equalizer, a utopian device that levels every playing field. Rarely do these conceptions converge with our understanding of -isms or macro and microaggressions that pervade society.
But this quote gets at the heart of a much needed message: technology, and this notion that we should all attain various tech skills, is still 1000% subject to (and often occurs within) the prestige model of higher education. And, stepping back even further, the idea that we can all attain the same skills, in the same fashion, without barriers, is pretty unbelievable. I understand see the appeal of coding retreats and similar programs, but we can’t have conversations about their necessity without first remembering: the contexts in which these are performed, the systems of prestige and privilege that dominate the landscapes they’re performed in, and the ways in which marginalized students will absolutely be forced to navigate oppressive structures that affect how their abilities read in the classroom or on the job market.
This semester I taught four separate sessions on the Arduino and Raspberry Pi platforms — two aimed at developing skills and two aimed at brainstorming project ideas. I’ll touch on the two that were the most challenging to devise: Raspberry Pi Basics | Python and Pi and Arduino Basics | Sensors and Servos. This isn’t new — plenty of fantastic libraries are actively supporting these technologies, but I’m not sure whether we’re clearly documenting how to teach them. I had trouble finding any resources on best practices for teaching these within the constraints of a one-shot method. So I’m sharing my approach, and what I learned from it, in the hopes that it helps others librarians doing similar work.
Developing Learning Outcomes:
Given the time constraints of the one-shot, I knew I had to prioritize — I could either go for a deep dive into the topic or I could keep it purposefully broad for wider exposure. And more importantly, I wanted every student, faculty, and staff member who attended to feel like they belonged — less jargon and specialized knowledge requirements, more getting your hands dirty no matter your background. So I emphasized broad exposureas a primary learning objective. This meant:
We covered the absolute basics — what a sensor or servo is, what the Ardunio and Raspberry Pi are, and how those add-ons individually connect to them. I like to think of this as the simple exercise model — e.g. lighting up an LED.
Adapting the simple exercise model above for CU’s science community. I focused on picking a sensor that could be used in advanced projects without diving into advanced specifics. (I chose the Ultrasonic Distance Sensor and Continuous Rotation Servo.)
Pros: By emphasizing exposure, I was able to say — this is a no pressure session. If you don’t leave the room understanding every little thing we talked about, it’s okay. The important thing is: now you know this exists. You’ve gotten experience digging through sample code, of setting up one part of a project. You can build upon that when you leave this room (and you also know who to come to if you feel like you can’t). Quick tips:
I used pre-written code snippets; this saved time and allowed attendees to focus on comprehending how the sensors were behaving at a basic level. (Again, with the hope that they might build upon this later.)
Cons: Broad is good, but students still had questions about how these sensors could be used in actual projects (despite providing project examples). I think they had trouble seeing the bigger picture with this method.
Structuring the Session:
The nature of these workshops was all about hands on collaboration. I started by providing a brief (10-15 minute) spiel about what the hardware was, how it worked, what it operated on, and what programming languages it paired best with. Then, I asked everyone to introduce themselves to the people around them — aka, their new group members. For the duration of the session, they worked together on a series of open-ended exercises that I’d devised (with the option to veer off course, depending on their skill level). The only rule was: everybody “drives” at least once; meaning, no one person should do all the work. The open-ended lessons were structured as such:
I got to expose participants to both the hardware and other like-minded individuals; people worked with and learned from one another as the session went on.
Adding on the “challenge” portion of the lesson allowed me to provide attendees with a flexible low-floor, high ceiling experience; it was VERY cool to see people who ditched the sensors and servos entirely to work on programming an LCD to display data recorded from the Arduino.
Cons: The success of this method largely depends on who shows up. You’re taking a gamble that you’ll get a decent mixture of skill levels, but that may not actually work out.
So even though some things went well, these few really didn’t:
Including a coding intro. These were 10 minute overviews of various languages (like Python and Wiring); the idea was to give those who’d never programmed before some common knowledge. However, there just isn’t enough time for this to be effective; folks who already knew it were unenthused, and those who didn’t were hard-pressed to understand anything during my flash-coverage of it.
Showcasing project examples before we got started. Showcasing too many took time away from the hands-on portion. In the future, I’d shorten this to include 2 or 3 really interesting examples, rather than the 10 I used.
Not using a floater. Let me tell you — these hands on sessions can get out of hand real quick if you don’t have all hands on deck. Consider using other tech-savvy staff to help troubleshoot issues.
No info is ever “too basic”. I didn’t think to say — “See how the metal rods connecting this sensor to the Arduino are straight? They’re supposed to stay that way.” But 40 minutes in, after noticing that one group actually bent their sensor to fit a part of the board it wasn’t supposed to, I realized — yep. I should’ve included a “no bending” note. This also means I should’ve covered how to properly slot sensors into the board; leaving up a diagram on the screen that showed how to connect it wasn’t enough. Overall, be as thorough as you can with any and all explanations.
I’m not disillusioned into thinking that this is the only way to teach Pis and Arduinos; I’d love to hear about strategies you’ve tried, or even better tips you have, on doing this. And if I missed some ridiculously awesome “How-To-Teach-Raspberry Pis-And-Arduinos-When-You-Have-NO-IDEA-What-You’re-Doing” handbook that you know of, please send it my way!