Different Motivations of Male and Female Software Developers and How We Speak About Our Work

I’m not the whiny type.
Throughout all these ‘women in tech’ discussions I’ve always been against all feminist view angles.
I’ve always thought ‘Shut the f*ck up, do your sh*t, behave like any other person and all will be well’. I’ve always refused to become paranoid and interpret everything that happens to me in the light of my gender.

But I must admit I’ve gotten to a point of being exasperated of hearing that I ‘didn’t go deep enough’ when talking about my work, meaning people perceived me as less technical – although admittedly and luckily it’s more the exception to the rule.

I’ll work my way through this post, trying to point out misinterpretations on both sides, which could easily be avoided if we’d approach tech interviews with less prejudices and with an awareness that men and women may have different motivations behind software development, that they express their love of software development differently.

Important to note that I’m not affirming any of these two attitudes is better or worse. I’m saying they’re different, and we should be aware of it.
Neither am I saying all men have this view, and all women have the other view. And of course there’s men who feel like me, and women who feel like the men, the people I attribute excitement about technology and not about the outcome to.

Now back to the topic.

Yes, I am a woman and yes I also do UX design, but by no means does that imply I can’t code. My CV contains much more coding work than UX, and is mainly targeted at development work. It contains roles such as “Senior Mobile Developer”, “Software Developer” and “Mobile Developer and UX Designer”. I have a degree in Media Informatics from one of the top unis in Germany, have done mobile development in both my bachelor and my masters thesis. I have done native mobile development building dozens of apps of all complexities, backend and CMS programming within a project of maximum complexity, with thousands of classes, with dozens of people having worked on it over the 5-6 years of its existence, worked with search technologies, did top notch front end development and built complex testing frameworks, which clearly reflects in my CV.
Nonetheless people ask me unbelievingly ‘So I’ve seen you do UX… Do you also code?”

Some people look at me in awe at the interview table when I give high-level details on the projects I’ve worked on, but somehow don’t even bother to ask specific technical questions about that project, some even providing me with a weird smirk, which somehow seems to say ‘Yeah right, you’re a young pretty lady, what could you possibly know about development.’
Or I get asked ‘Hm, so you worked with the Play! Framework, heard that doesn’t perform so well..?’ and my counterpart feels unsatisfied if my answer to that is a short ‘Well, we had Elastic Search on top of the MongoDB, which of course helps and a Varnish cache.’ What should I have said, start giving you code examples where Play! scales badly or start a debate?!

Some people interpret that if I don’t explain in detail how exactly I implemented these projects it means my technical knowledge is shallow.

While I just don’t see the point of talking about one project for 20 minutes, and prefer giving a good overview of my work and letting my counterpart pick the topics he/she found interesting and ask me more technical details, which I’ll be happy to answer, but in a concise and probably not super-nerdy manner – especially when it’s a phone interview. Not by going through code, mentioning specific details in a framework or whatever, because once I’m done working with it, I don’t dwell on it for ages. I’ll probably need to re-check for implementation details, because I care that the newsfeed application I built is really ace, not about every tiny problem there was along the way.

It gets even funnier in the relatively new field of mobile development, which has only truly begun around 2008 with the launch of iOS and Android. Experts in this field will be relatively young. When your future work involves coaching mid 40yr old males who’ve done Java development their entire lives in Android development, things get awkward, because at that age it’s probably hard to accept that a younger person, a woman even, has more experience with it. Sometimes you feel like people think ‘At least if she’d been a 28 year old dude… But she doesn’t even look like the female version of Steve Urkel!”
This is one of the typical situations I’ve always refused to interpret in a gender-based fashion and told myself “Maybe it was just me doing a poor job explaining or maybe they already had made up their mind for another candidate.” But now I realise I prefer talking about the product and its complexity and I’ll explain how I implemented it in detail only upon request, which in turn may let the man across the table think that I couldn’t add any value to his expertise. It only reinforces the perception gap, when in reality both sides could learn so much from each other.

I’ve probably been in dozens of interviews and never has the technical interview been led by a woman.
‘So what!?’ you will ask. And I will tell you it does matter, because as I said, males and females have different motivations for writing code and thus a woman will probably bond better with another woman, because she’ll know to ask the right questions.

