Liz.new

A sassy lady (since always) and a software engineer (since 2013) with lots of things to say (mostly about web, women, and/or programming).

Why I’m here

I am here because I love what I do. I love working with Ruby. I love tinkering with JavaScript. I get an absolute thrill over the legitimately amazing things I can do with programming. I’m stoked to learn Clojure. And maybe Scala. Or Python? More things. I’m excited to learn more.

I am not here because I have an agenda. I have an agenda because I have to have one to keep my head above water. This agenda also comes with the support of a wonderful community, which is the only thing that can protect me from the vitriol and cruelty that exists in the tech sphere. These things are thrown at me because of my gender, the opinions I hold, and the people I socialize with, not because I’m a bad person or a bad engineer. Just because someone doesn’t like me, the things I say, and the things my friends say.

Earlier today when my GitHub profile was used to lend credibility to a repo mocking feminism, rape victims/survivors, and women in general, I wasn’t mad. My first reaction was concern for the code that I have access to on GitHub. Was my account compromised? Or worse, was GitHub? Code that isn’t mine could be at risk. Code that lots of other people have put many hours into. Code that does good things.

And then, when I figured out it wasn’t a security breach, because I’m human, I got mad. GitHub is a source of my abilities as an engineer and a record of my contributions to software development. It is my career. It is also my pride and joy. My proudest achievement in life was becoming an engineer.

But I’m ok. No one threatened me. No one hurt me. They rattled me. I’d be a fool if I tried to lie and say they didn’t shake me a little. But I also felt lucky, loved, and supported by more people than the number involved with the filth on GitHub.

I am also still really happy to be here.

I also still want to change the tech world, but not in the way you might think. I was to spread infectious enthusiasm for software development. I want people to love their code as much as I love mine. I want people to have the same zest for programming that I do. I want people to be happy with what they are doing.

Renaming “soft” and “hard” skills

People in the development community tend to throw around the phrase “soft skills” to describe things that are not directly related to writing code. This isn’t exclusive to the development world; lots of people use the term “soft skills” to describe traits that can’t be directly attributed to certifiable/measurable skills and specialities. A non-exhaustive list of what “soft skills” typically encompasses would be:

  • Project, task, or team management
  • Communication
  • Friendliness
  • Team building
  • Influence and persuasion
  • Conflict resolution

I, like many others, am pretty damn tired of referring to these as “soft skills.” Many employers actively seek out these attributes in prospective employees, making them near requirements for success in the workforce. If something is a near requirement, why is it “soft”? I’m not a stuffed animal, and neither are these highly relevant job skills.

"Soft" implies that it’s less important than it is by using a word to describe the skill set that also means things like "pleasing", "enjoyable", and "subtle effect." To further illustrate my point, here are some words that are synonyms for the many meanings of "soft":

  • mushy
  • dim
  • lenient
  • easy going
  • compassionate
  • subdued
  • silky
  • gentle
  • forgiving
  • tolerant

With the exception of “compassionate” and “easy going”, this is not how I want myself described to a prospective employer ever. These sound more like personality traits you’d find in a dating ad than on someone’s résumé or in a job description.

Yes, it’s nice to be able to have “soft” because its immediately obvious opposite is “hard.” But, just like “soft,” “hard” has some unintended meanings in its synonyms as well:

  • resistant
  • solid
  • unyielding
  • arduous
  • grueling
  • strict
  • severe
  • violent
  • austere
  • reliable

Again, with the exception of one or two terms (“reliable” and perhaps “solid”), none of those adjectives are terms I want applied to me and my “hard” skills. I’m sure no one wants to have their technical skills described as “violent” or “unyielding” (especially with regards to change).

The point here, really, is that both “soft” and “hard” have many different definitions. How do you know which one someone is actually referring to? Do you infer? Or do you just hope it’s not “silky” or “violent”?

When we say “soft skills”, people typically mean interpersonal relationships and personality traits (team building, communication), task- and management- related abilities (project and team management), and customer-facing skills (conflict resolution). When we say “hard skills”, people typically mean certifiable, testable, or measurable knowledge (programming languages, aptitude in math) and skills (selling prowess, abilities related to manual labor). It’s usually very easy to determine if you (and employers) consider something a soft or hard skill, but what warrants a stamp of approval in terms of ability with both soft and hard skills remains subjective even when certifications come into play. Hard skills can be tested - or at least employers like to think they can be - and your performance measured on some secret scale.

So can we please stop calling them “soft skills” and “hard skills”? Can we call them something more specific and descriptive of what we actually mean? I think we should introduce some transparency in the way we as humans describe our abilities and the way employers describe jobs.

