Latest Entries »

2011 rundown / 2012 resolutions and plans

Filed Under: Pretty things, Python, SF Bay, Stuff, Tech
Dec.31, 2011

Since others I know have been writing similar posts: a look back, and a look forward.

What I did in 2011:

  • Helped my parents pack up for the move from Minnesota to Portland, OR.
  • Finally figured out how to write a Django app from scratch.
  • Attended PyCon for the first time; presented a poster and met all sorts of cool people.
  • Got down to 171 lbs. Immediately gained most of it back, thanks to surgery + laziness + depression. Managed to re-lose about 7 lbs before the end of the year.
  • Had surgery to remove a benign (but weird) ovarian cyst. That was a drag.
  • Did the badassest 213 (UI design) project ever with Marco, Galen and Alex.
  • Wrote a 203 paper that got linked by lots of people. Led to a column in Full Circle Magazine and a talk at Wikimedia.
  • Vacationed in Sea Ranch / saw the northern California coast.
  • Got my first smartphone. So that’s what this whole mobile nonsense is all about.
  • Had an internship at Code for America through Google Summer of Code. Became friends with all sorts of awesome staff, fellows, and interns there. Switched projects partway through. Met Karl Fogel and Carl Malamud.
  • “Learned” Ruby on Rails. Decided that it and my brain do not get along, and to stick to Python for now, no matter how much that means not being able to work on lots of cool apps :/
  • Did my first 24-hour hackathon.
  • Visited Boston and actually enjoyed it for the first time.
  • Started weight-lifting more seriously.
  • Felt my first earthquake. And my second and third.
  • Dyed my hair red with henna for Halloween. Didn’t realize how permanent it was.
  • OpenHatch made the legal move towards becoming a non-profit, and I got a seat on its board of directors.
  • Houseguest had their stuff stolen, possibly by housemates or their friends. Found a new place to live.
  • Turned 25. Had a lovely birthday party. Can now rent cars without paying extra.

Things I will do in 2012:

  • Move to my new house in Elmwood.
  • Blog more — let’s say at least one (short) post every week. I’d get in on the #acetarium Iron Blogger thing, but I’m on the wrong coast to buy the other participants drinks when I don’t make the deadline…
  • Give a talk at PyCon. Heckle people at TiP. Take at least one tutorial, preferably more. Participate in the sprints. Hopefully not make an ass of myself.
  • Try out Debian.
  • Actually learn bash and various other UNIX sysadminny stuff.
  • Work on and finish my final project, and present something impressive in the end.
  • Graduate from my master’s program.
  • Find a job that I love and that involves at least some coding.
  • Read more (non-class-related) books.
  • Re-do my personal website and portfolio.
  • Be more social / make more, closer friends.
  • Go sightseeing/traveling in California — Tahoe, Big Sur, wine country…
  • Get back into rock climbing, at least enough that I can do V2s again.
  • Keep weightlifting, and figure out all those scary barbell-using lifts. If I lose weight, great; if I just get more badass, awesome.
  • Be more deliberate/picky about the projects I tackle. Focus is valuable, and work, school, and volunteering already divide it a lot. I hate half-assing things, so I should be better prepared to say no.
  • At the same time, though, preserving time for my own vanity projects is also a goal.
  • Tackle more computationally-interesting programming problems, instead of just pure CRUD web apps.
  • Do more with JavaScript; learn more JS libraries and frameworks. I might not like JS, but it’s not going away and at least it does cool things.
  • Use SASS or Less for at least one project.
  • Learn about lambdas, map/reduce, and the other parts of Python I never use. Be less of a n00b.
  • Stay as sane and happy as can be managed.
Comments »

Technical recruiting is broken.

Filed Under: Entrepreneurship, Rants, SF Bay, Tech
Oct.10, 2011

Sigh.

Three weeks ago, I went to a UC Berkeley career fair and dropped off a copy of my resume with a certain startup. I’d put a lot of effort into selling myself with this particular resume, and trying to stand out from the crowd (most of the attendees were undergraduate CS majors–most probably with better technical chops, but little to no real-world experience, sense of design, or communication skills). While I was at the fair, I had a nice chat with the startup guy there about the company and web development and Python and I figured I had a pretty good shot.

