Melissa Marshall

Programming, the tech industry, feminism. Plus, occasionally, cats and space.

[melissavmarshall]

Book Review: “Thanks For The Feedback”

Every six months I face a performance review at my job, of which a major component is collecting direct feedback from your colleagues. This never fails to send me into a full blown panic – I start to doubt my tech and consulting skills and nitpick every small slip-up I’ve ever made. Hence, the panicked Amazon buy that was “Thanks For The Feedback”. 

Unlike most things I buy online late at night in an anxious haze, this was a fantastic purchase! Most books about feedback teach you how to give feedback; this one teaches you how to receive it. It starts by making the great point that a) most people don’t know how to give good feedback and b) that you get feedback all the time that isn’t a direct “here is some feedback for you” conversation. For example, a break-up, losing your job, and the eyebrow raise your coworker gave your outfit are all feedback in one form or another. After giving a brief overview of different types of feedback – evaluation, coaching, and appreciation – it starts to focus on how feedback affects us and why. Some feedback triggers us because it hits too close to home, others because of our relationship to the receiver, and still more because it clashes with our view of our own identity. Finally, the book digs into how to respond to different sorts of feedback, and how to make a conversation productive regardless of if you take the advice to heart or not.

There are a number of things I loved about this book, first being that it recognizes that different people respond to feedback in different ways based on their innate wiring. Some people are more sensitive than others and are more affected by positive or negative feedback. The book teaches you how to recognize this in yourself and prepare yourself appropriately. I also loved that so much time is devoted to learning how to properly listen to people and trying to understand where feedback-givers are coming from. Listening for the core truths in what a person says is so invaluable in any situation, not just a feedback one. It also gives you tools to make that person feel heard and listened to, and how to graciously reject feedback you feel is truly off the mark. Finally this book is absolutely packed to the margins with examples of feedback and conversations to illustrate drive the authors’ advice. It’s refreshing to read something that not only tells you what to do but gives concrete examples of how to do it.

I would recommend this book to anybody, and especially consultants for whom listening to (and actually hearing) your clients is such an important skill. This is a book I’ll hold onto for a while because I think will take a some time to fully absorb it and put their advice into practice regularly. However, it makes the process of gathering and responding to feedback feel less of a mountain and more of a molehill, and for that I am very grateful!

[anitaborginstitute]

CEO of the Anita Borg institute, Dr. Telle Whitney, is sharing her views and the initiatives of the Institute with NPR for #raceOnTech. Join the conversation on Twitter!

[melissavmarshall]

Reddit Chief Engineer Bethanye Blount Quits After Less Than Two Months on the Job

Blount's exit comes less than two months after she joined Reddit from Facebook.

Sad but not surprising.

[melissavmarshall]

Objective-C: Getting Started

I've been working on a project to build an Objective-C framework for about four months now. This post is intended to give you an overview of the landscape of Objective-C development – what tools, frameworks and resources you can expect to use as you work. Hopefully this will be useful to developers moving into mobile! Please note that my experience with Objective-C has been building hybrid mobile apps for a corporate client only so I expect my list will reflect by that (i.e. I know next to nothing about storyboarding and the CI tool I use shall not be named for its terribleness).

Setting Up

What kind of a machine do you need to be an effective dev workstation? Probably a Mac. Technically you can develop on a Windows machine but save yourself a migraine or two and use a Mac if at all possible.

Mindset

All praise be to Apple, our benevolent overlords. Be prepared to spend hours trying to implement something only to find you literally can’t because they say no. Accept that Apple has very strong opinions and try to roll with it.

Keep in mind that if Apple didn’t develop it they are going to strongly discourage you from using it, even if it’s a fantastic tool. For example, Apple will tell you not to use CocoaPods, a very popular dependency manager for iOS development. This is just bad advice. Do not take the Apple documentation of what you can and can’t do as absolute truth. 

You have a choice of sticking to Apple’s official choices and receiving a lot of support from them or trying to break away from their recommended stack as much as possible. This is a tradeoff you should make very carefully; when you choose a tool that Apple doesn’t recommend pay close attention to how much community support it has. Also remember that non-Apple-sanctioned technologies that make it into your app can get your app rejected from the App Store (often Stack Overflow will be able to tell you if this will happen with a particularly library/framework).

