A (not so) Quick Reflection on QWER Hacks

(oops, this is a bit of a late post).

Last month, I had the pleasure of running two workshops at QWER Hacks: An Introduction to Web Development with React and Firebase, and Hacking for Social Impact: EdTech. I want to spend a bit of time to just word vomit my thoughts on the event, lessons I learned from the workshop, and blab about something that frustrates me quite a bit: that it’s “weird” that I volunteered at QWER Hacks.

matt this is too long please make this shorter

disclaimer: I think the Some Thoughts on being an ‘Ally’ is probably the most interesting and accessible part of this post. still, if you have the time, I think you should read it all :)

1. Hackathons & Why QWER Hacks
2. Workshop 1: Intro to Web Development with React and Firebase
3. Workshop 2: Hacking for Social Impact: EdTech
4. Some Thoughts on being an ‘Ally’

Hackathons & Why QWER Hacks

Before I talk to you about QWER Hacks, let’s first get a bit more context on what hackathons are. I promise, it’s not just the dictionary definition.

A Brief History of Hackathons

First, some context. What is QWER Hacks?

It’s a hackathon, an event where computer-y people (not necessarily computer science students) come together to make something in a short period of time. Usually, people make apps, websites, scripts, hardware (e.g. a robot, a smart bike lock, or a pillow that shakes you awake), or really anything else that somehow involves making something.

Hackathons have been around for quite some time (supposedly since 1999), but they’ve recently grown in popularity: big ones like PennApps, Hack the North, and UCLA’s own LA Hacks draw thousands of high school and college students together to create something awesome. At large hackathons, you’ll see a range of corporate sponsors from the Facebooks and the Googles, from the Red Bulls to the Soylents, and even from the CIA to the NHS.

As larger hackathons become more far-reaching and generalized, specialized hackathons have popped up too. These hackathons tend to specialize in two ways: theme, and audience.

Let’s start with theme. DementiaHack is one well-known series: it’s a hackathon focused particularly on helping dementia patients and caregivers, with events held in Toronto and [London] sponsored by Facebook and the Canadian/UK governments. EarthXHack (previously called HackEarth) held in Dallas is one of America’s biggest environment-focused hackathons. And, some of my friends held an amazing hackathon last year called Citizen Hacks centred on digital privacy (you should definitely attend next year if you can)! Of course, this list isn’t exhaustive; every year, more and more hackathons pop up, trying to solve problems that are maybe too niche for big tech/industry to handle.

Then, there’s audience diversity. Like most fields, computer science and software engineering can be pretty unwelcoming to visible (and invisible) minorities. The most prominent is probably sexism: if you’ve kept up with the news, you’ve probably read about Google’s internal diversity memo debacle, heard of Sheryl Sandberg’s Lean In, or read the hundreds of articles on sexism in tech. And, it goes without saying, tech has its fair share of racism, homophobia, transphobia, classism, and sexual misconduct.

As an aside, I think there is no debate on whether or not this is a problem in tech. It clearly is. But more on that another time.

Back on topic. Hackathons can be scary too! Think about how alienating it is to go to a stadium filled with “the best hackers in the country”, and to see nobody who looks like you, or shares the same experience as you. In response, a plethora of diversity-focused hackathons have sprung up to create welcoming communities: AthenaHacks at USC, Pearl Hacks at UNC, and SheHacks at the University of Western Ontario are three of the many hackathons focused on women and non-binary individuals.

I think this is where there can (and should) be a debate: how effective are these hackathons at promoting diversity in tech?

In my personal (and admittedly uninformed) opinion, I think these events are great: I’ve anecdotally seen them attract people to hackathons who otherwise wouldn’t have come, develop their technical skills, and network with hackers and mentors that they otherwise wouldn’t have met. However, I acknowledge that I have a pretty limited view of what’s happening, and I’d love to get hard data on the impact of these kinds of events. For now though, let’s get back on track.

QWER Hacks.

QWER Hacks: A First

QWER Hacks is a brand-new hackathon at UCLA specifically themed around the LGBTQIA community. It aims to specialize in two ways: in both product theme, with prizes focused on LGBTQIA education and health, and in audience, by bringing in keynote speakers, workshop leaders, and mentors with a focus on the LGBTQIA community.

To my knowledge, QWER Hacks is the first LGBTQIA college hackathon (it’s definitely MLH’s first one, and I don’t think HackOut is a tech-focused hackathon). To me, this was a surprise. I guess I’ve never been on the lookout for it, but I had always assumed that there were plenty in Toronto and California. If anything, that’s emblematic of the problem: very few people talk about homophobia or transphobia in tech, even though it’s extremely prevalent.

