Developers hate support, don’t they?

I'm at the end of my first official week doing support for 10gen. My major achievements are:

  • Learning how to work the coffee machine in the Dublin office. It's taken me a week to get it, but now I can understand the machine's needs. Even if my coffee did taste a bit of cleaning fluid this morning.
  • Navigating around Dublin - I led the way to the pub, followed by two people who live here. Turns out I know the most efficient routes between work venues and pubs, even in a town that I've never been to before.
  • Closing all outstanding Java driver pull requests, except for the one we want to merge but needs to be updated. This is a massive win for us, now we can actually stay on top of them instead of wondering which are valid and which ones we're actively ignoring. I hope the CTO isn't peeved I closed one of his from two years ago.
  • I got my highest scoring day on StackOverflow yesterday, receiving a "whopping" 67 points in one day. Be nice, I'm quite new to SO - despite being on there for over two years I'm really only just starting to feel comfortable there. One day I might actually ask a question.

In all seriousness though, I learnt a LOT this week. I've been with 10gen for about 9 months now, so although I feel like I should be a fully fledged member of the team there's still a lot I don't know about. In particular, as I hadn't used MongoDB before working here, and as I'm head-down on delivering the new Java driver (more to come on that later, I promise), I don't see a lot of how people actually use the database.

I've been lucky because this wasn't a heavy week for customer support, so I've been available to pick up "free" support - basically take a look at questions people are asking on StackOverflow and the MongoDB Google Groups and see if there's anything I can answer. Obviously I focussed on the Java side as this is the area I'm most comfortable (and there are only a few of us to answer those questions, and plenty of others to pick up more general questions).

So here are my Lessons Learnt:

Customers want to be heard

Responsiveness is almost more important to (paying) customers than detailed answers. They want to know that you've seen their problem, and you're on it. So sometimes it's best to answer a problem with a question or questions, asking for clarification on their situation and explaining any assumptions you have. It turns out that writing that long and detailed explanation of the steps they need to take isn't really necessary when you've figured out what they're really trying to do and response with "this is going to require production downtime". Suddenly it's not as urgent for them to fix this right now.

The Java Ecosystem is alive and well. In fact, it's a monster...

There really are a remarkable number of libraries/third party apps that people are using on top of our basic Java driver. This week, I've been trouble-shooting people using Morphia, Spring Data, Jongo, Grails GORM, as well as a lot of people who are using the driver directly. I've learnt a lot about installing and using all these things, as I've had to do that to reproduce people's issues and suggest solutions1. I've learnt that some of those things make life quite a lot easier, especially for the happy path of Java developers who simply want to save Java pojos into the DB and query for them afterwards.

I've also learnt that querying is quite inconsistent across all the libraries, and I'd say the main problem that users have is turning an understandable query from the shell into something that the library they're using understands.

Also, Dates get people every time, particularly in Java.

Where is the problem?

Related to the previous point, when a query returns nothing it's difficult to work out: if you're using the library incorrectly; if the Java driver doesn't support various options; or if the database isn't doing what you expect it to. More often than not the problem is not understanding how to use the tools (and the onus is on us, the library developers, to make it as easy and unsurprising as possible for developers), but sometimes it's a bug. Tracking down the root of the issue is important, because if it's a bug we should log it in the correct place, and if it's working as designed it suggests a lack of documentation or possibly a design flaw.

Having people to help you is dead important

I could have done this from home, from the London office, or even from the beach if I'd wanted to. However, I opted to come to our Dublin office where we have our EMEA support, because I knew that alone I'd try and dodge the work. Not because I don't want to do it, but because I don't know our processes, I don't know if we have a knowledge base I can use, I don't know if my answers are correct, and so on and so on. When you're uncertain, sometimes the easiest option is to run away. But when you're embedded in the team that does this every day, you can ask the stupid questions and get help rather than sit and feel stupid.

It's also nice to be part of a daily standup so you can hear what other people are up to, and it puts a (good) subtle pressure on you to do something so you have something to report.

What I like about support at 10gen

I've done support before. In fact, during my last year at LMAX I worked out I spent the same amount of time on the production support team as I did working on a team delivering new features. But since I've never worked for a product firm before, I haven't done this sort of support. 10gen makes its money by selling support contracts, so not only is it important to keep the SLAs with the paying customers, but it's also important to provide excellent quality support for them - with any luck they'll keep paying. It's also important for us to support those who don't pay - it's kinda like a teaser of the great quality they'd get if they paid us.