Payoff! The next day, I received this email (a few bits redacted):

Hi Karen,

Our engineers really enjoyed meeting you at the career fair yesterday! (Also, I have to say that I love the graphics on your resume, and the “But wait! There’s more!” :))

You definitely stood out from the crowd as one of the most talented engineering students and we think that you would be a fantastic contribution to the future of (Startup).

I would like to schedule you for a 45-minute Skype interview with an engineer next week. What is your availability Monday, 9/26 through Friday, 9/30 from 10:00am – 5:00pm PST? What is your Skype user name?

I will forward your availability to our recruiting coordinators, (John) and (Jessie), as soon as I hear back from you and you will hear from one of then them shortly after confirming the date & time for the interivew.

If you have any questions regarding the interview process or (Startup) work life, please feel free to contact me at (Jane)@(Startup).com.

I look forward to following up with you ASAP after your Skype interview next week!

Thanks & have a great interview!

(Jane Smith)
(Startup) Technical Recruiter

“One of the most talented engineering students”. What. I suspected that they were just mistaking pretty-and-organized for competency, but even so, my ego was fit to burst. Huzzah! Maybe I could get a job I’d actually enjoy, with a cool company, that could pay me enough money to pay back my student loans! I was super excited.

But then I actually had the Skype interview. Despite the fact that I was applying to do front-end web development work, my interview was with a backend engineer. And instead of talking about the web projects I’d worked on in the past, or anything relevant or interesting, I got grilled with the so-standard-it’s-frickin’-trite Computer Science questionnaire.

Things I was asked about that have little or nothing to do with being an actual web developer:

  • Red-black trees.
  • Multithreaded processing in CPUs.
  • Different types of sort functions. (I was like “I sort of remember learning about that stuff seven years ago, but I program in Python. I just use the sort() method and assume Python knows what it’s doing.”)
  • Lots of Big O questions.
  • The difference between a linked list and an array.
  • SQL queries. (Well, that could be relevant, but I’ve always used Django or another ORM so I don’t really know any raw database stuff.)

One of the questions seriously started with “In a language such as C++ or Java, how would you…?”. If you read my resume, or know anything about me, you know I don’t *do* Java. (Well, I did some Java when I took a couple CS courses in college, and hated it, and notably chose not to major in the subject. But that was seven years ago.) I do *Python*. (And HTML/CSS/JS/RoR/BBQ.) Which I mentioned, and then answered the question Pythonically.

It wasn’t that I couldn’t answer the questions. It happens to be the case that I *have* taken a couple traditional CS courses, so most of them I could at least fudge by on what I remembered from seven years ago and from INFO 206 last year. But answer or no, none of it had anything to do with the actual, real web apps I’ve coded and contributed to over the last two years, and yet it was the standard by which I was judged.

I emailed back the startup today to ask what my status was. Five minutes later I got a rejection email. In that phone interview, I went from “A fantastic contribution to the future of (Startup)” to useless reject in forty minutes flat. Because I don’t remember hardly anything about bubble sort or merge sort and frankly don’t give a rat’s ass.

So now I don’t even know whether or not to bother applying for other web developer jobs. I’ve seen this perfunctory pop quiz on CS canon before–I got another version of it when I interviewed with Google and another (stealth) startup last year. It’s likely that *anywhere* I apply, I’m going to be subject to that test, and more importantly, companies will judge my ability to do the job based on it. Not on, say, my documented open source software contributions or web app projects for class or PyCon speaking or experience teaching Python and web programming to newcomers. That would be silly.

Maybe I should just discount all my technical experience and re-enter the job market as some “UX/interaction designer” / “web designer” / “product manager” weenie. Then it’d be easier for companies to classify me. (And also pay me ~$20k less to do nearly the same damn job.)

I am a *programmer*. I am not a fucking computer scientist. It’s utterly disheartening how many Bay Area tech companies can’t tell the difference.

If you believe that there’s a shortage of programmers and other technical workers right now, consider to what degree your recruiting process assumes that the “best” applicants fit the stereotype of a dorky computer science major who’s been coding since he was 10 and solves Rubik’s Cubes for fun and thinks that job ads calling for “rockstars” and “ninjas” aren’t utterly puerile and inane. (And let’s not even get into how age, race, gender, and culture stereotypes feed into this.)