So, when my friends running QWER Hacks asked me to help out by running a workshop, I jumped at the opportunity! Even though I’m not a member of the LGBTQ community, I think it’s a great cause, and it’s a group starved of resources in tech. Plus, I love teaching and spreading knowledge: if I can teach a few people about web development, I have no doubt that they’ll have a larger impact than any singular thing I can code.

So, what did I do? I was asked to do two workshops: a technical one on web development with React and Firebase, and a case-study analysis of education technology (dubbed EdTech).

I’ll talk about how the workshops themselves were in a bit. First though, I want to spend a bit of time talking about the event itself.

Some Reflections on the Event

The hardest part of planning large recurring events is always planning the first one. You need to do lots of initial legwork to set everything up: find a date that’s not too busy, secure funding for an event that has never happened before, convince sponsors and volunteers that lots of people will come, and most importantly, convince attendees that they should come to this event that has never happened before.

I’m happy to report that I think the organizers did a great job. There was solid turnout from hackers; almost every table at the venue (Ackerman Grand Ballroom) was occupied! They were able to secure a partnership with MLH, and got corporate sponsors like Facebook, Google, Microsoft, Oracle, and Activision/Blizzard! And, they had a solid roster of workshops (though I might be a bit biased there).

I also had an opportunity to talk to some of the hackers at the event, and I was pleasantly surprised by the number of people who said that it was their first hackathon. I think that’s where the impact of this event is truly realizable. QWER Hacks was able to get a few more people into the scary and intimidating world of big tech, networking with Facebook engineers and learning about machine learning along the way. The tech world often talks about making the community more diverse, and being more inclusive - this is clearly a right step in that direction.

Another plus was the focus on being queer in tech. As I mentioned earlier, I think there are very few opportunities for people to learn about the queer experience in tech (regardless of their gender or sexuality). Their opening speaker, Luca Soldaini (a PhD @ Amazon), discussed the under-representation of LGBTQIA scientists and its implications. The Trevor Project, a large non-profit dedicated to suicide prevention among LGBTQIA youth, was a hackathon partner - and they had presentations + resources about the unique problems that queer teenagers face. And, not to mention, that there were lots of queer hackers - each with perspectives and experiences to share. I personally haven’t seen a tech event with this kind of environment in the US, and I’m sure it was as impactful as it was different.

As a footnote, I don’t think the impact of QWER Hacks is solely for LGBTQ hackers. Not all the hackers there were queer; some were new to CS, and wanted a lower-commitment/less-competitive space to get started. Compared to other UCLA hackathons like LA Hacks (which is a huge event, something that can definitely be intimidating) or IDEA Hacks (which is a hardware hackathon, a great idea but also scary), QWER Hacks is also uniquely more casual (e.g. it’s 24 hours instead of 36). Even if you don’t believe that QWER Hacks helps queer hackers, there is still a solid argument that QWER Hacks serves a unique community at UCLA, and it deserves your attention.

In sum, I think QWER Hacks was a great event: a great idea, solid execution, and meaningful impact. I hope that it continues on next year, and the year after that, and… well, until we don’t need it anymore. I don’t see that coming anytime soon.

And now, let’s get a bit narcissistic: let’s talk about myself.

Workshop 1: Intro to Web Development with React and Firebase

I’m going to be quite honest with you, I’m a bit sick of typing about React and Firebase after running this workshop. In particular, it’s because I typed out 14000+ words for the README of the workshop repo. I’ll give a quick flyover on what I talked about, but I’m more interested in discussing what could’ve gone better.

(if you don’t know what React or Firebase are, this next bit is going to not make much sense. maybe you should… read the brief for the workshop to learn more 👀)

Structure of the Workshop

I was given one and a half hours to run the workshop. I could assume that people had previous programming experience (e.g. variables, functions, sequential programming), but didn’t have experience with HTML, CSS, JS, React, Node, databases, or Firebase/Firestore. They should get something out of the workshop; I elected to make the project an online chatroom.

Admittedly, I had already painted myself into a corner with these restrictions. Still, I had ambitious goals. I wanted to teach people how to make a full front-end hackathon app with React and Firebase (or really, Firestore), going over the most important concepts for each industry buzzword. And, I wanted to do it well: to not gloss over the core tenets of React that make it so popular, or the ideas behind Firestore that make it insanely convenient.

But, uh, I ran into some problems.

Planning & Writing

I spent a lot of time planning this workshop. Over the winter break (and a bit of winter quarter), I wrote up the script for this workshop on GitHub.