Resources for Beginners

Blogs

Many blogs now understandably focus their writing on Swift rather than Objective-C; expect to search through blog’s archives rather than their latest stuff.

Ray Wenderlich has a ton of iOS tutorials, articles, library recommendations, etc. You are guaranteed to run across his articles at some point in troubleshooting your iOS code.

NSHipster is easy to read, focusing on all types of iOS development and Apple news. 

iOSDeveloperTips is another blog you’ll run into a lot if you google your errors.

Articles

iOS BDD Beatdown - a very thorough comparison of a bunch of iOS testing frameworks.

XCTest: The Good Parts

Resources

Apple Developer Docs is your source of truth... mostly.

StackOverflow is your friend; often the official Apple docs will say you can’t do something – go to SO to check that this is actually true.

Tools

Unit Testing

XCTest is XCode’s built-in testing framework. Use it mostly for unit tests; it does its job well and as of 2013 has command line support and test running from within XCode. Not a bad default. Side note: OCUnit/SenTestingKit were merged into XCode and eventually re-written as XCTest. You’ll run into references to these all the time but they are essentially obsolete unless your codebase is ancient.

GHUnit is another unit testing framework – doesn’t seem terribly well supported or commonly used (I’ve never used it personally).

OCHamcrest is a library of matchers for use with testing frameworks. You can also write your own matchers. Neat!

BDD

Kiwi is a useful and popular BDD framework.  

Cedar is another popular framework by Pivotal Labs. Rated as better than Kiwi by iOS BDD Beatdown (link above in the articles section) for its ability to run focused tests and its good documentation.

Specta is another standard BDD framework for iOS. It claims to be more lightweight than Kiwi or Cedar (I have no idea how true that is). You’ll definitely want to use the matcher framework Expecta with this one. Seems to be losing the popularity contest to Kiwi and Cedar.

 Mocking

OCMock is basically the mocking framework for Objective-C. It has support for a bunch of stuff like class mocks, partial mocks, and observer mocks. It boasts some pretty decent documentation plus a strong community for when you need help. Becomes ultra-powerful in combination with OCHamcrest.

OCMockito is a less popular but definitely viable (and well-supported) alternative to OCMock. Especially if you’re used to using Mockito for Java development, this might be a nice place to start.

Acceptance Testing

Calabash is a really nice acceptance testing framework. It supports cucumber for easy-to-learn-ness. 

KIF stands for “Keep it functional” and aims to be a lightweight and easy to use functional testing framework. Some caveats: including KIF in your production code can get your app rejected from the app store and version 2.0 is not backwards-compatible with 1.0.

Frank is a Cucumber-based acceptance testing framework similar to Calabash. Claims to be “Selenium for native iOS app”. Bonus: created by an awesome ThoughtWorker, Pete Hodgson! 

Dependency Management

CocoaPods is a fantastic choice for iOS dependency management. Easy to install, easy to use, widely used and supported, this is an excellent tool overall. Note that it’s easier to start a project with CocoaPods than it is to migrate (since it changes the environment you work in considerably) so you might want to include it up front.

Carthage is a lightweight, unintrusive dependency management tool. Definitely consider it if you’re introducing dependency management into an existing project or you just don’t want to deal with the craziness of CocoaPods like a whole new workspace file.

Logging 

Caveat: I have used none of these logging frameworks so essentially this is just a summary of what I think of their Github docs ¯\_(ツ)_/¯  Can someone give me a good use case for when you should start prioritizing a logging framework? 

CocoaLumberjack seems well-supported and easy to use, especially as it preserves the format of the default NSLog. Also claims to be an order of magnitude faster than NSLog which, if true, is impressive.

LibComponentLogging-Core is a small logging library that adds conditional logging and log levels. The syntax is essentially just a C macro.

NSLogger looks a little crazy on first glance! Its authors describe it as a “high performance logging utility”. It has a desktop logging console which is useful I guess? It strikes me as the fancy sports car of logging frameworks – cool but possibly a lot more than you need.

Build 

For the most part you are locked into Xcode and its command line utilities, although you could build a wrapper around these if you really felt like it. Be prepared to struggle a lot at first with finding the appropriate flags, deployment targets, linking settings and certificates.

