This Blog Has Moved!

Right, so yes, five years ago I moved to github pages, and never bothered to redirect any of these pages there. Now I've moved on from there, and... Finally I am using my real domain, trishagee.com . My blog is now at trishagee.com/blog .  See you there!
Post a Comment

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?

Comments

Post a Comment

Comments have been disabled since this blog is no longer active.

Popular posts from this blog

Dissecting the Disruptor: What's so special about a ring buffer?

Image
Recently we open sourced the LMAX Disruptor , the key to what makes our exchange so fast.  Why did we open source it?  Well, we've realised that conventional wisdom around high performance programming is... a bit wrong. We've come up with a better, faster way to share data between threads, and it would be selfish not to share it with the world.  Plus it makes us look dead clever. On the site you can download a technical article explaining what the Disruptor is and why it's so clever and fast.  I even get a writing credit on it, which is gratifying when all I really did is insert commas and re-phrase sentences I didn't understand. However I find the whole thing a bit much to digest all at once, so I'm going to explain it in smaller pieces, as suits my  NADD audience. First up - the ring buffer.  Initially I was under the impression the Disruptor was just the ring buffer.  But I've come to realise that while this data structure is at the heart of the patte
Read more

Dissecting the Disruptor: Writing to the ring buffer

Image
This is the missing piece in the end-to-end view of the Disruptor.  Brace yourselves, it's quite long.  But I decided to keep it in a single blog so you could have the context in one place. The important areas are: not wrapping the ring; informing the consumers; batching for producers; and how multiple producers work. ProducerBarriers The Disruptor code has interfaces and helper classes for the Consumer s, but there's no interface for your producer, the thing that writes to the ring buffer.  That's because nothing else needs to access your producer, only you need to know about it.  However, like the consuming side, a ProducerBarrier is created by the ring buffer and your producer will use this to write to it. Writing to the ring buffer involves a two-phase commit.  First, your producer has to claim the next slot on the buffer.  Then, when the producer has finished writing to the slot, it will call commit on the ProducerBarrier . So let's look at the first bi
Read more

Dissecting the Disruptor: How do I read from the ring buffer?

Image
The next in the series of understanding the Disruptor pattern developed at LMAX . After the last post we all understand ring buffers and how awesome they are.  Unfortunately for you, I have not said anything about how to actually populate them or read from them when you're using the Disruptor. ConsumerBarriers and Consumers I'm going to approach this slightly backwards, because it's probably easier to understand in the long run.  Assuming that some magic has populated it: how do you read something from the ring buffer? (OK, I'm starting to regret using Paint/ Gimp .  Although it's an excellent excuse to purchase a graphics tablet if I do continue down this road.  Also UML gurus are probably cursing my name right now.) Your Consumer is the thread that wants to get something off the buffer.  It has access to a ConsumerBarrier , which is created by the RingBuffer and interacts with it on behalf of the Consumer .  While the ring buffer obviously needs a se
Read more