This thing is huge. It’s 14603 words, or 56 pages in 10pt font.

And to be honest, it’s way too long. I wanted to put everything in this README. I resolved myself to not doing that, since it’d be overwhelming (the opposite of the point of this workshop). And to some extent, I did - I tabled the discussion on component lifecycle, or delving deep into this in Javascript, or Firestore’s event listeners.

But come on. It’s 56 fucking pages. That’s way too long for an intro workshop.

This alone should’ve been a red flag for me: what I want to cover would take way too long, given that the script is too long. I told myself that I’d just skip some in-depth explanations during the presentation and tell the participants to refer to the README; surely, I’d still make the hour and a half time limit. Right?

Running the Actual Workshop

Oh, how I was wrong. I think I maybe could’ve speedrunned through the entire workshop in an hour and a half, assuming everything went perfectly. But obviously, it didn’t.

The first thing I didn’t foresee was, well, how many people would come to the workshop. It was actually quite a packed room - easily with 30+ people in it - which is great, but also posed a logistical problem. To run the workshop, I had me (the presenter) + one awesome helper (thank you so much Jamie!!!). Unfortunately, that’s a ratio of 15:1, and only if I stop presenting to help people troubleshoot things. For a workshop geared towards beginners with little web dev experience, we really should’ve gotten more mentors: a ratio of 5:1 or lower would’ve been good.

Then, I just forgot about how long environment setup might take. I asked people download Node beforehand, but some people ran into trouble: they had old OSs, or didn’t know what version to download, or they just forgot. And, there’s a pretty annoying problem with Node on Windows Subsystem for Linux where spaces in the file directory (e.g. C:\Users\Matthew Wang) causes problems with Node’s runtime, which is extremely tough to fix (though it is doable with some creative symlinking)! This easily cut 10 or 15 minutes into the workshop, which was time I couldn’t afford to give up.

And then, there’s the meat of the workshop: live-coding the React and Firebase code. I expected this to be the bottleneck of the workshop, but most of the coding actually went pretty fine! I did know the workshop material like the back of my hand, so there weren’t any problems with typing out the code/demoing the workshop project.

The problem was, mostly, me. I didn’t stay true to my “I’ll brush over most things” attitude about presenting: I made sure that everyone understood all of the workshop material, and vigorously answered any questions. I think this was mostly the right approach to take about the entire ordeal, but it absolutely killed my timing. By the hour and a half mark, we hadn’t implemented a single line of Firestore code into the app. So in essence, I had just taught a React workshop.

Oops.

Post-Workshop

After furiously apologizing to all the workshop attendees, I (somewhat naively) promised them that reading the workshop + asking mentors could get them up to speed. To my surprise, quite a few people actually did finish up the workshop! But most of them left somewhat confused, and probably scratched their heads over the README. Can’t blame them.

I mentored for a bit after the workshop too, looking to help as many of the attendees as possible. I was pleasantly surprised by how many people retained most of the React content that I covered, and I was glad to help them figure out Firestore. It seemed like most of the projects at QWER Hacks were web applications of some sort, so I helped a lot of groups architect out their tech stack for their app (which is something that I quite enjoy doing).

Something that some attendees ended up doing was forking the tutorial repository and modifying it to fit their hack. In hindsight, this is actually a pretty smart thing to do, and I should’ve explicitly mentioned this in the workshop/included instructions in the README to do so. I was told that quite a few projects had the repo’s code, which is mostly reassuring to hear!

Retrospect

I am kind of happy of how the workshop went; it got lots of positive feedback, and it was educational. But, there’s a lot of room for improvement.

The biggest reflection that I have is that the workshop was too ambitious. It probably should’ve been two separate workshops (Intro to React, Intro to Firebase/Firestore), with each workshop being at least an hour. I’m debating if I should’ve given them starter code; I dislike this because then the attendees usually don’t know what the starter code does. I definitely could’ve implemented less React features, leaving code stubs or areas of “homework”/TODOs for attendees to finish.

The second biggest reflection is that I word vomit way too much in writing. This blog is the absolute pinnacle of that bad writing habit, but it bled directly into the README. Part of it is I am often too ambitious of a writer - I never want to leave a path unexplored - but another part of it is that I’m just not concise. Combine that with the mish-mash of complex sentence structures that I use (just look at this paragraph), and you’ll get a large blob of text that’s pretty unreadable. Next time, I need to write a significantly more concise explanation: one that’s really accessible and easy to understand, not an intimidating wall of text.