Comments »

Something I’ve been up to

Filed Under: Pretty things, Rants, Stuff, Tech
Jul.23, 2011

Well, there’s many things that fit that descriptor lately. I’ve been busy! (And not blogging about hardly any of it; oops.)

Anyway, one of those things is a new FOSS-ish project I started called “ponyjoist“! It’s a Python script (soon-to-be a real Django app, so it can be run like other management commands) to make Django more Rails-like.

First, a wee bit of background: I’ve been sort-of learning Ruby on Rails trial-by-fire style at my internship this summer. I had thought I would be working on a Django-based project, but I got moved to a different project early on. Not only is my main project at work Rails-based–my side projects are Rails too! Which is hardly the end of the world–I see the appeal of Rails, and it’s always good to learn new tools. But it’s frustrating to feel coding-illiterate all over again–to know what I want to happen but not how to tell the computer to do what I want. Especially given deadline pressure. And there are a number of little things about Rails I keep running into that rub me the wrong way, things I feel Django does more sensically.

Python and Django are my first loves, my native digital tongue. Of the languages I’ve encountered, Python makes the most sense to me (mostly). I didn’t like feeling like I’d abandoned it.

But there are two main things that I like about Ruby on Rails that Python/Django don’t have.

1.) list.first / list.last notation. Sure, you can write list[0] or list[-1] in Python and get the same effect. I don’t care. I find .first and .last elegant, and wouldn’t mind adding them onto Python.

2.) The rails scaffold function, which takes a model and auto-creates basic controller and view files that handle that model’s CRUD (create, read, update, delete) functions. Boom! Open your dev server in your web browser and, thanks to a single Rails command, you’ve got freaking model read-write functionality (which you can then edit to make pretty and whatever)! It’s flippin’ magic! It gets rid of so much repetitive busywork! Why doesn’t Django have this??

It’s this second gap that ponyjoist is meant to solve. The script, once I finish it, will take a Django app and a model as arguments, then edit and/or create urls.py, views.py, and template files with basic skeleton CRUD-implementing code for that model. (Hence the name; ‘django-scaffold’ is already taken by an unrelated app, so instead we have the image of a Django pony made up of unfinished wooden studs! There will be an awesome logo eventually, I *promise*.)

So (once I get everything working) your initial app development workflow would then look like this:

1.) startapp appname
2.) Add the app to settings.py.
3.) Install South (see South’s instructions)
4.) Create that app’s first model(s). Let’s say one’s a Person model.
5.) Run syncdb / do migrations / whatever. See: South’s tutorial.
6.) Run ./manage.py scaffold appname Person
7.) Run ./manage.py runserver, go to localhost:8000/appname/person/, and admire your lovely new urls, views, and templates! Look at all that tedious, repetitive work you didn’t have to do!
8.) Continue editing to your life’s content.

I guess this touches on what I feel is one of Django’s biggest weaknesses: even for building the most basic of web applications, it’s painfully incomplete. The official Django tutorial isn’t so much a learning tool as an advertisement–there’s so many basic things that it ignores or glosses over. Like migrations. You wouldn’t believe how frustrated I was, when trying to build my first Django app on my own, to find out that after the first database sync, there was no way I could edit my models successfully with just a vanilla Django install. Django doesn’t have a built-in database migration function (something that Rails does have, incidentally); you have to 1.) know in advance that that’s the case and 2.) have installed a separate migrations app, such as South. There’s no way to take seriously a web framework that won’t let you change your models after the first go; sure, you can get away with it for a silly tutorial, but it’s utterly unrealistic.

The official Django tutorial also leaves out how to implement any sort of user-facing CRUD functionality, instead spending an entire page on the /admin/ interface–which, while not useless, is unlikely to be used much by any Django app that’s not a newspaper or blog. Django 1.3 has such nice handling of static files and auto-generated forms now, yet those aren’t in the tutorial either! If you didn’t already know those features existed, you’d be hard pressed to find them. (My Django book dates to version 1.0, so it doesn’t mention them either. :P)