So the support organisation here is absolutely key to our bottom line.

The driver developers (of which I am one) are "strongly encouraged" to do a week of support every three months. We used to do days here and there, but blocking out a whole week to be part of the team, to be excused from your day job, and to leave your e-mail (and sometimes meetings) alone because you're busy doing support, works really well. I've felt very focussed on the support role during this week, and I've been motivated to do a good job. If I had been seconded to the team for a period of weeks, I would have dreaded the whole thing and have plodded along doing my time until my escape. Alternatively, doing it for a day at a time the support issues leak into the day job and the day job is hard to put down during your support hours.

I've learnt a lot this week. I have been lucky, I've had fairly straightforward issues to address and it hasn't been a busy week. But next time I see the support week looming in my calendar, I won't fear it as much. I'll probably do the next one from home, but my week here in Dublin has prepared me for what's in store. Most importantly, I've got to know the people who are part of my team here, so I'll be more comfortable asking the stupid questions.

In summary

  • Doing support is so important for developers. Getting an understanding of what your users are doing and what their pain points are can really help drive your design and your architecture, and can really motivate you to fix that stupid bug or write that overdue tutorial.
  • Developers and support techies can learn off each other - I've learnt a LOT off the guys here, but I've also been able to answer a few questions about Java in general and the driver in particular.
  • Scheduling time in support for developers is a very tricky balance, and probably needs to be experimented with a bit before a company finds something that works for them.

Although I'm never really going to love being on support, I still like being encouraged to work on support regularly - it's been so important for my understanding of our product and of our users.


1 I found Grails BY FAR the most difficult to get started with - all I wanted was to write a unit test to prove the issue, and I had to not only create a whole application using the grails command line, but I had to install a whole host of plugins and uninstall all the stuff for hibernate that gets put in there magically. I never did find the solution to the Grails problem I was looking at.

JavaOne: The Problem With Women – A Technical Approach