I’m also curious on the efficacy of code-on-screen-and-follow workshops as a whole. My workshop wasn’t particularly interactive: participants just watched me code something and then listened to me explain it for a few minutes. I usually prefer to include some sort of Q&A (e.g. “now what code would we write here?” or “what type is this variable”), but I couldn’t fit that in. I wonder if shrinking the scope of the workshop (e.g. didn’t cover component lifecycles) to make it more interactive would create a more effective learning experience.

And of course, the other things that I mentioned earlier: more helpers, budgeting for installation troubles, and including basic troubleshooting in the README.

Teaching well is something that I’m extremely passionate about, and I’m glad I had this experience to reflect on. Teaching web development is especially tricky because I personally believe that a lot of people learn/teach it wrong (a conversation for another day). Hopefully, the next time I teach a workshop (which might just be this one!), I take heed of these lessons, and make it even better.

Workshop 2: Hacking for Social Impact: EdTech

This one will be a bit shorter, I promise.

I also did one more workshop for QWER Hacks, about EdTech (slides here)!

Compared to the web dev workshop, this is one that’s much less technical, and more focused on ideation/awareness. You can think of them as mini-TED talks, focused on a specific field of development.

Why?

I chose to talk about EdTech, which is loosely defined as the intersection between technology and education to make learning even better. It’s a field that I’m particularly passionate about, not only because I love teaching but also because I see education as one of the fundamental (if not the fundamental) drivers for opportunity. I’m lucky enough to do work in EdTech right now, as part of the Teach LA dev team!

I’ll spare you the rest of the explicit details (which you can see in the slides if you want), but I do honestly think that people underrate EdTech. Things like KhanAcademy, Scratch, or Piazza are widely impactful and have significantly changed how education already works. I think there’s an insane amount of potential to use technology to make education (and its institutions) even better. There are a few reasons why we haven’t: education is slow to adopt new tech; it isn’t lucrative; it’s really, really, hard. But someone should be doing it. Hopefully, that might be you!

Running & Retrospect

Oops, I did end up talking about some of the explicit details! But onto the actual running of the workshop.

Turnout was small. We had about 10 people, small enough that I can be a bit more conversational in the presentation style (which is exactly what I did). We had a solid discussion about personal experiences being students, the institutions surrounding us, and what we might be able to do. It was later in to the night, and there were other workshops running concurrently, but I think it was a modest success.

In terms of retrospect, not much. I think in the future, I’d drop a bit of the scripted content and focus more on the group conversations, especially if the audience is small enough to be conversational. But other than that, I’m pretty content with how things went.

Okay, onto the real spicy stuff.

Some Thoughts on being an ‘Ally’

Right off of the bat, I want to clarify: I am not a member of the LGBTQ community. I am a straight, cisgender man.

This usually surprises lots of people, in a few ways. Supposedly, a lot of it has to do with my love of facemasks and Carly Rae Jepsen (both of which are things you should enjoy regardless of your gender or sexual orientation); that’s maybe a conversation for another day. But, I think the thing that bothers me more is that people then ask why - if you’re straight, then why are you volunteering at an event for LGTBTQ people?

an aside on emotional capital and empathy

I understand where people are coming from. We all have limited bandwidth to care about things (I like the phrase emotional capital here), and it makes lots of sense to care about things that directly affect you; you’re probably also better equipped to deal with these problems, since you have first-hand experience and likely a passion to solve them. In other words, sympathy is easier than empathy - and I’d say that people are usually less empathetic on a broad level (to no fault of their own).

This gets compounded by two things. The first is information overload: with the rise of the internet and social media, it’s never been easier to see all of these things that you have to care about. Mind you, I don’t think there’s actually more things - human history has been pretty bad for quite some time - but now it’s omnipresent. So, your emotional capital is spread thin.

To some extent, this numbs people from new issues. There’s another war in the Middle East? There’s another genocide? There’s another case of police brutality? There’s another school shooting? There’s another authoritarian government? I don’t mean to trivialize any of these individual incidents, but at some point it just becomes hard to keep up. It reminds me of an often-paraphrased quote: “one death is a tragedy, but a thousand is a statistic”.

The second is just how hard it is to effect social change. Actively making meaningful impacts for LGBTQ rights, or to stop voter suppression, or to support victims of famine is hard. Usually it involves going somewhere, talking to lots of people, and failure. It’s usually much easier to donate to a charity, or repost a story on Instagram, or change your Facebook profile picture. I’d argue that these kinds of actions drift you farther from actually engaging with these issues: because the buy-in you need to repost an Instagram story is so low, you don’t need to research the issue or grapple with its victims; you just press a button. In other words, you spend your emotional capital with breadth, rather than depth.

