As a woman in computer science

Some people have been asking me what it’s like working as a women in a male-dominated field. I can tell you that sometimes it isn’t easy dealing with the feeling of being an outsider at work but I also have to admit that things have been getting better for women in technology over the past years.

The overt staring and glaring at my body that was common during the 90s has been replaced with small glances and innuendo. It could be a testament of the fact that I’m getting older and I don’t look like how I used to but I believe that society has been changing over the years to be more accepting of women in roles like this.

I remember when I was just a little girl and I told my father that I wanted to be a computer programmer when I grow up. He laughed. Maybe he thought it was funny that at eleven years of age I knew what I wanted to do with my life or maybe he thought that females and computer don’t go together. I’ll never know what he thought.

Look. I’m not a radical feminist but I know that I deserve equal pay for doing the same work. When it comes to salary negotiation, women are given a low-ball offer and then shamed for not accepting it. Salary negotiation is tough for men but it’s near impossible for women. The cards are stacked against you.

I don’t know what I’ve been rambling about but I wanted to get this off my chest. It has never been easier to be a women in computer science although it is never going to be as easy as being a man.

As a woman in computer science

Configuring Git for high productivity coding

Git is a powerful version control system which is used extensively here at Amazon. We use it to version our Python, C# and Java code as well as other scripts. The good thing about Git is that it is highly configurable with aliases and hooks.

Aliases allow you to create a shortcut of a very long command using a shorter command. For example, if you want to do a ‘git log’ with extra parameters which change how it is displayed then you can make an alias for that command with a shorter command. In my gitconfig file I’ve got a bunch of common aliases plus some personal ones that I’ve come up with in order to save time. Read this guide for setting up git.

Another way of configuring git is by using the hooks feature. Hooks are scripts that are run when certain git commands are run. The ‘pre-commit’ hook is run to check certain things about what you’re commiting and it can even return messages to you if you’ve forgotten something. Another very common hook is the ‘post-commit’ hook which can be used for sending out emails or Slack notifications upon a successful commit.

At Amazon we use a bunch of these hooks for things such as collecting metrics and triggering unit tests to run. Hooks are also the basis of continuous integration systems such as Jenkins and Gerrit but those are beyond the scope of this post.

Sure there are some areas of the company that still use Subversion or another subpar VCS but Git is clearly the winner at this organization and most teams use git very effectively. I would recommend that you learn how to configure your environment with git aliases and hooks to make your workflow more smooth.

Configuring Git for high productivity coding

Overview of QA processes in Amazon’s Search Experience Team

Amazon is a fast-moving company but something that we don’t neglect is our testing framework. We’ve built up this testing structure over the years which allows us to confidently push changes out to our live site. The search experience team is focused on improving the quality, speed and accuracy of search results on Amazon.com with a focus on improving revenue.

Our team methodically tracks different search metrics over time and we run search simulations on our Hadoop clusters in order to determine the optimal algorithms for search procedures. We have a passion for improving these metrics for speed, quality and relevancy. Any irrelevant search results are seen as a critical defect on our team.

All of our server-side automation is taken care of by Python scripts, plus we have Javascript and Perl test drivers that automate functionality from the front-end. This multi-lingual approach is requried due to the specific technologies that Amazon uses which I won’t dwell to much on because it is a trade secret.

One thing we try to drive on our team is test automation. Because manual test are cost a lot of money for very little return, we try to shamelessly automate everything that we can. We want all of our tests to be automated and have important metrics returned and visible on a dashboard where we can investigate problems before they are pushed live.

In a later post I’ll mention a specific testing framework that is very useful.

~                                                                              

Overview of QA processes in Amazon’s Search Experience Team