Finally, on a little more advanced note, there’s the issue of dependency handling. Django does zero of this; you have to use a completely separate app like Buildout to manage dependencies. Whereas Ruby on Rails has rubygems and/or RVM, plus bundler, basically by default. Handling Rails dependencies, in the vast majority of cases, is hilariously simple. (And disgustingly slow, yes, but that’s a different problem.) This encourages reuse of gems among Rails developers (and fulfills Django’s espoused Don’t Repeat Yourself (DRY) philosophy in a much more cosmic sense). The amount of analogous reuse of Python eggs and Django apps is tiny in comparison, as far as I can tell, and I wouldn’t be surprised if the lack of automagic dependency handling contributed to that.

I’m not saying that Rails is better than Django–as I’ve mentioned earlier, I prefer the latter by *far*. But I do think that Django could stand to take some lessons from Rails in order to make it more accessible to designers and beginning developers and just plain faster and easier for anyone to program with. We don’t have to have South or Buildout or ponyjoist (or something else CRUD-focused) built into Django; people like having a choice of tools and that’s perfectly fine. But I want a damn tutorial that takes a good hard look at what real, actual Django web app development involves and actually goes through all the components needed for self-sufficiency (not in complete detail, *obviously*, but you can’t very well look up docs on something you don’t know you need and don’t know exists). And if we can build some little hacks to make a tutorial like that more simple…well, that’s what I’ve been working on the last week. :)

Comments »

On helping [iPhone owners] change the world

Filed Under: Current events, Pretty things, Rants, Tech
Jun.22, 2011

Last weekend, I participated in Hack for Change, a 24-hour codeathon sponsored by Change.org and Code for America where developers and designers were challenged to create apps for the public good. As my first hackathon, it was a tremendous experience in a number of ways, and some really cool applications came out of the process. Though we didn’t win, I’m very proud of the app my group built, Safehood — an entirely SMS-based anonymous communication channel for a neighborhood to discuss crime and potential safety threats, sort of a real-time backchannel for an existing neighborhood watch.

There was something that one of the groups said in their presentation, though, that kind of pressed my buttons. They made some very enthusiastic–grandiose, even–claims about how their application was going to change the world. But, I wondered, who would it change the world for, in whose interest? iPhone users, apparently–their app was iPhone-only. Well, this shouldn’t be a surprise, but even in San Francisco, most people don’t have iPhones. Most people don’t own smartphones, even. And for a significant–and radically underserved in many other aspects–segment of the local population, their only access to the Internet comes in thirty-minute increments at the public library.

Granted, there are many social problems that need addressing besides the digital divide. But it’s an issue that affects every entrant in this hackathon to at least some degree because of its very nature–trying to solve problems with technology. If a segment of the population can’t realistically use or access your app, your claims about the extent to which you successfully address your chosen cause should reflect that.

When my group started brainstorming what we wanted to do for our application, my teammate Michelle had a simple suggestion: let’s build something to help poor people, something to address at least one aspect of the cycle of [urban US] poverty. You wouldn’t think such a suggestion would be radical at an event called “Hack for Change”, but it totally was. All the app ideas I had thrown out previously were things that I could see myself using–an anonymous photo-submission police tipline-type service in response to the Vancouver riots, or an app for emergency response and resources in case of an earthquake or other natural disaster. Certainly they weren’t apps that only I would find useful, or even only people in my socioeconomic class. But that was a major bias in my thinking. Michelle’s suggestion took us out of that frame, and after further brainstorming and deliberation, Safehood was the eventual result: an application for helping communities collaborate to make their neighborhood safer, with a user interface designed from the beginning for a population that might not have a computer or smartphone at home. In our mental picture of how the app would be used, we now had Oakland in our head instead of Berkeley. I won’t go so far as to say that we succeeded in all this–there’s a million ways the app could be improved. But at least that’s where our heads were at.

Of the 16 or so applications at Hack for Change, I don’t know for sure, I wasn’t part of their brainstorming sessions, but I don’t think that a single other group had “Let’s build something to help poor people” or similar as their starting point. That’s not to say that some of the apps couldn’t be useful to poor people, or that they didn’t successfully address whatever their other chosen cause was. But still, that seems… off, somehow.