Here are some ideas for alternatives to “soft skills” and “hard skills.”

For "soft":

  • Interpersonal
  • Human
  • Subjective
  • Psychological
  • Personal
  • Rational
  • Cognitive
  • Social
  • Life-learned

For "hard":

  • Quantifiable
  • Technical
  • Professional
  • Academic
  • Specialized
  • Computational
  • Robot
  • Learned
  • Mechanical
  • Book-learned (obviously not everything is learned in books these days)

Some potential pairings could be:

  • Interpersonal and quantifiable skills
  • Cognitive and technical skills
  • Personal and computational skills
  • Human and robot skills (heh!)
  • Subjective and quantifiable skills
  • Psychological and technical skills
  • Social and mechanical skills
  • Academic and experiential skills

While some of these have stronger, more positive connotations than others, I leave it up for you to decide what works when you describe yourself and your abilities. If you think that “soft” and “hard” are the best way to describe your abilities, well… I would encourage you to look up the multitude of definitions for those words. While they may not be the first thing someone thinks of, those alternate definitions are still floating in the back of people’s minds.

Thoughts on hobbies and gender, revisited

It’s no secret or a surprise that knitting is a gendered hobby. Most knitters are women and there is nothing offensive or factually incorrect about that statement. While knitting as a hobby is growing and there are more men and boys participating in the craft, it is still primarily women that pick up the needles and work with yarn.

Issues of difference have always been very important and fascinating to me. I focused on studying prejudice and social norms during my psychology education in college, and specialized further in grad school within a Women’s Studies department. I focused on norms and how they related directly to sex/gender, race, sexuality, and religion and are represented in popular culture that primarily attracts a young, female audience. Now that I’m in a predominantly male field, gendered differences in the way people work and interact at work are more apparent to me than in previous jobs.

What does this have to do with hobbies? A lot. I was a bit overloaded on the academic world, and over-analyzing every aspect of my life with a gendered, racial, etc, etc lens was an emotionally exhausting task. To be honest, it hasn’t really been on my mind until lately – last Halloween was the first time that I had friends with kids old enough to state opinions about what they wanted to dress up as. One of them recently lamented to me that while her son could find action figures, books, and costumes, her daughter could either be Cat Woman or the Black Widow. And that was it. There weren’t any other superheroes, all of her other options were gender-neutral ghosts, ghouls, animals, and inanimate objects, or the time-honored princess. Even Brave’s Merida is a princess. Her daughter dressed up as Captain America last Halloween. This isn’t new: princesses are to little girls what Marvel and DC Comic characters are to little boys. They’re the majority of the gender-specific market share.

But it got me thinking about hobbies, and kids, and how parents connect with their children. When I was a little girl, I played on the boys’ t-ball team and on a co-ed soccer team. I painted, crocheted, read books, threw mud, and played around on my dad’s ancient computer. I also played with my brother’s chemistry set, and he played with my Barbie dolls (he also had dolls of his own). It is never as black-and-white in lived family lives as it appears to be in the pink-and-blue aisles of Target and Toys R Us. I connected most with my mom when we sat on the couch and read together, and most with my dad when we make cookies in the kitchen.

How am I going to connect with my kids? Obviously I’ll teach them how to knit and I will attempt to instill a love of programming in them as soon as they are young enough to possess the dexterity to do both. Like any good parent with an obsessive hobby, I’ll force it on them until they make me admit defeat, or until they learn to love it. If I have boys, I’ll knit with them, just like if I have girls. I’ll play video games with them, and while I hope that they will be gender-appropriate or gender-neutral games, they may not be, so I’ll reinforce gender equality in their day-to-day lives. I’ll bake with them, and walk the dog with them, and make sure they enjoy reading as much as I do.

I was lucky enough growing up that my parents were both aware of and occasionally challenged gender roles. My mom raised me to be an unapologetic badass, constantly questioning and trying to improve myself in every way that I could. She taught me to be proud of my smarts, to not be afraid to share things I knew with other people, and to remember to listen to everyone, not just the people who I thought were smarter than me. My dad raised me to be polite and kind, always thinking of others before thinking of myself. Hopefully I’ll be able to teach my kids that their gender doesn’t matter, even if someone else tries to convince them that it does.

Modified from the original post on feministy.com (November 2012).

Theory vs. practice and my first days as a developer

This has been the start of my first week as a Software Engineer. I work at a real company doing things with code that people actually use. It is awesome, terrifying, thrilling, challenging, and hands down the coolest thing I’ve ever done. I’ve only been poking around in the code base for a few hours a day, but I’ve come to realize that I am going to learn more at this job than I expected.