I don’t mean to generalise, don’t get me wrong, but the past years I’ve been reflecting a lot on my motivation behind doing software development. It’s building gorgeous, well-performing digital products, that people adore using and that helps people achieve their goals. I love the outcome and I care about the team I work with to develop this product.

I thus care about the UI and I care about code quality, legibility and simplicity. If someone takes over my code, I want them to easily understand what on earth I wrote there. And I care about code performance, but not because it thrills me that the log prints 0.56sec instead of 0.62sec, but because this makes the user experience better.

I see software as a tool, and I only develop what’s useful and necessary. I don’t intrinsically care about how a tool gets me to my result, but that it does. If I need to review the tool, compare it against another to pick the best option, of course I’ll review the how-part. I do it because a better tool yields a better product, not because I happen to find the tool to be so cool (pun intended).

I don’t get high on the ‘nerdiness’ of my code. I don’t like using code patterns nested in code patterns over code patterns just because I can prove I know code patterns, and drive everyone around me nuts because the code is totally over-engineered. If there’s an Objective-C alternative when I code an iOS app I prefer using that one than some cryptic C code just to prove that I know C, unless of course I’m aiming at e.g. sharing complex algorithm code between my iOS and Android app via the Android NDK.

I like giving my variables a sensible name, not just ‘pvz’, leaving you in the dark to use IntelliJ shortcuts to inspect where the variable actually comes from and what it actually contains.

I won’t start inventing a new OOP language on top of C, just because I think the bracket syntax of Objective-C is crap. It’s the way it is, and I use it to code my product, because that’s how Apple defined it.

I don’t like reading a coding book and then discussing it with work colleagues as if I were in a book club. I don’t get excited about Futures in Scala. I think they’re really cool actually, and I read up on them and use them once needed, but I certainly won’t start a lunch break discussion with you on how we can rewrite all our code to use Futures just because I’m excited about it. If I come across a piece of code while I’m developing, I’ll nudge you and say ‘Hey look at this algorithm, what if we changed it to use Futures, that’d be faster and cleaner?’ and we’d start discussing, within a work environment, not at my daily break from the exhausting mental work I do.

And that ladies and gentlemen hits the spot when it comes to the difference between many male and female developers. Women get excited about the outcome, men get excited about how we’re getting there.

I see code, frameworks, programming languages and development environments as a tool, there’s not much excitement there about the tool, about what things I’d be able to build because the tool allows it, but no one really needs.
My excitement is about what I’ve built using the tool, that it adds value to the business and makes life easier for the user.

An analogy: I’m hanging up a painting in my living room. Once done, I’ll tell you about how beautiful the painting is, that it’s perfectly aligned with the door frame and perfectly perpendicular to the floor and ceiling, and that it has so much sentimental value to me because I got it from a dear friend. I most certainly won’t start to describe what hammer I used to hit the nails into the wall, discuss whether a metal or wooden handle is better and try to convince you to use the wooden handled hammer for all of your handiwork. Neither will I tell you what nails I used and what length and diameter they had.
Unless, of course, you ask me directly and specifically. And even then I’ll only tell you I used nails and a hammer.

And this reflects in the interview process.

If you’re giving me the example of a crash in iOS and tell me the order of calls that lead to this crash is non-deterministic, well, I will tell you it’s most probably a threading problem. If the you ask me ‘What’s DEADBEEF?’ I’ll tell you I have no clue. Why? Because as an object-oriented programmer I don’t care about hex codes indicating me low-level memory issues. If I see an EXC_BAD_ACCESS though, I’ll know it’s a memory problem, most probably caused by using a reference with a memory address to which the content either doesn’t exist anymore, or has been replaced by some different data. I care about it because I actually encounter it while working.

If you ask me what a NSZombie is, I’ll tell you you use it for debugging, when you force the system to keep objects around in memory that normally already would have been discarded.
Yes, if I was a code excited person I’d tell you the exact argument for the debugger and walk you through on how to set it up, I’d tell you you can detect cases where you send messages to already deallocated instances or instances that are invalid – the zombies! – because the initial memory content has been replaced and now is of a different type.

