On the Arbitrariness of Swear Words

The setting: my third grade classroom.
Our teacher was walking around the room slowly, armed with a pile of freshly graded quizzes. She came to my desk and laid down my quiz - face down, of course, so that I'd have the chance to review my grade before casually laying it face-up for bypassers to "ooh" and "aah." I turned over the quiz expecting an A, like the cocky 3rd grader I was, and lo and behold, I discovered a "B+" written in vicious red.
I was appalled at myself. Sure, I had the occasional A-, I was fine with that, but I was an A student, not a B student. How'd I let this happen?
"DAMN IT!", I yelled, in my frustration, at nobody in particular, at myself more than anyone. At least that relieved a little bit of my tension.
Our teacher whipped around, raised her finger in the direction of the door, and issued a stern "Wait for me outside."
What? What was this? Was she also as disappointed in my grade as I was? Is this what happens to all B+ students?
I was perplexed. I really had no idea why she'd sent me outside. You, as an astute reader well versed in the ways of the Western world, you likely figured it out. But I, the unaware third grader, just feeling my way in the world, I just couldn't figure it out.
She finally came outside, and I prepared for an explanation that would clear up everything.
"We don't use that word in the classroom!"
"What word??"
"That word that you yelled."
"Why not?"
"It's a swear word!"
"What's a swear word?"
Suffice to say, she was not very happy with me at this point. I was generally a good, obedient student, and suddenly, I was challenging her at every turn.
But I was just being honest. I didn't know that there were words called "swear words", that there was such a thing as "swearing."
You see, my parents were scientists - British scientists, to be specific - and they never got in their heads to teach us the basics of American manners. Thinking back, I can remember only two times that my dad scolded me for the words I used:

• When I called my sister a "bitch", loud enough that the whole house could hear. He didn't care whether "bitch" was designated as a swear word, he just cared that I was saying a rather mean thing. That was fair. (Though she probably did something unforgivable like steal my candy).
• When I answered questions with "yeah." He said that was "unfinished" and "non-committal" and every answer I gave should end in a real sound, like "yes" or even "yep". Yeah...so that lesson never stuck, though I did say "yesh" as my standard reply for a long time, to get around it while still avoiding conformance to boring old "yes". I was such a rebel, aye?