Yesterday dawned, with a sense of foreboding (actually it dawned with me coughing my lungs out, but we've heard enough about the sub-optimal state of my respiratory system this week). On this day, I was giving the talk I was dreading when I got asked to do it. It's the talk I actually put more work into than any of the other sessions I was presenting at this JavaOne. It was the Women In IT talk.

Continue reading "JavaOne: The Problem With Women – A Technical Approach"

On The Evil Of Stereotypes

I attended (one way or another) two events last week that got me thinking

The first was Girl Developers will Save the World - a session that had me a little confused as to whether that referred to me, or actual girls, i.e. those that are not yet legally classed as adults.  The second was the Remarkable Women Twitter party the following day.
Firstly, a caveat/disclaimer (as usual) - both events were useful, thought-provoking and overall worthwhile.  But the alarming thing to me was the number of times I heard "boys are…" or "women think…" or "girls prefer…".  And I know we often make generalisations to stress a point, but I'm becoming extremely wary of statements that group people together along some arbitrary boundaries.  

  • "Google+ failed because it's design by men for men" - no, it's because it's not designed for anyone.  Its only purpose was to compete with Facebook.
  • "Women are better at communicating and social activities" - what, all of us?  I'm better at communicating than every man I've ever met?  Than someone like Obama or Steve Jobs or John Stewart? 
  • "Women do better with female role models" - where are the statistics?  And do men do better with male role models, or do they do better with female role models too because women are so much "better at communicating"?
I'm not saying these statements aren't ever true.  I'm not even saying they're not true "most" of the time (although I want to see proof).  But any kind of strategy based on gross generalisations had better take into account the fact that these are generalisations, that they are based on Statistics1(and sometimes not even those), and that they frequently correspond nicely to things we'd like to think or we are trained to think.
Humans are great at categorising.  It's a survival skill - "yummy", "warm", "safe", "funny coloured = hurty tummy", "things with sharp pointy teethies like to eat me".  Without this skill we wouldn't have made it as a species.  And marketing people, who have to use psychology to get us to part with our money, understand this.  They identify trends and target their shinies to these trends (YuppieBaby Boomer, etc).  By identifying these groups and aiming at them, they make them real.  And since humans are a clan-based society, who (again for evolutionary reasons) need to fit in with their gang, these groups become aspirational.  Essex people drive BMWs and wear white stilettos?  I don't and I live in Essex, oh no! I'd better get on that right away, otherwise people will see I'm An Imposter.
So when people go around saying "Women are great at communicating", we believe it.  Those of us who are a bit sucky at it or maybe don't care about it wonder if we're aliens.  Or we believe we're great at it because we should be, and we don't work at improving our skills.  Men are terrible at cleaning?  Great!  I don't have to clean the toilet!  Women's minds aren't programmed for engineering because they're more communicaty than logical?  Fine, I'll teach physics instead of using it.
If I hear one more person say women don't do well in IT because they prefer more soft-skill-based roles, I'm going to scream. In that case, why are there more women entering accountancy than men? In that case, how do men ever get to manage people, and why does pair programming work so well?
If I hear once more that men put women off these roles because of the macho male environment, I'm going to drag that person through a tour of every office I've worked in - I'm constantly disappointed that my male colleagues enjoy football even less than than the girls I went to school with.
So, using stereotypes to try and address things like gender disparity in IT is not going to work.  The men in our industry are not beer-swilling, football-watching, womanising alpha males.  So why, when we talk about the missing women in our industry, do we assume they will be pink-obsessed, fashion-conscious, gossipy socialites who only hang around with other women?  Do you even know any women like that?  This is not Desperate Housewives, this is Real Life.

Really good marketing people don't target people as they are - no-one wants to be considered poor - you're a bargain hunter or great at identifying value.  Similarly, if you want women to use your product or  work for your company, you don't target to weight-obsessed, soap-opera-watching, child-caring fashionistas.  Instead you target how a person wants to be seen.  You might say using your product or working for your company makes a person look smart, savvy and awesome.  And who doesn't want to be all of those things?

Saying people in IT are sexy and intelligent and earn loads of money and have oodles of job options and can find work globally might be a compelling story for people.  Some of those people might even be women.  Some of them might even be the other missing minorities

Thinking in stereotypes can be damaging to everyone.  Gender stereotypes in both directions are so sweeping they are unhelpful, you can't categorise fully half of the world's population as one thing or another.  I hear men doing men a disservice by saying things that aren't even true for themselves, and the same for women.  It's something we're trained to do, and something the media loves to do.  But it's wrong.  

So the next time you find yourself saying "men prefer..." or "women are...", stop and think if this is actually true for all of the men and women you know.  And if it's not, just don't say it.

1Lies, damned dies and…

Overheard: Agile truths

After attending a number of conferences and events, and performing numerous interviews, I’m starting to hear the same things again and again.  Since Dan North challenged all my assumptions at QCon, I’m reluctant to outright ridicule them, but I will put forward my personal opinion.

Note: these are things I have heard from multiple sources, so with any luck I am not breaking the sanctity of the confessional interview.

I’ve never pair programmed, but I’ve frequently worked with a partner on critical production problems
I find this fascinating.  If there’s one thing that needs to be fixed as fast, as correctly, as efficiently as possible, it’s a production issue.  And when there is one, “everyone” knows that two heads are better than one, even The Business.

If this is the case, why is it so hard to sell pair programming as the default state of affairs?

Is it because creating new features is seen as just typing, where the bottleneck is access to the physical keyboard?  Is it because fixing defects when the pressure isn’t on is suddenly easier for one person on their own without help?

This state of affairs is interesting to me as it implies that when proverbial hits the fan, the instinctive thing to do is to work collaboratively.  Why don’t we do it more often?

We use Test Driven Development to get coverage
Seems weird to me to write your tests first to get coverage.  If unit test coverage is your most important metric (and other people have covered why this might not be the case), I’m not sure why you would write your tests first.  Seems to me that you’d get better coverage writing the tests after the code.  That way you can be sure you’ve covered every eventuality.

To me, the statement implies two assumptions which I would challenge:
a) The primary value of writing your tests first is to meet your coverage requirements
b) Coverage is a meaningful metric

TDD/BDD has a number of benefits (…and now I’m reluctant to list them here in case people repeat them back to me in an interview).  Good coverage will probably be a side effect of being forced to write your tests first, but I’m not convinced that’s the best thing that will come out of using TDD.

I only test first when I know what I want to code
I’ve overheard people saying that they test first when they know what the code is going to look like.  So you dive straight into the code when you don’t know what you’re doing???