If you ask me what a protocol is in Objective-C, I’ll tell you it’s like an interface in Java, used for modularisation of code, where you only define what methods and properties a class must have, but leave the implementation to the class, making it easily exchangeable.
If I was a code excited person I’d tell you you can create private protocols inside implementation files, that delegates are actually implemented using protocols as well, that you can use the @optional keyword for non-obligatory methods and that @interface is not the same as @protocol.

If you ask me what a category is, I’ll tell you it’s an extension to an existing class, allowing you to add methods to it without any subclassing, so if you create a category on NSString, you import the extension header file in your code file and execute category methods on an NSString object.
If I was code excited, I’d tell you that I create a file called NSString+Extras.h and NSString+Extras.m, define methods in @interface in the .h and implementations of it in @implementation in the .m and then import NSString+Extras.h into some other .m file and then do [someStringObject myCategoryMethod:param];

But I don’t tell you all of this. Why? Because as an iOS developer who’s been developing since 2008, I don’t consider it necessary to tell you how you create a category. And I also have no exhilarating moment of fun explaining it to you in detail. I assume that the length and breadth of my expertise and the fact that I can explain a high level concept makes it obvious that I know what I’m talking about.

I’m pretty sure within 6 years I’ve come across categories, threading, Storyboards, NSLayoutConstraints, delegates, blocks, NSOperationQueues and what not and I’ll happily explain you the concept and what they’re good for. I most certainly won’t quote code examples of each by heart, because it’s not the kind of stuff that keeps me up at night.

I love coding because it’s challenging to solve a problem, not because I know so many buzzwords and don’t feel eager to hold a debate with you on whether it’s more efficient to create layouts in code or in Storyboards.

If you’re not sure whether I know if delegates use protocol definitions and you’d like to hear it, just ask me! If you want to test my coding abilities, give me example code to review, give me a coding task as a test or whatever else that will actually make you truly assess my competence.

Don’t just judge on the fact that I don’t get overly excited of the fact that I programmed a C-loop asking some atomic clock API for the exact time and don’t reproduce the code by heart. I just wanted to check the time, how I did it was serving my purpose and now my head’s busy with other stuff. If I’ll ever need it again, I can just check the code.

You’ll say my examples of either not being asked anything at all or expecting too detailed answers contradict each other, but they don’t. It’s actually a reflection of both a situation where the interviewer concludes that ‘you’re not technical enough’ due to the fact that their general attitude is that of non-belief in what I say. Either they don’t believe I’m capable of doing what I claim to have done, or believe I have no in-depth knowledge of what I claim to know.

And the ultimate root of the problem?
The root of the problem is that when a male developer starts in a team, people consider him competent until he proves otherwise, because he starts throwing around all sorts of technical buzzwords. If a female developer walks into the room, she is considered ‘the junior one’ who’s still got to prove she’s competent and towards each one has to act like a paternal figure, showing her around.

Again I’d like to emphasise I’m neither generalising, nor trying to offend anyone.

I’ve met brilliant people, who I’ve loved talking to about my work, teams with which I’ve loved working, to which I feel I’ve contributed just as much as I’ve learnt. I’m very thankful for the fantastic people I’ve been given the chance to develop great digital stuff with, it’s been an honour.

I’m just trying to verbalise a feeling many other female developers have but instead of putting it out there, tend to drag themselves down by just thinking ‘It is me, I really am incompetent.”, which is not the way to go.

I’m just trying to ask for more awareness when it comes to achieving better working conditions for both men and women in tech. There is a certain bias when coders talk to coders, but I’m also aware that the conclusion for me, from this post, should be that I need to practice forcing myself to go deeper with how I implemented something, and not what I implemented, even though I’m not that excited about the how. Otherwise I won’t land as many jobs, become more influential in my company or be promoted, since I’m interpreted to be less technical.

We need to be aware of the different ways people approach and view software development and learn how to conduct interviews to harness the maximum potential of each candidate we have sitting in our interview room.