Most of my coding experience is on free and open source software projects, and most of the coders I know are part of that community. In FOSS, projects get started (and get continuing contributions and enthusiasm) because a developer wants to scratch his or her own itch. Which is understandable, and just fine most of the time. Hacking for “change” is different. Hacking for social change isn’t about scratching our own itch–it’s about scratching someone else’s itch, especially someone who may not have the resources to scratch it themselves. Being cognizant and deliberate about that difference is a challenge, but a necessary one, and one that I suggest that all designers, developers, and others think about taking on.

Comments »

Paper: Outreach and Diversity in FOSS

Filed Under: Rants, Stuff, Tech
May.24, 2011

Last week I finished my final research paper for INFO 203: Social and Organizational Issues of Information, on the mechanics of how people get involved in free and open source software projects and how implicit problems and biases in how that “recruitment” process works could explain the dearth of women and other diversity issues in FOSS communities. Honestly, I feel like I didn’t say much more than what Asheesh said in his super-excellent PyCon talk (and indeed, I quote from his talk and writings in the paper!). But there wasn’t a singular piece of writing out there, as far as either of us were aware, that laid out the need for FOSS recruitment changes (and underlying vision for FOSS) that Asheesh and I share. So now there exists a paper [PDF] [HTML] that he can point people to and tell them to read. Huzzah!

I don’t track the traffic to this website in the slightest, but at least one other person has linked (and glowingly recommended (!)) it so far. Which is good. I guess. It’s sort of alarming having strangers read a paper I did for class as if it’s an actual thing. I’m so totally not an expert on any of this stuff; I’m neither a FOSS leader nor a real academic. The only thing that’s making me not completely terrified is that I do, mostly, believe the argument the paper makes and want it to be more widely discussed. So, fine.

Anyway. As a teaser, my favorite bit in the whole dang 29-page thing:

Normal humans like to be welcomed. Recruitment processes for any number of other communities and collaborative efforts – university students, churchgoers, Habitat for Humanity volunteers – typically include elements to orient new members and help them become useful. Yet, for various reasons, such efforts are drastically undervalued and neglected by most FOSS projects. Feeling like an outsider – being the only woman, non-coder, or other minority member in the room, on the email list, or in the IRC channel – only exacerbates unwelcoming or hostile infrastructure.

It is important to note that none of [the previously discussed] assumptions or “filters” affects women or a particular ethnic group exclusively. There are plenty of people, men and women, who would otherwise be fantastic FOSS contributors who do not do so because they are busy, unsure of their technical prowess, shy, and/or discouraged by a project’s seemingly-hostile atmosphere. It is also important to make clear that despite the dismal statistics, the FOSS community is not devoid of female contributors and project leaders; these “filters” are not absolute in their effects. My point is merely to show that women (and presumably other minority groups) tend to be disproportionately affected by these flaws in FOSS recruitment. On the flip side, this also means that women and minorities represent the greatest growth potential for outreach in the FOSS community; if FOSS were to go from 2 percent women to 50 percent women (or even just 20 percent women), that change would not merely make FOSS’s demographic calculations more equitable but would also signal huge community growth as well, with thousands of new contributors coming “off the sidelines.”

(from pages 19-20)

Comments »

How to teach programming: shy, practical people edition

Filed Under: Art, Pretty things, Rants, Stuff, Tech
Mar.04, 2011

Retrospectively, if any kid were going to grow up to be a coder, it probably should’ve been me. Genetically speaking, my dad had been working on computers since high school in the 1970s, semi-breaking into the school on the weekends to hack on the PLATO project and throw LAN parties with his fellow teenage geek buddies. Mom had a minor in Computer Science (which was how she met my dad) and worked as a tech writer writing manuals and documentation. Growing up, since Dad was a software engineer at Apple, I *always* had access to computers. At age two After Dark was my favorite program; I could watch the screensaver fish or flying toasters forever.*

Dad tried to teach me BASIC when I was young, maybe 8 or so. I caught onto the syntax pretty quickly, but I had no interest in working with it; to me, interesting computer programs were Number Munchers and ClarisWorks and Kid Pix. They had a UI and could clearly be used for something fun and/or useful. In BASIC, I could make sequences of mathematically-significant numbers. Bo-ring! So, *obviously*, I wasn’t going to be a programmer when I grew up.