CI/CD

You can use your CI tools of choice for your Objective-C apps but keep in mind that some will be easier than others. In my day-to-day project we use a Gradle plugin for our pipeline to run our Xcode command line build, test and package commands. Apple has its own CI tool called Xcode Server but pick a tool that gives you what you need, not just one that fits in Apple’s official stack. Particularly if you’re developing other types of products (web-apps for example) alongside your Objective-C app it makes more sense to align your CI tools to match.

Deployment/MDM 

Apple’s Device Enrollment Program (DEP) is a pretty handy way to configure your iOS devices straight out of the box. You can turn on or off most settings through this program and do neat things like drop a device directly into single-app mode. Use this in conjunction with a mobile device management program.

There are so many iOS MDM vendors I don’t know how you go about picking a single one. I am most familiar with AirWatch which is okay. It gets the job done despite a sometimes confusing UI and hack-y workarounds to push settings to devices. It does, however, work pretty well for large-scale deployments.

IDE 

The problem with any non-XCode IDE is that your application’s project file, where the build settings are stored, is incredibly difficult to understand, parse and edit without breaking anything. XCode has a very nice wrapper for this project file and you will need to use it to edit the build settings unless you are very, very sure you know what you’re doing.

XCode. You will have to use XCode at some point even if you do most of your building and testing in the command line. Get familiar with it.

AppCode basically looks like JetBrains took IntelliJ and did a find and replace to add iOS development to it. It could be a useful alternative to XCode but straight out the box it is unintuitive and clunky. Also you’ll still have to have XCode for some stuff anyway.

Use your own text editor! ...but you’ll have to use XCode at some point.

Obviously this is not a comprehensive list of all the Objective-C development tools you could ever need. What other tools or categories of tools do you think are essential to beginning Objective-C development?

[anitaborginstitute]

“You don’t manage people, you lead people. You manage things.” - Rear Admiral Grace Murray Hopper

[melissavmarshall]

Technology is not neutral, and a technology that a billion people use to communicate has the power to warp and change reality around itself.

https://medium.com/@zip/my-name-is-only-real-enough-to-work-at-facebook-not-to-use-on-the-site-c37daf3f4b03

[melissavmarshall]

Hybrid Mobile Apps: An iOS/JS Demo

I’ve spent the last 8 months working on something I’d literally never heard of before: hybrid mobile apps. It feels like I must have been living under a rock not to have heard of these before - there are so many frameworks available for building this type of app. If, however, this is the first time you’re running into these, the idea can be a confusing one. Why would you bother to combine two quite separate technologies and how do you do it?

Say you want a standalone app that can access all the fancy hardware on your device like its GPS or accelerometer; build a native app. If you want to build out a complex, stylish UI, like something you’d see in a browser, a responsive web app may be your best bet. Hybrid apps give you the best of both worlds. They also let your app be (sort of) platform agnostic. You could theoretically take your iOS-web app and convert it to an Android-web app - although in reality porting is often more work than you expect.

I’ve been working specifically on hybrid Objective-C and AngularJS applications. On your iPhone or iPod you tap an icon to launch the app, which launches a mini browser which in turn loads your web app. It sounds a bit Frankenstein-y (and it can be, done poorly) but it works better than I had anticipated.

I put together a very simple demo app using Objective-C and ExpressJS (since it’s a lot more lightweight than AngularJS) to document the main points. If you want to see the full code and follow along, go ahead and clone it from Github (but keep in mind this is not a tutorial). All the app does is let you click a button which uses the device’s GPS to find where you are and spits back your latitude and longitude. Thrilling, I know.

From the UI to the device

First things first, I need a button. Here’s one (styling stripped) that calls a method when it’s clicked:

<button type="button" onclick="locateMe()">Locate Me</button>

And here’s the function that gets called when I click it:

function locateMe() { var xmlHttp = new XMLHttpRequest(); xmlHttp.open("GET", '/findMe', false); xmlHttp.send(null); }

Awesome. XMLHttpRequest is a handy Javascript object that lets you make calls and retrieve data from URLs without actually sending your user anywhere. In our case I’m going to use it to make a dummy HTTP request that our native Objective-C will be listening for and ready to intercept. As you can see the JS is making a get request to the ‘/findMe’ page (which doesn’t exist).