Of course there is a place for this - spikes, prototyping, getting a feel for a new library, so on and so forth.  But I feel that for most code that you write in your day job, you probably have a business requirement and possibly (probably?) a less firm idea of how you’re going to code it.  To me, this translates into writing the test first (which documents what you want to deliver, which you already know) and then getting that to pass (which is writing the code, which is the bit you might not know).

If you know exactly what the code is going to look like a) I would question that statement and b) what’s the point of the test?

What are the real answers?
At QCon I saw on Twitter a number of complaints because the presentations there gave opinions, guidelines, and, worst of all, a lot of “it depends”.  But people seemed to want The Answers.

In my opinion, what developers get paid for is working out the “it depends” parameters and selecting an approach, technical or process-wise, that works for their situation.

So although I have strong opinions on all the above subjects, and although LMAX has specific approaches to both pair programming and automated testing, sadly I’m not going to go into lots of details about those.

Mostly because I’m still interviewing candidates, and I don’t want to give away the correct answers….

Why the customer isn’t always right

Last week I went to get my hair cut (yes, sorry, this is a story about hair).  I had thought long and hard about what I wanted.  I researched, checked styles online, and bought a magazine so I could show my hairdresser exactly what I was after and there would be no confusion.  I was determined I would not be spending that ridiculous amount of money on something I was not going to be happy with.  I was even bold enough to ask for some changes to it at the end, which I have never ever had the courage to do before.

He did an excellent job.  It was almost exactly what I had asked for, with some variations to account for my particular hair type.  It was a very cute hair style that suited me.  But I had a niggling doubt.

A few days later, that niggle was a certainty.  It wasn’t what I wanted.

However, it was what I had asked for.

Being English, the thought of going back and telling him I wasn’t happy with it was horrifying.  Especially since he had done a really good job of it.  It wasn’t his fault that what I’d asked for wasn’t what I had actually wanted.  But I knew what I wanted now, and I was prepared to pay for it (again).

This time I didn’t show him a picture.  I didn’t point to anything specific.  I said I wanted it much shorter after all and outlined the look I was going for.  We had a conversation about it and I left it to him to apply his skills to actually implement it.

This time, I was much happier with the results.  In fact, it was exactly what I wanted.

So what?

Of course this got me thinking about work.  It’s not just a lame excuse to write about girl stuff on a supposedly technical blog.  It got me thinking about our customers.

Whoever our customers are, whether they’re end users, internal business owners, external clients, or we work in a bank and have fifteen thousand layers of Business Analysts between us and Real People, whoever they are they want something from us.  And in many places, we, the techies, have trained them to ask for more and more specific things, so they can be sure they’re going to get what they really want.  Remember that time Bob asked for that extra field on that report because it would make his job easier?  Remember when Sandra wanted the workflow to be altered in a specific way?  It’s because they know that if they ask for something specific, the chances are better that it will make its way to the front of the work queue at some point, and when it comes out the other end it is more likely to be what they wanted.

Only it isn’t, is it?

There’s always another field to add, or another change to make.  And your customer isn’t quite satisfied, even though you did exactly what they asked for.  And sometimes they don’t tell you that they’re not getting what they need from your system, because it’s expensive or time consuming to get changes made.

The key to delivering something they really want, instead of something else that’s merely adding to the weight of your code, is finding out what they’re actually trying to achieve.

So Bob wants that extra field.  That’s easy enough.  But when you ask him why he wants that extra field, turns out it’s because the numbers in the reports he’s getting at the moment aren’t the ones he needs, or aren’t quite correct.  He’s probably created a monstrous Excel spreadsheet into which he manually types half of the numbers from the reports it took you ages to develop, which munges them into something quite different, in order to get the real thing he wants.  He’s just missing this one small piece of information to get the final figure correct.  It would save your company a lot of time/money/mis-typing errors if you completely re-wrote the reports Bob uses to give him exactly what he needs.  Or if you gave him a tool to download CSV formatted raw data from the database.

It’s not Bob’s fault he can’t ask for this, he doesn’t know what we’re capable of providing him.  It’s not our fault for not delivering it the first time round, we don’t know what he does day-to-day.  But having a conversation where we recognise where the knowledge lies (Bob knows what the output of his day job is presumably, and we know what’s available and how we can provide it), and collaborating to come up with the least rubbish solution for everyone, is a step to providing that overused term, “business value”.

We’re not on different sides here, we all play for the same team - we want our jobs to be as painless as possible, which (should) ultimately provide better efficiency for our company.  After all, we want the company to make money so they can pay us, right?