Except, at the same time, in elementary school I was creating huge, elaborate games in HyperCard and HyperStudio. I took a summer class on HTML at age 11 and promptly built a personal website full of animated GIFs and thunderstorm photography. As I know now, I was *totally* going to be a programmer, at very least on the front end. But at that time I didn’t see any of the stuff I liked as coding! Coding meant mathematical curiosities and text-based toy programs.

This perception largely continued through college. During my sophomore year I decided to take the first two CS courses (5 and 60) for fun, mainly because my friends at Mudd had taken them and raved about the professor. Prof Ran was, in fact, amazing, and I was glad I took the classes for background’s sake. But again, it was all context-less toy programs–a Towers of Hanoi solver, a command-line-based Connect Four player. The “coolest” thing we did was write a Centipede clone (I added the SkiFree yeti to my version as an additional obstacle :D) that you could host on your student website via a Java applet–and all the applet code was provided in whole without explanation. Additionally, it appeared that my chemistry curse (that everything that could go wrong did, and even if nothing could go wrong, the laws of physics themselves would break to make my experiment fail) applied to CS as well, given the number of weird errors I encountered in the homework that not even the TAs could figure out. Since our grades were predicated on turning in compiling, working code at midnight (late submissions got zeroes), my worst grade in college ended up being CS 60. So I took that as a signal to give it up.

Instead, I took all the front-end / digital media classes offered in my home campus’ art department. Disappointingly, though, those were almost entirely Dreamweaver and Flash-based, with only an elementary coverage of HTML and CSS and no scripting at all. I ended up spending all of “Intermediate Web Design” flailingly trying to teach myself PHP, since I already knew more code than the art professor who taught the class. There simply was no course offered that covered the wide space between CS and art, no ‘How to build a dang web application.’ Obviously there *had* to be connections between functional code to the UIs I was accustomed to, but I had no idea how engineers did it and no way to learn. So I pretty much gave up on the discipline.

Basically what revived my interest was having the opportunity to work on OpenHatch. Getting thrown into web app development and all the associated languages and tools–Python, Django, git, Agile, bash and other command line nonsense–all at once? Yeah, it was a lot. But Python out of context is just a toy. Django out of context is plausible, but hard. Git out of context…wouldn’t've made any dang sense. So sure, I couldn’t remember half the git commands (Asheesh eventually made a wiki page for me :P) and I had to look up how to restart the Django development server practically every dang time. But I made do, and I learned it, because the context totally freaking motivated me to. Because *finally* code had a purpose–it was clear, finally, how it could be self-expressive and useful to me. Learning these tools meant I could help make OpenHatch exist. Like, fuck yes.

Obviously, other people don’t feel the same way about coding and CS that I do. (If everybody did, there would be no CS majors!) Lots of people appreciate the beauty of code and of pure CS problems in themselves. Which is awesome. And I do too, to some extent. But I don’t research the history of masterpieces or do experimental art–I draw pretty things. I never studied music theory–I sing. The routine conflation of English literature and writing coursework (NOT the same thing, DAMMIT) makes my brain explode. Asheesh once gave a talk on “Debian for shy people” and often talks of “programming for shy people” generally. I happen to be not just shy but practical, too. And it took intense personal mentoring via OpenHatch and integrated non-traditional-CS ‘how to build a web app’ curricula via IOLab and Rails Outreach for Women for me to finally feel empowered enough to call myself a programmer.** Just a shy, practical one. :)

* Fun story from my dad: When I first saw After Dark, it was running on Mac OS System 6, with an add-on that made the control panel a hierarchical menu. Even at age two, I could mouse through it and turn the screensaver on myself. Then Dad installed the System 7 beta, which turned the menu into a folder, so the control panel would no longer pop over to the right when you clicked on it. Nonetheless, I apparently instantly figured out to release the button to open the folder, then double-click on After Dark (when before it would have been a single click). Dad passed along to the System 7 developers that the graphical cue of a window appeared to be enough to get users to do the right behavior–at least, two-year-old users. (I (today) told Dad that Apple should’ve used me in their ads–”So easy a two-year-old can use it!”)