At this point, I'd started to wrap my head around the idea that there was an arbitrary set of words designated as "swear words", but what was in that set? How would I know to avoid them if I didn't know what they were? I could try to ask my parents, but they might just muddle my mind with their British-isms instead. My teacher was not forthcoming with them, but thankfully, my peers were happy to supply a list. And what an expressive list it was!
From then on, I knew not to scream profanities in front of teachers, but I also always had a sense with me or the arbitrariness of swear words. I could never quite take someone seriously when they put effort into scolding about swear words, because I never quite believed there was anything inherently detestable about them. These days, I try not to *over*-use them, but I definitely use them. I use them to get out my frustrations, to express to others the magnitude of my emotions around something, to add impact to a message.
As a linguistic aside: swear words serve a unique function in the English language - "fucking" (or if you're British, "bloody") is one of the only examples of a linguistic phenomenon called "infixation". It means we can infix it in words, like "abso-fucking-lutely", and our brains parse that as perfect English, and there are specific rules that dictate what syllables can be infixed. I know this because we covered it *twice* in the course of my linguistics minor, though my second professor was so reserved that she couldn't bring herself to use the American example. It amused me to see that even a linguist could feel bound by societal rules to not swear.
There's a part of me that wonders if we enforce "no swearing" with kids and in formal settings purely so that we can further enhance the effect of swear words when we use them ourselves. If we never hushed a kid yelling "damn", would we get as much satisfaction from yelling it ourselves? I don't know, but I bet there are linguists and neuroscientists out there that have done all sorts of interesting research on how swear words form, how they change over time, and what effects they have on the brain. (If I wasn't writing this on the train, I would look it up myself, but I will instead leave it as an exercise to the reader).
Back to practical matters: now that I'm working on the programming curriculum for Khan Academy and teaching kids in person, I need to make sure that my lessons and comments are all kid friendly, mother approved. I have no desire to spark a debate with an angry parent on the exposure of kids to swear words, as I don't want to distract from the point: learning programming.
That means that I find myself trying to swear less, or find substitutes for swear words that are just as satisfying and effective. I've already found a few from the community, like the oh-so-visual "Oh My Fried Chicken!", but I have yet to incorporate them into my every day speech. I have to re-train myself to avoid the words that come reflexively to me, the words that are used so heavily by the adults around me, the words that feel so damn good to say. That seems... hard.
But garsh darn it, I'll give it a go… and check back in 10 years to see what the next generation thinks about swearing.

JSConf 2013: My Favorite Talks

I was fortunate to attend JSConf 2013 this year. I was a speaker in their training track, where I had fun giving a workshop on Backbone. Shout out to HackReactor teachers Marcus and Tony for being my super helpful TAs.

When I wasn't workshopping, I got to enjoy some amazing talks from a wide array of speakers. They're now all available online, so here's a list of my favorites:

• Nicole Sullivan: Creating Living Style Guides: Nicole explained how she worked with Trulia to refactor their CSS, work out performance issues, and create a style guide. You'll come away wanting to have a style guide for your site, if you don't yet. Khan Academy has a basic one here, and even though it doesn't cover everything, it's already helped me to avoid making up new styles.
• Rebecca Murphey: Optimizing for Developer Delight: A talk on engineering team culture, communication, tools, documentation, and best practices. A great one to watch particularly if you're a tech lead or manager.
• Angelina Fabbro: JavaScript Masterclass: A talk that's more about becoming a better developer and approach to learning than about JavaScript itself. I love her philosophy so much.
• Seb Lee-Delisle: CreativeJS - making art in the browser: Seb couldn't attend because of Visa issues, but he made it work over remote video. And yeah, normally you'd think a remote talk at a conference would be horrible, but it was amazing. Since he couldn't hear us for whatever reason, he made us wave his hands to show our applause or laughter or agreement, and that made it more interactive than the in-person talks. And Seb was generally awe-inspiring with his ability to make creative programming look easy.

Technical Interviews Make Me Cry

First, let me clarify one thing for those of you who've never dated me: I cry. A lot.

When I can't get my vagrant box setup correctly after 3 hours? Crying.
When I use an MVC framework for the first time in my life and I'm banging my head against it? Crying.

So, yes, on the spectrum of manly-man-no-emotions to chronic crybaby, I'm very much to the right. Above average, you might say.

Now, back to technical interviews. I've been lucky to have very few in my life, because I'm kind of a love-at-first-sight girl when it comes to jobs. There are very few job descriptions that I've read and fallen in love with, so when I do pursue them, it usually turns out well because it aligns so well with my particular skills and interests.

When I applied to Google, I went through a brief phone screen with an array of short questions (which were easy enough since I was still in the thick of my Computer Science major), a take-home worksheet with fun challenges, and an in-person interview which was mostly me talking about my favorite projects, with a few classic questions that I'd prepared for, like reversing linked lists

When it came to Coursera, I didn't actually apply. I thought I was just going to the office to meet the team and chat about our shared interests. But then they said "well, actually, we'd like for you to join us, and for this to be an interview." I freaked out, because, hey, I had not prepared for an interview — and I hadn't done one since that Google process 5 years before. But, maybe I could use that as an excuse. My first interviewer eased me into it gently and probably because of that, I managed to make it through the rest of them with a smile on my face. I still think they took it easy on me that day, because man, I've seen the interview questions that they gave to candidates that came after me, and I can't see myself making it through those with any degree of confidence.

A few months ago, I decided that I really wanted to join Khan Academy. I would longingly browse their jobs page in my idle hours, read their intern blog posts from top-to-bottom, and fork their repos on Friday nights. It became a bit of an obsession. (Shh, don't tell them how creepy I am.)

The interview process was scheduled to begin as most do: a 40 minute phone screen with one of the engineers. I wasn't sure how to prepare for it, what sort of questions I'd be asked. I figured I'm known for more frontend work these days and folks may be under the misguided illusion that I'm a JS expert, so I read through parts of the ECMAscript spec, reviewed the craziness of prototypal inheritance in JS, and read through all the frontend posts on that engineer's blog. Part of me thought I should study more, study enough that I'd feel confident that I could handle *anything* they threw of me, but that would have taken me months, if that. More likely, I'd never feel 100% confident.

When the time came, I sat there on my bed, on an unusually hot San Francisco day, and dialed into the Skype call. My interviewer started with the usual, asking me about a recent project I'd worked on, and I randomly selected something that was hopefully remotely interesting. Then, we opened a Stypi and he gave me the coding question. I won't say exactly what it was (in case that's his go-to question), but it was basically figuring out how to calculate some bit of data, nothing language specific, more math and logic.

And that's when I froze. I didn't immediately know how to answer the question, and I broke down.

I stared at the wall for minutes. I listened to my interviewer breathing, knowing that he wanted me to start working through the problem, but at that point, I couldn't.

The only thing going through my mind was "I can't do this."

I stared at the "hang up" button on Skype. I could just press it, and he would go away, and then I'd give up on my obsession, and I would convince myself it was a stupid idea in the first place.

I could feel my palms getting sweatier, and then I could feel the tears start to come. And the silence grew more uncomfortable. It'd been minutes since I said anything. I needed to do something, anything.

I finally managed to convince myself that I'd be an idiot for hanging up, and in an act of honesty, I choked out something like, "Um, I'm sorry, I've literally gone blank and not thought about anything for 5 minutes. I'm not used to coding on the phone."

And my interviewer understood. He guided me through it, urging me to keep going, even though I kept wanting to throw in the towel. I wanted him to give up on me, to realize the mistake I'd made in thinking I could meet their bar, to put me out of my misery. At some points, I couldn't type because I could no longer see through the tears that had welled up in my eyes. But eventually, we got to the end of it, and the interview was over.

And then the sobbing REALLY began. I had just finished the first step of the interview process with the company I desperately wanted to work for, and I'd bombed it. I’d frozen, I’d cried, I’d stumbled through my somewhat shoddy solution. Did I really deserve to even be an engineer, if I couldn't even make it through a phone screen? What gives me the rights to give talks at conferences, if I can't make it through standard interview processes? I was pretty damn frustrated with myself.

After a night spent in existential crisis mode, I found out that I'd made it to the next step. Apparently, my solution wasn't that shoddy after all and somehow, I hadn't scared my interviewer off.

It was then that I realized the most important part of prepping for the phone screens: confidence. Even if I didn't really have any, I had to convince myself that I did, and do everything in my power to not mentally run away. By the last phone screen, I was almost having fun.

This story has a happy ending: after three phone screens, a fun take-home assignment that literally had me bouncing off the walls in excitement, and a chat with the team, I was offered the job and have been working there ever since.

What are the take-aways from this?

If you're an interviewee: don't just prepare for the material, prepare for the format. If I had made myself go through the uncommon and uncomfortable situation of being put in the spot and asked to answer a random technical question, maybe I would not have cracked so easily when it came to the real deal. If you ever suffer from Impostor syndrome, you should probably prepare even more, because the standard interview situation will make you feel like an Imposter in the worst way.

If you're an interviewer: seriously consider the format of the on-the-spot technical interview and whether that's the best way to judge all candidates. In my experience, when we are programming on the job, we're given the problem and we have time to think about it. We have time to research possible solutions, we have time to try stuff out that we know will most likely fail, and we can wait until we have something decent before we show it to our colleagues. Oh, and as it turns out, I don't actually cry much at work - maybe a few times a year, when I'm already having a horrible day and I'm struggling against something that just won't work.

That's why I love the format of the take-home assignment. Both times that I've been given one (Google and Khan Academy), I loved them both because I had the time to really sink my teeth into them and because I got to experience what it would be like to work in that role. The take-home assignments were always very similar to actual work projects, so by doing them, I could figure out whether I'd actually be any good at it, and whether I'd like doing it. That's valuable for the interviewer *and* the interviewee. Yes, it’s hard to judge an assignment when you can’t witness its process, but it’s a surmountable task.

Now, I know that not everyone likes take-home assignments - and I know that some engineers absolutely love interviews, or at least prefer them to a take-home. So, I’ll stop here before this post becomes a 10-page exploration of alternative interview practices. Maybe that will be a future post, once I start being an interviewer again. Apparently Khan is keen to keep experimenting with more take-homes. :)

But just take this away then: remember that an on-the-spot interview can be incredibly intimidating and frightening for some people. Try to remember what it can be like to be in their situation. Ease them into it. Be understanding. And forgive them if they cry.