Intercepting the request

Before that button is ever clicked, it needs to be displayed on a page. Do that the mobile app needs to open a web page. I do this with the WebApp.m class:

+ (WebApp *) appWithWebView:(UIWebView *)webView {    return [[WebApp alloc] initWithWebView:webView]; } - (id) initWithWebView:(UIWebView *)view {    self = [super init];    if (nil != self) {        self.webView = view;        [self loadWebApp];    }    return self; } - (void) loadWebApp {    NSString *path = @"http://localhost:3000/";    NSURL *url = [NSURL URLWithString:path];        [self.webView setDataDetectorTypes:UIDataDetectorTypeNone];    [self.webView setDelegate:self];    [self.webView loadRequest:[NSURLRequest requestWithURL:url]]; }

When the web view is initialized, the ExpressJS web app (running locally in this case) is loaded onto the page.

But before even that can happen, I need something to initialize and load the WebApp class. This happens in the main view controller in the Objective-C code, the obviously-named ViewController.m:

- (void)viewDidLoad { [super viewDidLoad];    [self createWebApp];    [self registerRequestHandlers];        LocationController *locationController = [LocationController sharedInstance];    [locationController initLocationManagerWithDelegate:self]; } - (void)createWebApp {    self.webApp = [WebApp appWithWebView:self.webView]; } - (void)registerRequestHandlers {    [NSURLProtocol registerClass:[LocationRequestHandler class]]; }

The very first thing this class does (besides calling the superclass) is to create a WebApp object and hold onto it for later. This starts the page initialization and will be useful later on for sending information back to the Javascript UI. The view controller is linked through XCode’s storyboard feature to be created and loaded when the app starts (I’m going to call a complete understanding of that out of scope of this post for now).

The next thing that happens when the view loads is a call to Objective C’s NSURLProtocol class to register a request handler class. By registering a class, the system knows to check if the class can be initialized when a particular URL is loaded. You can think of these as event listeners, where instead of an event you’re listening for some URL to be loaded. 

Also notice that when this class loads it creates an instance of a LocationController object and set the controller’s delegate to the view controller - important for creating and intercepting callbacks later on.

Let’s take a look at the request handler class, LocationRequestHandler.m:

+ (BOOL)canInitWithRequest:(NSURLRequest *)request {   return [request.URL.path caseInsensitiveCompare:@"/findMe"] == NSOrderedSame; } - (void)startLoading {    NSHTTPURLResponse *response = [[NSHTTPURLResponse alloc] init];    [self responseWithStatus:200];    self.location = [LocationController sharedInstance];    [self.location startUpdatingLocation];    [self finishLoadingResponse:response]; }

The method canInitWithRequest is interrogated every time the URL loading system gets a new request. The first registered class that can initialize with a particular request gets to handle it. In this case, the request handler can initialize if it comes in with the path ‘/findMe’.

When the request handler, the startLoading method is automatically called. We access the LocationController singleton and start trying to get location updates on the device. I’m not going to go into the details here, but I’m using the CLLocationManager class to start location tracking and handle callbacks when the device finds a new location. Check out the code and do a little digging in the LocationController class for more information.

...and back to the UI

So we’ve clicked a button which sent out a dummy HTTP request, then we’ve intercepted that request and used it to start a request for the device’s updated location. What happens now when that information comes back?

CLLocationManager will eventually come back with a callback containing the new location data. The LocationController.m class intercepts this data - it was set as the delegate for CLLocationManager when we initialized it way back when the view controller was loaded.

// The callback from CLLocationManager - (void)locationManager:(CLLocationManager *)manager didUpdateLocations:(NSArray *)locations {    NSLog(@"Locations updated");    [self stopUpdatingLocation:[locations objectAtIndex:0]]; } - (void)stopUpdatingLocation:(CLLocation *)pos {    NSString *latitude = [[NSNumber numberWithDouble:pos.coordinate.latitude] stringValue];    NSString *longitude = [[NSNumber numberWithDouble:pos.coordinate.longitude] stringValue];        [self.locationManager stopUpdatingLocation];    [self.locationDelegate locationUpdatedWithLat:latitude andLong:longitude]; }