** It also helped that in my new grad program, everyone seems to think of me as being super-technical. Like, sure, I guess I had more experience with this stuff than many of my classmates going into 206 last semester. But me, “technical”? It feels as if Velma were “the hot chick” in the Scooby-Doo gang–bizarre, though also awesome. Imposter syndrome, engage! :P

Comments »

Take my hand, and we shall commit a sin irreversible…

Filed Under: Music, Politics, Pretty things, Rants, Stuff
Jan.17, 2011

Another song post.

(photo by Ingrid Tayler, CC-BY)

Ever since I first laid eyes on it, I have been in love with San Francisco’s city hall building. There aren’t many other places in the world that I’ve been to that would rank as more romantic. Ever since I saw all the pictures of gays and lesbians marrying their partners when gay marriage was newly legalized in California (prior to Prop 8), I’ve felt this way. Seeing “Milk” and watching Harvey dance up the big atrium staircase to his new office after being elected to the city council only further reinforced it in my mind: the association between this building and people who fight for love. I don’t think I’ll ever get hitched here, but still: when I bike past it I kind of have to fight the urge to grab a random dude or lady and elope.

(this is relevant, I swear)

There is a song on my computer that is practically ungoogleable. The lyrics aren’t listed anywhere; I’ve only ever found one mention evidencing that it does, in fact, exist. I’m not even sure how it got on my hard drive. But when it came up on shuffle last year, I actually noticed what the words were saying and I fell in deep. The song is “Halfway There” by West of Eden, and if I ever get married, gosh darnit, this song will be at the wedding.

Go listen. Here’s the chorus (hand-transcribed, thanks to previously-mentioned googlefail):

So take my hand, and we shall commit a sin irreversible
Baby I’m tellin’ you, we’re halfway there to be labeled socially unapproachable
Oh, let ‘em roll, ’cause I’d rather have you than be clean, cool, and respectable
So we’re goin’ to hell, but tell me baby, who cares–we’re already halfway there.

The vocal parts move from whispery and sweet to sassy and snarling and back again throughout. It’s only two ladies and an acoustic guitar, yet it’s not just soft and folky — there’s real passion in the later choruses. And I love the harmony.

The lyrics aren’t a be-all and end-all — while spontaneous road trips and “sleep[ing] till noon” and telling haters to screw off are certainly things I want in a relationship, I do too want to be a responsible adult sometimes. I want a solid, ridiculously joy-filled “world of two” but I still want to be part of the wider world; as much as I am in love with being in love, having other friends and other goals is very important to me. Everything in moderation, excepting moderation, amirite?

But the song does get at something key. The couple in the song exists outside of other people’s expectations and norms for what their relationship should look like. Given the chorus, and the two women singing, I like to think it’s about two lesbians in love, but it doesn’t have to be for the point to be the same. The idea of deliberately, powerfully passionately choosing one another outside of anybody else’s narrative, and defining for each other what that choice means–what does it mean to be a wife? to have a wife, when you are yourself a woman?–these are all ideas that the increased visibility of queer relationships and the advent of gay marriage have brought to the fore. Even straight couples ought to ask, and are asking, these kinds of questions. Just as Western gender roles have changed and expanded, there are fewer and fewer set expectations for how romantic partnerships are going to work anymore–or at least there should be. Even if you want a stereotypical white middle-class 1950s relationship, you sure as hell had better make that clear from the get-go!

If I get married, I want a marriage that very explicitly doesn’t happen by default, which relies on inertia as little as possible. Where nothing is assumed up front, roles are discussed and negotiated and baggage is examined and at the end of it all we yell “Fuck yeah I do! I choose you, Pikachu!” and start making out wildly in front of everybody. And I want this song there.

Comments »

Body issues

Filed Under: Comics, Rants
Dec.02, 2010

I’m still not at a point where I really, truly *like* how my body looks, but I’m at a point where that aspect bugs me less than my elbow problems and fitness level (specifically in climbing). Found that fact weirdly comforting today, despite my overall frustration with being injured. (STILL waiting on the new insurance card so I can make an appointment to have my elbow looked at! And my own research suggests that this damn thing won’t heal for at least 3-6 months!)