At my first job, I expected to become more proficient at Ruby, Rails, and JavaScript (among other things). I didn’t expect to see languages and frameworks being used in ways I had never conceived of. I didn’t expect to be working with such a complex app and equally complex models. Models that actually, truly model the real objects they’re representing. It’s a big code base with complex database models, but it’s big and complicated because the problem it solves is also big and complicated. The relationships represented in this database, while confusing to a newcomer, make sense after you have the big picture.

This contrasts greatly with my previous (albeit limited) experience developing web apps. At Dev Bootcamp, there is a lot of theory. They did a really good job about instilling that theory in us as practice. Object-oriented design and the “Rails way” weren’t just textbook theories, they were actual ground rules for developing applications. I had never developed an app or worked with an app that veered too far from those principles. While my implementations of OO principles and the Rails way may not have been perfect, they were pretty damn good considering that I’d only been doing it for a few months. The apps we built were not overly complicated, nor were we proficient enough with the tools we were using to efficiently and expertly use them.

In short, the apps we built at Dev Bootcamp were sheltered from the “real” world of users, continued development, and maintenance. Partly because of our skill level and partly because they’re not designed for mass-consumption. Legacy code wasn’t a thing we had to deal with because our oldest projects were only ever 9 days old. If we ran into a problem we could always drop the database and start over. We could hack together a provisional solution for something until we figured something else out because deployment didn’t impact users (we had none). I encouraged my team to consider our data and dummy users as real objects that had to survive migrations, refactoring, and complete code base changes. But, I would be lying if I said that we never succumbed to temptation and dropped the database anyways. So I won’t lie: we did it. We rake db:drop’ed it like it was on fire.

And now, I work with an app that’s real. It has real users (lots of them), real data (tons of it), solves real problems in an elegant manner, and it actually helps people. The little things I do to our code base will, in some small way, impact the education of the app’s users.

So it’s only the end of my third day. I haven’t pushed any changes to the app (yet). I’ve poked around the API, played around with dummy data, and familiarized myself with the app. 

Lots of the theory that we tried to practice at Dev Bootcamp has suddenly become real for me. The practice of principles is never the same as the theory, but being an academic, I’m always inclined to hope that theory and practice are mirrors of one another. In the “real” developing world, they’re not. And that’s making me a better programmer. It’s making me more inventive, it’s making me question things more, and it’s making me more comfortable with the things I don’t know.

This is one of the worst tech ads I’ve seen in awhile. This is not how you make women feel comfortable in tech positions. This is not how you enable or encourage women to achieve in tech positions. This is how you contribute to making people think women are inept with technology. 

A woman who uses the computer for family photos, the internet, “and stuff.” Contrasted with two men: one a gamer, the other a multi-tasking businessman. 

A woman who says “what?” when you show her an SDD, and two men who get excited and can’t wait to get going.

A woman who marvels at a screwdriver. A woman who suddenly feels like an expert because she can do something that is being compared to a child’s building bricks toy.

Oh gosh, golly gee! I wish that I had a brand new Samsung SSD so I could feel like an expert!

Actually, I kind of wish I had a Samsung SSD so I could throw in it in the face of the people responsible for this ad.

Why I wear dresses

Since graduating college, I’ve only had one job that required “business casual” attire. I hated that job, partly because a dead-set-in-her-traditional-ways HR representative made snide comments about my wardrobe everyday (“I wish I wasn’t a professional woman so I could wear jeans!”). It was never “business casual” enough for her.

So for a few years, I rebelled against wearing dresses and skirts solely out of spite. Spending 40 hours a week in cheap polyester because it was all I could afford from the “business casual” area of Target completely turned me off from dressing up for work. Imagine my relief when the job I took at Groupon fresh out of grad school required no change in my wardrobe. 

I moved to Chicago and admitted defeat my first winter. It was colder than I had ever been in my entire life. I can say with absolutely certainty that it was the coldest I had ever been because I was born and raised in California and had only visited a cold part of the country once during winter. I lived in leggings, wool tights, hand knit sweaters, and piles of scarves for my first winter in Chicago.

And then spring happened! Glorious, beautiful spring. After spending 4.5 months wearing nearly all black, I decided it was time to break out the bright colors and festive prints. All those dresses that lived in the back of my closet were suddenly now the perfect thing for me to wear. They were no longer horrendous memories of being ridiculed for my sense of style. I embraced wearing dresses. One brave weekend I went through my closet and bagged up all of my Threadless t-shirts and crappy college kid clothes for donating. Very slowly, I started buying new pieces of clothing that were well made, would last for years, were reflective of my style, and were comfortable.

