If you can’t see it, you can’t be it.

As a person who has always been good at math and science, I’m not sure why it took me so long to get into technology.  Basically, I just never envisioned myself as a science or math ‘type’ of person (with whatever connotations that stereotype carried).

Things have really changed.  In order to become an engineer, I had to let go of the notion that I needed to fit a personality stereotype of the girl-nerd who memorizes digits of pi in her spare time and gets involved in pedantic debates with strangers in the grocery store line about the nuances of the Silmarillion.  Letting go of this allowed me to focus on what I’m really good at (solving problems, working in details that relate to a larger picture, learning languages, working primarily solo but in the context of a team) and move into a field where these strengths can blossom.

The paradigm shift was essentially a change in my personal narrative. When I was growing up, I thought of programming as an anti-social activity that women only did if they were socially awkward.  Just as most little boys today don’t imagine themselves as nurses or secretaries or pre-school teachers, I didn’t picture myself as an engineer.

Even now, I sometimes feel that I don’t belong here.  And that’s not uncommon among females in tech.  If you ask a woman how she got into the field, you’ll likely hear some version of “I don’t really belong here.” A few common responses:

  • “I’m an English major who just stumbled into this field by accident.  Lucky for me!”
  • “I’m just doing this because my old company needed some help with their HTML, so I said I’d do it.”
  • “I’ve always wanted to do this!  I’m weird like that.”

Each of these narratives serves either to minimize our tech skills or minimize our femininity.

Taking time to intentionally rethink my own story has really helped me recognize my own very real belonging here.  Here are some of the things I remind myself of when I feel like the ugly ducking of engineering:

  • Engineering is all about communication, and as a writer with an English background, I have a lot to bring to the table here.
  • I’ve been using web technology for the last 20 years, and as someone coming into the field with fresh eyes, I tend to have a clearer sense than seasoned engineers of how people will use our apps and what behaviors users will expect from the software.
  • Although I’ve always thought of myself as a humanities person, other members of my family — men and women — have pursued science successfully.  My parents work in physics and medicine, and I just found out that my grandma graduated from college with a math major!  Without realizing it, I followed in their footsteps.

Sitting in the office, although I’m surrounded by a the trappings of a tech sub-culture that I don’t care much about — debate over the new Microsoft game system controller, Jar Jar Binks conspiracy theories — I know more than ever that I belong here.  The things about me that make me an unlikely coder are the very things this industry needs — fresh eyes, all kinds of people who can help broaden the potential uses of technology, better communicators to pass our technological skills to the next generation of junior engineers.  I’m not going anywhere.

Advertisements

Senior engineers might not be so bad

I’ve talked before about my ambivalence toward senior engineers.  As members of the department with 4+ years’ experience, senior engineers often come across as know-it-alls, eager to criticize whatever you do before you’ve even had time to explain it.  No matter how hard you work, how many annoying little bugs you fix, how many features you contribute of your own initiative, in the end nothing you do impresses or surprises them, because they could do your job better and faster anyway.

It’s easy to resent senior engineers — people who are significantly younger and less organized than I am but make significantly more $$ (because, let’s face it, they are significantly more skilled than I am) — but I’ve seen some great sides of senior engineers over the past few months that have softened my critiques.

One of these glimpses happened a few weeks ago.  I was having a conversation with my senior engineer friend Brent about how overwhelmed I feel about next steps in learning computer science — I want to take a couple of classes, but all of them seem to require Python.  After the year-long slog that was learning JS basics, I lamented, how could I commit the time to learn Python?

At this point, my stereotypical senior engineer would have been like, “Yeah, it’s probably out of your reach.  I program fluently in all languages, and 99% of them are so much more better than Python anyway.  Let me further offer some choice critiques of OOP that only I have thought of.”  And then I would have gone back to my downtrodden and discouraged state.

But Brent is not your stereotypical senior engineer.  He took a breath, and said, “Yeah, but you know, once you’ve learned one language, they’re really not that hard to pick up.  I wouldn’t let that stop you.”

In that moment, I felt a newfound capability as the whole world of programming opened up to me.  My thoughts raced: Is it possible that learning Python — learning any language — might not be such a big deal?  What if I can do it without much fuss?  What if I can learn anything I need to learn?

Since that conversation, I’ve been devouring the Python.org tutorial and even started a Python-based Data Structures course!  Brent was right — it’s really not that difficult to learn a new language, and the time investment is so much lower than it was for my first language.

But my bigger takeaway from this experience is about reserving judgement until I’ve really given something a good try.  Python terrified me at first because I had it in my head that learning it would be a huge time sink.  It continued to loom over me until I tried it out.  Likewise, senior engineers — who I’d all but written off after a few terrible experiences — turned out to be not all bad and maybe even a little bit good.  It’s all a matter of being open to new experiences and not letting pre-conceived notions get the better of me.

Save Time: 3 Ways to Study Smarter

I spoke a couple weeks ago about the concept of high-leverage time, in which every hour of focused time is an investment that will reap exponential benefits in the future.  Studying engineering skills certainly qualifies as one of these, and it’s crucial to learn a few skills that will help you get the most out of your study time.  These three ideas provided great time savings when every minute was precious:

  •  Learn keyboard shortcuts for your OS and for Sublime.  You should be able to do most of your work without touching your mouse.  Every minute you invest in practicing keyboard shortcuts represents hours saved in the future.
    • OS: Use shortcuts to switch windows seamlessly and search for anything you need.  Be able to switch tabs in your browser without using the mouse.
    • Sublime: Copy/paste are givens.  You should be able to search one or all files, duplicate lines, swap lines, and move between lines and parts of lines with ease.
  • Tame information overload.  In school, a million ideas and software trends are coming at you every day.  It can be overwhelming.  If I had looked up every new term and trend that came my way, I would never have gotten any coding done.  I used two free apps to help manage the information overload:
    • Evernote is my note-taking app, and I place the word REVISIT next to any term or part of the lecture I want to come back to.  When I have free time, a simple search gives me my list of concepts to look up or code algorithms to work through.
    • Pocket allows you to save any online article for later [offline] reading.  It even has a browser plugin so that you can save articles from your desktop, then read them later on your phone or tablet.
  • Schedule task-switching into your day to give your brain a break.  If you work on the same project for long periods of time, you’ll lose a lot of time banging your head against the wall.  It’s best to switch tasks every couple of hours — for example, between a major project, an algorithm exercise like exercism, and doing mock interviews with other students. Set a notification to remind you to switch tasks.  When you come back to your project, you’ll have clear eyes and often be able to pinpoint your problem right away.