At the end of the day, my point is that people have little emotional capital available, rarely spend that on purely empathetic causes, and when they do, it’s often at a somewhat shallow level.

I know that sounds harsh. It’s not really anybody’s fault per se, but it’s an unfortunate reality that means that minority groups get very little outsider support. And, this paints everybody as mostly benevolent people - I haven’t even touched on people who actually act against social change.

At the same time, I don’t think you have an obligation to be informed on every social cause, or to support every movement that asks you for it.

caring and support

Right, so why do I care about the LGBTQ community, even though I’m not in it. There are a few shallow answers: I have gay, lesbian, bi, and trans friends; it’s an “obviously” good cause; it’s 2020; that’s what I should do.

Fundamentally, I think LGBTQ people are people too. I do not think your sexual orientation, gender identity, or any other immutable characteristic of who you are as a person should affect how we treat you as a society. This is the same reason that I’m an ardent feminist, even though I’m not a woman (which is something I also get lots of flak for). This is why I’m, to put it lightly, not a fan of racism, even if I personally rarely experience it.

Hopefully, that wasn’t controversial.

I would like to think that most people agree with this sentiment, at least to some respect. Lots of the disagreements that people have on these types of topics are rooted in what it means to treat people equally; the common framing of this debate is “equality versus equity”. I don’t want to get into this too much in this post, because that’s not really the core issue with my allyship gripe.

I think the core of the issue is the difference between passive and active support, and how we perceive it. It’s one thing to say “sexism is bad”, but it’s another thing to go to a women’s march. The former doesn’t garner a standing ovation (and it probably shouldn’t, though that depends on where you are in the world): it’s a good thing to say, but also it’s a pretty risk-free statement (again, depends on where you are in the world). It’s emotional capital light. The latter is still… pretty risk-free, but it requires a more active participation, a commitment to go to something. It requires more emotional capital.

And here’s the the thing. We’ve got so little emotional capital (the world around us sucks), so we’ve got to spend it effectively. We spend it on the things that affect us in our everyday lives. The natural extension is that we think everybody else behaves in the same way: they’re only willing to spend emotional capital on something that directly impacts them.

This is why “my friend is gay” or “I have a daughter” or “my grandparents” are common justifications for why people advocate for groups that they’re not a part of. They communicate why the person is willing to spend their emotional capital: the cause is close to them.

the resulting impact/culture

Now, that last bit is pretty obvious. But I think the impact of this is less so. I’d wager that most people view social justice with the “close-to-you” attitude that I mentioned above. What this does is make it strange for someone to advocate for a group that they’re not a part of. It dissuades allies from standing up.

This is problematic. To make widespread social change, you need the buy-in of everyone (or almost everyone) to make an impact. If the public views gay rights as something that only impacts gay people, and therefore something that only gay people care about, then society will never make true progress.

The classical historical example here is moderate white voters during the Civil Rights Era. Mind you, I’m definitely not an expert in this field, but it’s a general consensus that one of the reasons why MLK, Rosa Parks, and the concept of civil disobedience were so effective was because they swayed moderates in the south to vote for racial equality. And it’s a tale repeated across history, and one still being repeated today.

But furthermore, the attitude of “you support queer rights? it’s because you’re gay, right” trivializes queer rights. It says that it’s a cause worth fighting for only if you’re queer - that it’s not a fight for universal human rights, or social justice as a whole, but just this one, isolated thing. And, in some senses, it insinuates that if you’re not queer, you shouldn’t care about queer rights. It’s insulting to queer people, it’s discouraging for allies, and worst of all, it’s self-perpetuating.

So, what’s the actionable item out of this very long post? It’s two things. More broadly, I hope that more people are willing to stand up for social justice as a whole, even if it’s for a group that they’re not a part of/not related to. But more narrowly, we need to normalize a culture of allies. It shouldn’t be strange that someone who’s not gay is supporting a LGBTQIA hackathon. It shouldn’t be strange that a man is at a woman’s march. It shouldn’t be strange that an American supports human rights abroad.

Though that last example leads itself to another perspective to look at this. We’re all human. Even if you’re not gay, you share a sense of common humanity with queer people all over the world. Shouldn’t that be enough?

the end

QWER Hacks was great, it should happen again! I am too ambitious in teaching web development and am not good at writing concisely! I like EdTech! And not all people who champion LGBTQIA rights are queer!

Truthfully, I hope this was a not-terrible read. It took me a long time, and it’s very unstructured. The point is kind of obvious, but it also deserves being written out into words.

And I promise, I’ll work on less word vomit. On the next post.