So now I have a closet full of dresses that are reflective of my personal style, which means I wear dresses a lot. I don’t need to. I’m a software engineer (!!!). Most of my co-workers are still wearing their college wardrobes. And that’s totally fine for them! 

But I wear dresses. Why? Because they make me happy, and I feel like it’s easier for me to express things about my personality through what I wear than anything else.

I also wear dresses because it’s easier to pick out one thing in the morning than it is to pick out two. A dress is an entire outfit. 

Also, somehow, magically, dresses don’t get dirty or dingy as fast as plain old cotton t-shirts. They don’t need washing as often, which is good because they are typically hand wash or dry clean only, likely because their fabric is nicer.

I wear dresses because I don’t have to. It’s a choice that I make for myself everyday to express how I’m feeling with what I wear. Some days I feel like leggings and a hoodie (those days are usually December-March), and other days I feel like 5 inch heels and a floor length dress. 

Going to Hogwarts

One of my favorite ways to explain how passionate I am about coding is to compare it to the world of Harry Potter. To me, learning to code is the closest I will ever get to boarding the train to Hogwarts, taking my O.W.Ls, and crushing my N.E.W.Ts. Picking out a new computer and configuring Vim (new obsession) are akin to selecting a wand at Olivander’s. I could continue with the comparisons, but I think you get it.

Except there is one part of my Harry Potter analogy that doesn’t fit: in the world of magic, only those born with it can do it. While being born in a first world nation with access to high speed Internet, English-language training materials, and swanky computers may predispose you to excel at hacking, ultimately anyone can do it. There is a difference between anyone being able to do something and being good at it, or even enjoying it enough to try and be good at it.

We can argue for days about what makes a good programmer. Some people value soft skills while others value programming ability and breadth of knowledge. Others still argue for educational background or time in the field. Regardless of the actual reason(s), I think being good at programming is magical.

Why magic? Why not super powers? Because bad ass wizards don’t have to wear spandex. But really, it’s the limited nature of being a super hero that bugs me.

How many heroines/heroes have more than 1 super power? Not many. Compare that to magic, with its many disciplines, spells, and realms of knowledge and it feels a bit more like programming. The diversity of magic practically begs for comparison to programming, which is populated by opinionated polyglots with a wide range of expertise.

Also, I’m not doing this to save the world. I’m doing it because something inside of me needs to do it. Sure, saving the world is a bonus, but it’s also awesome to do things for yourself every once in awhile.

Part of me also hopes that someday I’ll meet a real dragon in the literal sense rather than a crotchety old dev whose demeanor resembles the scaly beasts.

Interviewing women

One of the things I learned from the interview processes I went through is that the presence of women is important. I present you with two different scenarios.

One: A large company with a number of well known and very talented female engineers and product managers on staff. The only women I spoke with during my entire interview process fetched me water and coordinated guest pass access to the building. I did not meet a single female employee who was not a recruiter. While they were all very lovely, kind women, I felt no connection to them because all I talked with them about was the weather. When I brought up the topic of female engineers in general, they started discussing a female product manager and how great she was.

Two: A mid-size company with a number of female engineers, engineering managers, product managers, and technical support team members. I did not interview with any women, but I was introduced to many members of the engineering team during my visit, including a number of women. While I also felt no connection to them, it was due to the brevity of our interaction, not because of their role at the company. When I brought up the topic of female engineers in general, they said they had quite a few and appreciate the value of a diverse work force in all aspects. 

Even though I spent less time talking to the women at Company Two, the interactions I had with them were more meaningful. I don’t need to talk to women, or see women, or even have any women there to want to work at a company.

But when the only interaction I had with the women you employ is what equates to them running errands, there isn’t a snowball’s chance in hell that I will come to work for you. 

And it’s not because you have female recruiters. That’s not why. It’s because I’m passionate about diversity in engineering. It’s one of the first things out of my mouth during every interview process. For a company to listen to me say that numerous times and create that interview experience says to me that they really don’t care about me as an individual human being with interests outside of hacking. Or much much worse, that they don’t care about diversity in engineering. 

(For what it’s worth: you don’t have to employ women engineers to care about diversity. You just have to genuinely, honestly care about diversity.)

Women Are In Everything

A lot of the time when I describe myself and what I’m passionate about, I end up talking about women in programming or women in engineering. Taking about concepts such as power, oppression, injustice, equality, objectification, etc has been a common theme in my life since I started college.