<span style="font-size: x-small;">Caveat: Mileage may vary.  Sometimes, with some customers, you really do need to tell them what they want.

On The Similarities Between Girls And Aliens

I discovered, through the power of the search words that lead to my blog, that there was an incident at JavaOne that once again opens the can of worms that is Sexism In IT.

This Makes Me Sad.  I had a really positive experience at JavaOne.  In fact, I would say it was the one conference I’ve been to in the last 12 months where I felt like my gender wasn’t a problem - I even got away with wearing hotpants (tweed is business-casual, right??) without being mistaken for anything other than a developer.

I know incidents like this cause a lot of tension, and I want to explore why.  Get ready for some gross generalisations: women get upset because they feel they’re being marginalised or treated differently; men get upset because they think we’re being over-sensitive, especially when the cause is something unintentional.  I sometimes wonder, as I’m sure other people do, if perhaps picking up every incident harms our cause more than advancing it.  But then I feel that the unconscious stuff is exactly the stuff that needs to be pointed out - if you don’t realise you’re causing a problem, you can’t change your behaviour.

So what I wanted to do was… well, what I wanted to do was not rant about gender (again) and be a good little non-gendered programmer.  But then I thought that spreading a bit of understanding might be A Good Thing.  After all, we’re all about continuous improvement, right?

I’m sure many people have been one of a minority at some point in their lives (brace yourselves for a litany of stereotyping) - the only man at their daughter’s dance recital; the only white guy on a basketball team; the only straight guy in a gay bar (accidents happen!); the only girl on the development team… Speaking for myself, in those situations I’m not actually looking for things which prove that I’m Not One Of Them. I’m sub-consciously seeking reassurance that I’m not an alien, a freak of nature, the odd one out.

I’ve been in mostly male environments for the last 16 years - this is the norm for me, it’s my life.  It freaks me out if I’m surrounded by women actually.  What’s jarring and uncomfortable is when the difference of your gender becomes apparent: when all the t-shirts are boy-shaped and boy-sized; when someone makes a joke about “women”; when someone addresses the room with “Gentlemen” - or worse, they try and make up for it: “Gentlemen.  Oh, and Ladies.  Well, Lady <nervous smile>".  Thanks, that doesn’t make me feel like an outsider at all.

Something else that really highlights the difference in genders is when you have plenty of women at the conference… but they’re not the attendees.  They’re manning the booths (marketing/sales or just plain hired “help”), they’re taking tickets, they’re dishing out the lunches.  In these cases, it becomes normal to assume that “girl” = “staff”.  Not guest.  Not equal.

TradeTech was one of the worst examples of this that I’ve experienced.  Those (wo)manning the booths had been chosen for their aesthetics not their knowledge.  There was even entertainment consisting of scantily clad stilt-walkers - at a financial conference!  I made the mistake of turning up in a skirt - for those who know my dress sense, it was not one of my arse-length ones, it was just above my knees - and everyone assumed I was selling something. I had a job to persuade them that I had actually paid for my ticket.

So.  What am I trying to get at?

  • We’re not trying to make you uncomfortable when we point out tiny accidental possibly maybe sexist or sexist-seeming comments/incidents.  We’re trying to stamp out behaviour that can subconsciously be pushing women (or other minorities/groups) out of our industry.  We like it here, we want to stay, and we want others to join us.
  • It’s very easy to alienate people who are not 100% comfortable in your environment.  Every time I see t-shirts in boys size only I’m reminded I’m Not One Of You.
…and what can we do?
  • Well, the t-shirts is an easy one.  So easy, and so stupid, you might not think it’s worthwhile.  Especially as people like me don’t even want your free t-shirt.  But I want to feel like you wanted me to want it.  Please stock some skinny-fit tees in multiple sizes, and stock smalls and mediums of the normal shape.  There are guys who would like this too.  Even if you can’t get rid of your skinny tees, it will do wonders for your image.
  • Never assume your audience is all male.  Never even assume it’s “mostly” male.  If your sister/girlfriend/mother/daughter might frown at something you’re saying, don’t say it.  You’ll look like an idiot.  You can assume your audience is all technical, and joke about managers, or is all Java, and take the mickey out of C#.  Don’t draw arbitrary battle lines based on gender/race/origin - any jokes should make all the audience feel included, not like specific individuals are excluded.
  • There’s already been a lot said elsewhere about encouraging women speakers at events.  I’m totally behind this, but it’s a fine line because I’m also totally against positive discrimination.  For the purposes of this blog, I would just say make sure you have some women on your speakers list, in the same way you would probably ensure you have a Java 7 talk, or a talk on the shiniest new technology, or other miscellaneous checkboxes you need to tick in order to make your conference a success.
  • Not sure what to suggest around many of the girls there being staff… I guess something simple like clear uniforms would stop people assuming female delegates are there to hand out lunch.  And making sure that your staff/helpers/organisers are of both genders too.