When the success callback returns with a new location, the location controller parses that information, tells CLLocationManager to stop trying to update our location, and calls another delegate method. When the view controller instantiated this class it also set itself as the delegate - so calling  locationUpdatedWithLat takes us back to ViewController.m.

- (void)locationUpdatedWithLat:(NSString *)latitude andLong:(NSString *)longtitude {    [self.webApp reportLatitutude:(NSString *)latitude andLong:(NSString *)longtitude]; }

In the view controller we’re simply passing information one layer closer to the Javascript UI. Using the WebApp object we created when the app loaded, we can send our latitude and longitude data back to WebApp.m.

- (void)reportLatitude:(NSString *)latitude andLong:(NSString *)longtitude {    NSString *jsCallBack = [NSString stringWithFormat:@"reportLocation('%@', '%@')", latitude, longtitude];    [self.webView stringByEvaluatingJavaScriptFromString:jsCallBack]; }

Here we’re squishing our latitude and longitude data into a call to the function reportLocation(). Then we call stringByEvaluatingJavaScriptFromString - an absurdly named, but very handy function that runs pieces of Javascript and returns you the result. In our ExpressJS app, we pick up the call to reportLocation() and update our HTML accordingly. Because there is very little Javascript overall, I’ve left it all in index.html.

function reportLocation(latitude, longitude) {   document.getElementById("latitude").innerHTML = latitude;   document.getElementById("longitude").innerHTML = longitude; }

And there you have it! We have two layers of code interacting smoothly back and forth with each other. You might be able to tell in this screenshot that I’ve added Bootstrap styling.

Not exactly Flappy Bird, but still, a neat concept. 

What experiences have you had building hybrid mobile web apps? Feel strongly about whether hybrid apps should be used over all-native ones? Let me know below.

[melissavmarshall]

Working With 3rd Party Vendors

In agile software development, self-direction and control is key. As teams we write stories, estimate them, and play them. What we do, when we do it, and how we implement it all is up to us. In contrast, a 3rd party vendor is something you have very, very little control over. Because of this, agile software teams are typically awful at working with vendors, particularly those with different software delivery processes than our own. When we can’t directly control a piece of our process and alter those that aren’t working, the process can easily break down.

Have you ever had a burn up chart look like this?

That inflection point is when your vendor delivered something and it sucked. Like, really really sucked to the point where your entire team got blocked until the vendor’s next delivery. And then that delivery sucked too. 

So how do we keep our product owners and project managers from crying themselves to sleep at night? Here are a few things I’ve learned the hard way.

1. Know what you want

Imagine sitting down for dinner at a fancy Italian restaurant. The waiter comes over and asks you for your order. “Hmm, I’m not sure. Surprise me!” When the waiter puts down a plate of something you hate in front of you, you don’t now get to scream at the poor guy. If you don’t know what you want, you’re going to get someone’s best guess instead. You might get the best damn lasagna ever made but if you were deep-down craving spaghetti you’re probably not going to be happy.

Finding out what you want is going to take some work. If you’re working with anything customer-facing, hardware or software, prototype it (and prototype, and prototype some more). Then test your prototypes with actual, real-life customers before even googling a potential vendor. If instead your vendor deliverable is something a development team will be working with, then ask developers what their ideal deliverable would look like. It sounds obvious, but team leads (who are often non-technical) are not the best people to ask what their team needs from a piece of software.

It might take some time to do this iterative design and testing upfront but it will save you quite a bit of time and money compared to having to re-do the whole project later with a new vendor.

2. Ask for what you want

So you know what you want, now you have to ask for it. When searching for vendors be up front and explicit about what you’re looking for. Find out what products they sell that are closest to what you need. If you have the budget you can ask if they can alter an existing offering or create something custom for you.

If your vendor can’t meet every need you have (and they probably won’t be able to), try to prioritize what you want and be prepared to kill your darlings. Also think about what kind of delivery cycles and responsiveness you’ll need from your vendor. If you have to sacrifice a few desirable features to work with a responsive, continuously-delivering vendor, do it.

3. Have a single point of contact with your vendor