And to be honest, if you look back at my life, it was a trend when I was a little girl, too. Instead of playing on the girls t-ball team, I played on the boys team. For the one insufferable season that I played soccer, I was on a co-ed team sporting a bowl cut (a hairstyle I demanded because my brother got one).

So this theme of being a little brave and loud about things that people don’t always notice is not something new. It’s just a little bit of who I am.

So it should come as no surprise that upon entering the world of programming, there are things I notice. Namely:

  • It’s not uncommon for me to be the only woman in a room.
  • Just because there are other women doesn’t mean that we’re going to bound over our shared gender. I’m just as likely to connect with a fellow woman in programming as I am with anyone else that I share a common interest and gender with.
  • If I am the only woman in the room, how I carry myself often sets the tone for how men respond to me and the things I say.
  • A strong personality, patience, or a desire to find common ground through conversation make more of a difference in how well I get along with people than anything else.
  • Everybody loves to talk about Katy Perry, even if they don’t like her, she’s still fun to talk about.

Only a few of these observations have anything to do with me being a woman, although who knows how likely it is that a man in engineering would make similar observations.

But really, the point is, women are in programming, just like women are in everything else. And, just like everything else women are minorities in, we sometimes have to deal with bigotry, ignorance, arrogance, confusion, fear, and sexism. But also, just like everything else women are minorities in, we have allies, we find support, and we eventually succeed.

Women are in everything because we’re people, and people are in everything. We will get through the rough spots because we have the allies and the support. And even when we get through the rough spots, there will still be some troubling events. It will never be perfect, but we can still strive for it.

Although you would assume it goes without saying, it actually has to be mentioned because it often isn’t, women aren’t the only minority group - in programming, or in anything. I won’t pretend to be an expert on being marginalized: just because I’m a woman doesn’t mean I know everything there is to know about being an outsider. It may not always be easy for me, but it could definitely be harder. And even then, it not about the level of difficulty a person experiences, it’s about there being difficulty for people period.

When you start talking about “women in engineering”, remember that women are one group of many that need support and allies and be someone who provides support for people who need it and don’t be afraid to be an ally.

On being new, or: Why I’m not doing phase 4

Last week I had the pleasure of having lunch at Table XI and taking part in their round table talk for the day, where I gave a Pecha Kucha presentation on what it meant for me to experience being new. 

Dev Bootcamp offers an optional phase 4, where students stay around for an extra 3 weeks and offer 10 hours of TA work in exchange for additional training on a Javascript framework. They also get help searching for jobs and everything that comes with job hunting. I opted not to do phase 4 through Dev Bootcamp and am instead doing my own personal phase 4.

A lot of people have asked me why I’m not doing phase 4. When presented with the opportunity to learn for 3 more weeks and know more than I do now, I jumped at the opportunity. But the more I thought about why I was doing phase 4, the more I realized that I shouldn’t.

I wasn’t so excited about doing phase 4 because I wanted to learn more. I was excited to do phase 4 because I was terrified of leaving Dev Bootcamp and being on my own. While I’m not on my own because I still have mentors and the Ruby community, I am significantly more alone than I have been in the last 9 weeks. I was using phase 4 as a crutch, as a way to avoid coming to terms with the gaps in my knowledge. I was scared that I would realize how little I knew, that I would find myself unprepared for an apprentice- or junior-level developer position.

The end result of all this pondering and thinking was that I couldn’t do phase 4 just because I was scared of learning on my own. I had to opt out of phase 4 and face my fears. It was precisely because I was scared of not doing it that I had to do it.

So here I am, sitting on my couch, reading a book about RSpec for Rails, snacking on some fruit, and hammering away at the keyboard writing tests for my knitting pattern generator. I’m editing my resume, tinkering with my website, and relaxing with my pup. It’s not so scary after all. It’s a little weird being alone after spending 12-15 hours a day with the same 20 or so people, but I’m enjoying busting some dance moves in my living room.

It has been awhile since I’ve felt new. I wasn’t new at my last job for a long time. There wasn’t much about my position that I didn’t know or understand. Before that, I was a nanny and a grad student. Being new is foreign to me now.

I was trying to describe the sensation of being new to programming to someone, and the best analogy I could come up with was that it felt like I was being shot out of a cannon. Being propelled through the sky, soaring so fast and seeing things from a completely unique perspective. Trying to take everything in, but being so overwhelmed by my surroundings that I feel like I’m missing things. 

I know that my cannon-like existence won’t last for long. I’ll find a job soon-ish, and I’ll get comfortable with being new. I will continue to learn and teach everyday. But until then, I’m in my little cannon, propelling through the sky. Zoooooom!