Comments »

Stereotype threat

Filed Under: Comics, Rants, Stuff, Tech
Oct.11, 2010

My first open-source software patch was made September 30. Today, October 10, was my first case of stereotype threat related to coding directed at me. Given the kind of sentiments that are common in FLOSS as a whole, I was probably overdue for some idiot saying something. It still disrupts your head a little bit–you’re trying to summarize your work and get shit done, but some arse has set up a big neon flashing arrow that points at you and says “LOOK! A GIRL.” It’s just a mite distracting. >.<

The incident didn’t go down *quite* as depicted. Yet again, I’m grateful that OpenHatch, the OSS project I’m involved with, has a high concentration of fellow lady coders and male allies who are awesome and totally rock. I didn’t even hardly have to respond. :)

Comments »

The Hooligan and the Underdog

Filed Under: Current events
Jun.25, 2010

I’m going to write a bit about soccer today. But first, some football context. Bear with me.

Having grown up in Minnesota, I’m a recovering (always recovering) Vikings fan. The Vikings are perpetual heartbreakers and heart attack givers. Even from the days of Bud Grant and “Two-Minute Tommy”, you could never count the Vikings out. Fourth quarter, even two minutes left—it didn’t matter how much the other side led by. The Vikings were the king of last-minute rallies. The Vikings are explosive—and, appropriately, inconsistent. My time as a Vikings fan was spent watching them win against far better rated teams—and lose to teams they ought to have blown out of the water. They’d spend most of the season playing like Super Bowl champions, then lose ignominiously in the playoffs. My team has only been to the Super Bowl once, and has never won it. Vikings fans take nothing for granted—we’ve seen too many impossible wins and aneurysm-inducing losses.

The problem with soccer for many people, I think, isn’t really that it’s so low scoring (give each goal a touchdown’s worth of points and it’s comparable with American football). It’s that as the game goes on, often the players and the match as a whole give off an air of inevitability—it’s assumed that the team that’s ahead will win the match, or that both teams will let things drag to a draw. Of course it’s boring when teams don’t fight and the announcers take things for granted!*

Which is why the US-Slovakia game, and later the US-Algeria game, were SO great, and SO American. Everyone thought we were goners when Slovakia was up 2-0 at half. Two goals is considered a commanding lead in this bloody sport! Fortunately, our team was made of Americans who didn’t know better, so they not only went on to tie 2-2, they would have had a third goal and won the damn game if it weren’t for a terrible call.

And the US-Algeria game: what a Hollywood script match! Taking more risks, hitting more and more shots as the game went on in a passionate, full-hearted, grit-in-your-teeth effort to get the ball over the damn line and stay in South Africa. I’ve seen many a “hurry-up” football game, carefully managing the clock and racing against time. I’d never seen real, serious “hurry-up” soccer before. The New York Times declared that the second half was more like a track-and-field meet than a soccer game, with the US offense constantly sprinting toward the Algerian side as fast as they could, Tim Howard hurling the ball well past midfield to Altidore’s running feet. (The soccer version of a Hail Mary?) How many hundreds or thousands of Americans who’d never even watched a soccer match before ignored their work, clenched their teeth, begged for a goal, and hollered like madmen we when finally got it in stoppage time? All this for a “boring” 1-0 point difference? We love the team representing us. We LOVE this kind of game.

Soccer can become the kind of game that Americans love. Not if we try to play like Brazilians, or like Germans, or like any other powerhouse team style. We have to make the game our own. Arguably, at this World Cup, the US side is doing just that.

* This is becoming less true worldwide. The gap is closing between the traditional powerhouses and smaller teams. New Zealand was thought to be one of the worst teams in the World Cup; in fact, they went undefeated. Slovakia killed Italy; Mexico dominated France; both those teams from last year’s World Cup final are going home early. There are no kings in soccer anymore: it’s now conceivable that any team can beat any other team on a given day. The US, with its sports culture full of teams like the Vikings and deep-seated love of the underdog, just tends to believe that fact more readily than most.

Comments »
Creative Commons License
Licensed under a Creative Commons Attribution 3.0 United States License.
Powered by WordPress.
Theme NewRiver by Karen Rustad, based on Motion by 85ideas.