If you have multiple points of contact with your vendor they will both a) not be able to make meetings at the same time and b) not catch up with each other about the meetings/emails they have each received and missed. This will end up with you having a testy phone call with one or the other about why they’re pushing back the delivery deadline or the functionality doesn’t match what you’d asked one of them for. It will be unpleasant.

Avoid this situation by having a single person to communicate your needs to and to inform you of their delivery expectations. Caveat: if you have multiple projects or products ongoing with this vendor, ask for one point of contact per project. An overwhelmed and overworked vendor representative is only going to end up disappointing both parties.

4. Make them a part of your team

People like working with nice people; they like to feel needed and included. Liking your coworkers not only makes you more satisfied with your job, it can actually affect how you feel about life in general (source). Research also shows that the more satisfied people are with their jobs, the better they do them (source).

Knowing this, it makes sense to ensure your vendor’s point of contact feels, as much as possible, that they are a valuable and liked member of your team. If they’re local, hold your meetings with them in person as frequently as makes sense. If they’re too far to visit regularly, make sure to get at least a few days of face time with them early on. Ask them to join your daily standups, your HipChat or Slack group, and any other forms of continuous casual communication your team uses. And be nice - say thank you when they help you out and let them know you appreciate the work they’re doing to develop your tool.

6. Push for small, continuous improvements to your deliverable

Big product releases are scary. They’re even scarier knowing that when (not if) you find bugs it’ll take a month or more to get a fix for them. They also require your team to sink a lot of valuable time at once into getting the damn thing integrated and working.

Getting your vendor to deliver small but frequent iterations of a product as it develops is probably the hardest thing on this list to accomplish (and as such I don’t really have any concrete advice on how to do it reliably). This is especially true the larger (and more waterfall-happy) your vendor is. Expect it to be downright impossible for some companies. 

If you can’t get frequent deliveries at least get frequent updates - remember how your vendor point of contact should be attending your daily standups? Ask them to update your team on progress their team has made, and keep a running log of issues and features they’re working on. It’s better to get a huge delivery of something you’re expecting and know what to do with than to get a big unknown dropped into your lap. It will also help your vendor to be more upfront about the challenges and potential date changes they’re facing.

5. Go ahead and bitch, but keep it private

Bitch about your vendor - at some point in your project you’ll have to if you don’t want to tear all your hair out in frustration. It’s the nature of working with something so wholly out of your control. But be careful! Complain to your roommate, or your spouse, or your cat as much as you want (unless they tell you to shut up). Try not to gripe too much in your project area; grumble about it a bit with your coworkers and then move on for morale’s sake. If you really must bitch about it at work, check that your vendor isn’t dialed into a call being held in the room. They will hear you. It will be super awkward. Trust me.

How do you feel about working with 3rd party vendors? Any totally awesome vendor experiences to share? Any hilarious horror stories?

[melissavmarshall]

What Women Get Wrong About Women In Tech

A few weeks ago I attended an event for women in software engineering at Glassbreakers, a startup aiming to build a network of women in the technology industry based on shared experiences and peer mentorship. The event was fairly typical of a tech networking event in San Francisco: held in a startup’s beautiful, open-floor-plan office, with free alcohol and mingling before the main event, which was a panel on mobile development. I’m usually surprised and thrilled to walk into any technical event where most of the people in the room are women, and overall I think what Glassbreakers is doing is awesome. But as the panelists introduced themselves and the Q&A began, I felt an increasing exasperation at the ways in which we fail ourselves when we talk about women in the tech industry.

Events like this have noble goals - to connect women facing similar struggles, build a community around those experiences, and create a space for us to rise together through an industry where we are consistently the odd ones out. However, in their execution they rarely seem to spark industry-changing decisions or conversations. Here are a few thoughts on why this happens and why over time this is so incredibly frustrating.

1. We Don't Care Enough About Intersectionality

The movement around women in tech, at least in my limited San Francisco based experience, is dominated by young, white women who work at startups or tech titans like Twitter and Google. 