If you’re interested in this whole topic, or want to tell me I’m wrong to my face, come along my panel at Devoxx - Why We Shouldn’t Target Women.

On How Not To Target Girl Geeks

(First, let me say this post contains opinion, stereotyping and sweeping generalisations. But that's sort of the point. Also I don't pretend for one moment to speak for all girl programmers, I can only speak for myself)

When I first started this blog, I wanted to just post "proper" technical information. I wanted to prove that there are girls out there doing "real" programming.

I specifically didn't want to talk about my gender. I wanted to prove by silence that gender is incidental to what I do.

But, it doesn't really work that way, does it?

Firstly because one of the first things I get asked by guys when I meet them in this industry is "why aren't there more girl programmers?" (that's after they ask "do you work in HR?" followed by "are you a real programmer?" - I'm not joking, this happened this week).

Continue reading "On How Not To Target Girl Geeks"

Sexism in IT?

Let’s celebrate our IT women

"Everyone" knows that there are more men than women in IT.  That it’s a "boys" job.  Not a lot of people know that the first programmer was a woman.  Not a lot of people realise the number of women in IT is DECREASING.  And has been since the 80s.  In a working world where I honestly believe that in general there are more opportunities for women (OK, inline with the other stuff I’ve been reading I’ll caveat this with white, middle-class women), it seems shocking that such a growth industry as IT is actually losing women, and appears unable to determine why, or stop the flow.

I get asked a lot, as a girl programmer, why there aren’t more women in IT.  This is a complicated issue and one I’ve been thinking about for years and still don’t have any good answers, but I personally think it’s more about perception than anything else.

I don’t think it’s because you get more outright sexism and laddish behaviour in IT than anywhere else.  I’ve worked in half a dozen companies, in a range of industries, including very male industries like manufacturing and banking, I’ve been a consultant so been onsite at a bunch more companies.  And I have to say I don’t think I’ve ever seen the sort of behaviour that is mentioned in the article.

I would go so far as to say IT, certainly in terms of programming or IT support, actually attracts men that are quite the opposite to laddish.  So here I will succumb to gross generalisation and stereotypes myself, but the guys I’ve worked with are highly intelligent and more likely to rate you on your ability than on your colour, sex or background.  These are often guys who were actually studying at school rather than absorbing anti-female sentiments in the pub or from The Sun.

I find being a woman in IT both a blessing and a curse.  As a girl, you are, I believe, more likely to get through to interview, and since you stand out as different are more likely to be remembered and called back for a second interview.  I think once in the organisation, we suffer more with low self-esteem and find ourselves constantly trying to "prove" that we’re not just some token bimbo hired by HR.  And do you know why?  Not because anyone ELSE thinks that, but because WE think that.  We are our own worst enemies.

We need to take a leaf from the boys’ book and have more faith in ourselves, more confidence.  We might not be as good as that person over there at this particular thing, or this other person at something else, but we are good at what we do, otherwise we wouldn’t be there.  And if we express our insecurities instead of our confidence, other people will assume we’re as mediocre as we sometimes think we are.

Some of the very worst culprits for sexism in our industry are us, the girls who are already in it.  Yes, it does exist, I am not denying that for a second1.  But the way to overcome it is to reflect it back at them, not to internalise it as our problem, something wrong with us for being in the wrong job.  The more we show that it’s normal for us to be here, that we belong here, the better we’ll feel about ourselves.  And maybe we’ll attract a few more girls too.

1Take, for example, the CEO who interviewed me and said "I’m probably not allowed to say this, but how will you feel working in an environment full of men".  To which my answer was, have you read my CV?  I went to a boys’ school for sixth form, I was one of 6 girls on my degree course (out of approx 150), I worked at Ford for 4 years.  Don’t you think I would be more freaked out working with girls?