I am one of these women (minus the startup experience) and although working in the industry while female is difficult it's important to recognize that I'm sitting on the easy side of the privilege spectrum. The women on the Glassbreakers panel on mobile development were also all white women working at startups or large tech companies with less than ten years industry experience. If we want to be taken seriously when we talk about the necessity of diversity in technology we need to practice what we preach. We need to represent software engineers of color, women over the age of thirty, trans* women, and women that don’t fall in any of these boxes as necessary and indispensable to our endeavors. How are we supposed to learn from their struggles and their triumphs when we don't ask them to be on panels, speak at conferences or join companies? When we push wealthy white women to the top of the industry and call it success we make gender discrimination in tech worse. The issue can be safely ignored by those who can now say: "Look, she made it, so you can too!"

2. We Celebrate Fear Instead Of Our Accomplishments

Fear dominates a lot of conversations about women in technology. We confess how afraid we were to start programming, how hard we still find it, how much you will struggle, how much you will need other people's help, and how hostile the industry is. It's fine, important even, to be afraid and to acknowledge that fear. But fear without action, and fear in an echo chamber is dangerous. It leads us to focusing on what scares us rather than what we can do to overcome it or despite it. It's fine to be afraid. I'm afraid so much of the time it’s unbelievable. But it's the things we do despite being afraid that make us awesome engineers.

We should also think carefully about the message we send to girls considering careers in CS when we stand up in a room full of engineers and talk about how technology and working in this industry is difficult. You don't get brownie points for having faced the most sexism on the job so let's stop trading horror stories like badges of honor. Without context these stories can easily turn women off coding entirely. And among each other it’s too easy to minimize one another's experiences by playing the one-up game.

It's important to acknowledge that what we do is hard, and that it's ok to be afraid. But we spend so much time talking about how afraid we are and so little time on our actual accomplishments. Past a certain point I feel exhausted discussing how hard the IT industry is - instead, tell me about that robot you built, or that web-app you wrote, or that company you launched. Goodness knows I could use the inspiration to keep me going through the crappy bits of the everyday.

3. We Confuse Friendship And Respect

There is a stereotype of the female geek that many women in tech conform to at some point or another in their lives - cute but not trying too hard, she loves video games and indie bands and most importantly she's one of the boys. She is unfailingly likable, effortlessly cool, and smart (but only in a vague, nonthreatening sort of way). The pressure to conform to this image of female nerdom seems to be particularly prevalent in startup culture where youth and hence immaturity rules. During the question and answer portion of the panel a woman stood up and said she didn't think her all-male team liked her very much - she was having a hard time connecting with them, and it was leading to things that affected her ability to do her job like being left out of impromptu hallway meetings. One panelist's recommendation was to address it head on with the team, asking to be invited to the meetings over and over until they relented. Another was to ask the men on the team for help with her work so they would like her more (rooted in psychology research but disempowering nonetheless). 

At no point did any panel member tell this woman that she didn't have to be friends with her teammates. To be successful at work you need team members who respect you and your work not necessarily people who will invite you to their LAN parties. Outside of startups this becomes more obvious - when your colleagues are middle aged men with kids you care less about trying to get everyone out to the bar on Friday night. The notion that you have to be friends with, or even well liked by your teammates to be a useful, respected engineer is an insidious one. Energy spent wondering why boys on the team don't invite you to play foosball is energy not spent becoming a better programmer or meeting people who are more mature than to write women off as coworkers.

4. We Think It’s Our Job To Fix It

Gender inequality in the tech industry isn't going to go away once we lean in hard enough, suck up to our male colleagues and dress the part. There are structural injustices embedded in tech culture that are not our obligation to fix. It's not our fault that people see a female name on a resume and perceive her as less competent. It's not our fault that women are systematically paid less than their male counterparts. It's not our fault that men are hired for technical positions more than women on the cultural assumption that men are more suited to the part. And it's certainly not our fault that women are harassed and assaulted and subtly made to feel less than human on a day to day basis.

So why is fixing the tech gender gap our problem? I'm so tired of being given advice on how to survive the assholes, and the not being taken seriously, and the lack of role models. Where are the panels on not being an asshole in tech? Where are the seminars on not harassing people at conferences? When will we start holding trainings on recognizing your own biases in the workplace? It's hard to explain just how exhausted I feel by the whole thing. And attending events where the advice is make friends, ask men for help and one day maybe someone will deem you important enough to move into management and slightly further away from the bullshit is so, so disappointing.