Update on events

Just a quick note to say I was interviewed for another podcast, again to talk about all-female events.  It's only a short one and there's probably not much in there that I haven't said before, either on here or in person.

From the 21st May, I'm at GOTO, both Copenhagen and Amsterdam.  I'll be talking about code & the Disruptor, thank goodness, and will be trying not to rant about the subject of women in technology.  If you see me there, come and say hello!

On Friday 25th May, after all the GOTO craziness, I'm going to repeat the Disruptor presentation in Rotterdam at 010DEV, an event rather fantastically called "The Disruptor and the Perfect Programmer", which someone on Twitter correct noted sounds like a fairy tale.

After all that, I'm hopefully going to take June off to play Diablo 3 and Prototype 2, and read the next Game of Thrones book.  All these joys I have been denying myself to make sure I get everything sorted in time for next week.

Featured on a BBC Podcast

This week's BBC Outriders podcast features yours truly venting about The Subject That Won't Go Away, Women in Technology.  I was interviewed at Sunday's Girl Geek conference, and got a chance to voice my opinions once again.  For those who can't be bothered to listen, they can probably be summarised as:

• There are genuine problems that face people in our industry, let's talk about those that you have actually faced, not ones that you imagine exist.
• In my opinion, now is a great time for women to make a name for themselves - conference organisers are crying out for you to attend and (if you want) speak, and our industry needs talented people of any type and isn't that fussy about who you are.
• Please, please can we start talking about the good stuff that we see as women in IT?  We shouldn't only talk about the issues we face.  Yes, we need to highlight problems and address them, but I believe that this message is drowning out all the great things about what we do, and why we love our jobs.  We should be encouraging people (not just women) to join us, not putting them off.

In which I defend the Male species at an all Female event

Google Campus is an awesome space

Today I was at the Girl Geek Meetup conference.  I didn't advertise it much because I've said in the past I don't really agree with women-only events, and actually I felt quite uncomfortable telling you guys I was going to be there, knowing the majority of my readers weren't allowed to attend.

It's probably worth explaining why I went, so a) I can give you guys and excuse but b) conference organisers can see what people like me are looking for in a conference.

Graduate Developer Community Meet a Mentor Programme
The primary reason I went is because the new Meet a Mentor programme I'm involved in does not have a lot of women mentors.  This is simply a numbers game - when you don't have all that many people signed up to be mentors yet, and you have the "normal" proportion of women in that group, you'll be lucky if you get one female mentor turning up at these events.  Since one of the things we want to showcase to undergraduates is diversity, it's pretty important we get all sorts of people involved, not just mining from the usual suspects in the London Java Community.  This was a good conference to target since a) the attendees come from different technology and industry backgrounds and b) yes, sorry, we want more women doing it.

Don't knock it till you've tried it
I've said before I don't think all women events are the way forward.  But I haven't been to one for a long time, and I firmly believe you shouldn't say bad things about something unless you've tried it out.  So I wanted to go to see what the advantages and disadvantages of an event like this were.  If I had a terrible time, at the very least I would have material for the blog.  I also feel like I have a bit of a responsibility to spy on these things, since my male colleagues cannot.

Networking
Similar to the Meet a Mentor goal above, I wanted to meet some different people.  I'm getting comfortable in my particular circles, and I'm starting to meet some of the same people at various events.  This event was based in the very start-up friendly Shoreditch, and didn't target a specific technology or business, so it gave me the opportunity to meet new people.

They gave me a platform to rant
I only really felt comfortable agreeing to go when I was invited to participate in a panel about whether all-women events were useful, or if they created a Girl Ghetto.  Knowing I could publicly voice my opinions on the subject at one of these events made me much happier to attend.



And actually... I had a very good time!  It was refreshing to meet new people, especially because they're mostly in different technology and business spaces.  I was really inspired to see the number of entrepreneurs, and people working for startups.  And I loved the range of ages, the diversity of people's backgrounds (ethnically, educationally, geographically...), and the fact that everyone bothered to come out on a very rainy Sunday to learn stuff and meet people.

It did feel different to "normal" conferences.  However.  I personally do not believe this was because it was an all-women event.

The LJC Open Conference last year had a very different feel to JAX London and JavaOne - it was more intimate, easier to wing-it in presentations, friendlier.  You could chat to pretty much anyone over the coffee. You could smile at random people.  These are all the same things I felt about GGM today.

I can't help but think this atmosphere of supportive learning and collaboration is at least partly a function of things like:

• Size - smaller conferences are less intimidating, and you get to meet with people more than once, giving you the impression you're with friends rather than spectators.
• Venue - being seated (or even standing) around a table or in a coffee-break area is more intimate.  It means the speaker can make better eye contact, feels more engaged with the audience, and there's less of a barrier for active participation.  If the presenter is less than 3 metres from you, it's much easier to ask a question.  This leads to a chattier, more tailored session - more of a dialogue than a speech.  As a speaker I really prefer these sessions, and I think as an attendee I get more out of this too.
• Common Goal - when you give up a day in your weekend to do "work" stuff, you have to have a clear idea of why you're doing it and what you're getting out of it.  I would say (although I could be wrong) that our common goal was to network, with a side-effect of learning "stuff".  Events at the weekend are really only something you do for yourself, since you're not being paid for it.  That gives you common ground.

I wanted to get a feel for if these awesome women were only going to events like these, and weren't going to "normal" conferences.  I think it was a mix.  I don't think (and I could be wrong) that people were coming to this because there were no guys.  I think they were coming because they were invited.  

Someone mentioned that a conference organiser once told them they have to ask a man to speak at their conference at most two times.  They have to ask a woman up to seven times, to overcome their concerns and reassure them that they really do want them.  I wonder if women also need to be asked several times simply to attend conferences?  This would make a lot of sense - about 15-20% of the technical workforce are women, but around 5% of conference attendees are women.  It's possibly that by the time women have been invited to, or told about, a conference enough times to make them want to go, it's totally sold out.  Do we need to very explicitly invite women to our events?  Show them we really want them?  Multiple times?  And this is just for attendees, not even speakers.

I'll come back to some of this.

The schedule

I presented on four occasions - yes, I was so greedy for fame that I actually had almost no time to talk to people or to see anyone else's sessions.

Why Open Source Your Secrets

A different spin on the Disruptor, when I answer the number one (well, number two actually) question: why did we open source it?

The slides are pretty simple and I'm not sure there's a lot of value in putting them online without the talking, but if anyone's interested I can either shrink it to a lightning talk at one of the LJC events, or attempt to expand it into a fully-fledged presentation

GDC: Meet a Mentor

What it is, what's involved, what's in it for you.  This is all material that needs to live somewhere on the interwebs so I promise to link to it as soon as it's available.  If anyone is interested in a really lightweight process for mentoring university undergraduates, drop me a line and I'll try and tell you all about it.

Technology in Electronic Trading (co-presented with Annalisa Sarasini)

This is the session I was most nervous about, since with Annalisa in Nepal and me in Seville, we didn't actually get a chance to talk about what we were doing, let alone rehearse it.  However I think it went really well - at the end of it, the folks who saw it said they had a better understanding of the use of technology in the banking/finance world, and I think it's a great way to show how computer science can truly be applied.  We'd love to run this as a full talk somewhere.

Panel: Women-only events - are we creating a Girl Ghetto?

Oh my goodness, all these women!

In which I get to say that I think it's grossly unfair we do not allow men to this event.  In which I state that this behaviour is sexist and (in my mind) unhelpful.  But in which I also am told that women are still either a) experiencing alienation/sexist behaviour at conferences (thankfully it seemed like a limited amount) or b) feel like there are issues around boys club, macho posturing males, and thought if they presented at a conference they might get questions designed specifically to make them feel stupid.

I think this is a very important point - even if none of this is happening, even if these women have never experienced this themselves, they think it might be happening.  Also, please note, these issues do not affect just women.  These perceived problems are stopping less confident men from attending or speaking at these events.

What can be done about these things?  My answer is, it's up to us.  The women, the less confident, the non-posturing non-alpha males, to make the changes we want to see.  And I can't claim all the glory for that answer.  When, during my very short stay at ThoughtWorks, I complained to Martin Fowler that GOTO 2011 was full of white, male speakers, he said to me, why don't you speak then?  Of course I said "who, me??".  I didn't think I had anything to talk about.  After attending a few conferences I realised that doesn't stop people.  And I realised people have to start somewhere.  And you have to start by doing some poor presentations to practice - you can't instantly be awesome.  It takes time, and practice, and Barrack Obama didn't come out of the womb knowing how to make an impact during a speech.  And guess what?  This year I'm speaking at GOTO Copenhagen and Amsterdam.

So my answer is, you want something?  Ask for it.  You want more women presenters?  Volunteer.  That panel is full of men?  Find out who organised it and what you need to do to be on it next year.  It's down to us.  Not to the conference organisers.  Not to some great beneficent them. The responsibility is ours.  But it's better than that - the control is ours.

Only you know what it is you want.  Only you can speak for you.  Not for all women; not for all white/black/purple people; not for all straight/gay/ambivalent folks; not for all geeks.  The question isn't "What do women want?" but "What do you want?".

I think I saw some lightbulbs go off in the audience.  I hope so.  These women were all awesome, they have a lot to share with the world.  We all do, even the tiniest experience, the smallest thing we've learnt is something someone else might not know yet.  Let's get out there and share it.

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....

QCon London 2012

I'm late with my write-up of QCon, and what's worse, it will be partial - "sadly" I was in Lanzarote on a training week with the running club from the Thursday (8th) so I missed most of it.  A sacrifice I had to make for 7 days in the sunshine….

Firstly, me me me

I presented the talk I previewed at Skillsmatter the previous week, something I was calling the User's Guide to the Disruptor, but actually turned out to be how-can-Trish-fill-95-slides-with-pictures-and-finish-in-under-40-minutes.

The audience was different to the Skillsmatter event, not surprisingly.  What was surprising is that I expected people at the conference to be less aware of the Disruptor, and those who came to the Disruptor-only LJC event to have had more exposure to it.  It was a (pleasant) surprise to see how many of the standing-room-only audience had not only heard of the Disruptor but had read stuff about it (I always love it when people have read my blog), played with it and were even using it in anger.

Because of that, I think if anything the talk did not go into enough detail, or enough new stuff, to please everyone.  Tough crowd!  But it was gratifying to hear the audience correct me in some of my answers, and answer other people's questions - it's always nice to know people are listening.

Of course, I will post a link to the presentation when it's available.  For now only the slides are online.

I enjoyed QCon

QCon was noticeably different to the other conferences I've been to in the last six months.  For one, it's not a Java conference - sure, I was hosted on the Java track, but QCon is wider-ranging than just one technology platform.  I'm not sure if it's because of this, or because it was based in the notoriously impatient London, but I felt like there was a message of "Look, let's just get stuff done, OK?".  Ultimately we get paid to deliver stuff for the business, and since my favourite question is always "but what are we trying to achieve?" I like to hear ideas around how to actually deliver.  Don't get me wrong, I've loved the technology conferences - I like to hear about new stuff I had no idea about, and I really like the community vibe from them.  But it's a nice change to be shaken up into thinking exactly why we do all this.

The Data Panorama

Firstly, Rebecca Parsons and Martin Fowler from my old employer ThoughtWorks put Big Data into perspective.  Previously I hadn't really cared about it - we process lots of data at LMAX but we don't really have to dig into it, so Big Data is not top of my "oooh I really worry about that" problems.  There were quite a few interesting points I took out of this:

 - In the past, it was easy (and possibly even correct) to model the whole application based on the data you were collecting or manipulating (and probably storing in a relational database).  These days it's not just the data from your app you need to worry about (and that can get big enough), but also all the news, blogs, twitter, and Facebook stuff generated by you and about you.  In addition, your data might not even be located with your app - the cloud has made the physical question of location redundant.  All of this pushes you towards an architecture which has to separate data from the application, and forces you to ponder your design.  I heard good arguments for Domain Driven Design here, which is nice because we like that at LMAX.

 - Reporting and analytics on Big Data must be more fluid.  There's so much data about you, your users, your application, out there that you don't even know the questions to ask.  Instead you want to be able to spot patterns in data you didn't even know you had,  I thought this was dead interesting - I studied Computer Science and Artificial Intelligence at university, and we were told data mining using AI was going to be fundamental to companies who wanted to be on the bleeding edge.  Only now is it looking like people realise it's becoming that important.

 - Martin referred to Data Scientists and said he was suspicious of scientists.  I'd been reading The Black Swan on the train in that morning and couldn't help but wonder if he's read the same thing - that was talking about how you should treat someone with suspicion if they suggest you can apply science and logic to anything that is… well, actually to anything other than actual science (by which he meant physics I believe).  By saying it's a science you suggest it's predictable and follows rules.  And if it was predictable, it wouldn't be hard.  Big Data is anything other than predictable - the data could be corrupt (it's safest to assume some of it is); it's generated by people (and we all know how fickle they are); and if you're collecting lots of it practically randomly, then cause/effect/correlation are not guaranteed.  So Martin suggests the term Data Journalist.  There was a storm on Twitter which suggested a certain amount of disagreement with this term, but I like it.  But then, I like to pretend I'm a writer and not a programmer.

 - They gave some examples of using data to drive economic growth (e.g. Kenya) - what I thought was interesting about this is that it was a win-win situation - expose the data to grow technology skills, but get a lot of interesting/useful/socially responsible applications in return.

 - Something I liked was about the idea of embracing "bad" data, stuff that's not trustworthy for whatever reason.  You can assume that the good data overwhelms the bad but you can't be sure.  By looking for more fluffy patterns, vague correlations, in your data, you might expose something interesting even if the data's not "correct".  As humans, we can't expect that we won't make a mistake - it's better assume we will and work out how to deal with it.

 - There was a call to not passively accept requirements, but to play an active role.  I like to think this ties in to my post about working with your customer.  But then I would.

 - I got a lot from this keynote, even if it was just a feeling of "I knew it!  I was right!". 

Highly available systems in Erlang

Joe Armstrong was a very interesting person to listen to, clearly someone who's been there and done that. Even without the presentation, the slides are interesting in their own right as they contain a lot of information and guidelines.

The points I took away are:

 - If part of the system fails, it's not up to that part to fix itself.  You need special help to deal with failures.  If you fell over with a heart attack, you wouldn't try and heal yourself, you'd get a medic

 - Isolation between threads/programs will mean that those different things cannot interfere with each other (i.e. no shared state).

 - My favourite quote was "If you make things synchronous you'll bugger things up".  In theory, it's so much easier for us humans (programmers) to think synchronously.  But whenever you design your system to by asynchronous, you find that your system actually becomes simpler and not more complicated.

JVM performance optimizations at Twitter's scale

 - I had a terrible view in the fully packed room, so I was just picking up phrases. I heard Attila mention the Uncanny Valley, a phenomenon I was introduced to by my sister when she was studying her Cybernetics PhD (Google it, I found it fascinating).  

 - There was a lot of really useful information about how the Java GC works.  It seemed to back up the (rough) premise we work on - stuff that's very short-lived is fine, and stuff that lasts "forever" is fine - it's the stuff in between which  cripples your system when it keeps getting shoved around.

Decisions Decisions

Dan North was, as always, an excellent speaker.  He entertained us but got us all thinking.  Five years ago at QCon London (my very first conference ever, and the thing that motivated me to start a professional blog), I saw Dan speaking and I was inspired to think about my working practices.  He was talking about BDD at the time, which was a relatively new concept to me.  I came away from that QCon with clearer ideas of what awesome development practices should look like.  Never did I imagine that five years later, not only would I be working in an environment which follows a lot of those practices (and pioneers many more) but that I would actually be speaking at the same conference.

I've come a long way since then, and of course, Dan isn't talking about the same things either.  I've been to a lot of conferences this year, and I heard nothing really preaching to the "meta-agile" LMAX (still have a post pending about our agile practices...).  When it comes to agile, there seem to be very few people who we can learn off - don't get me wrong, there are lots of things we want to improve on, which is why we're looking for people to learn off.  But most people are still preaching TDD and we want to know "what next?".

Well, Dan took everything we thought we knew, and ripped it to pieces.  Taught us to challenge everything we think we know.

It was irritating actually because he had no answers.  But he did tell us that the answers we think we already have might not be the right ones….

Well worth watching his talk when it comes online, I really can't summarise it here.

Developers Have a Mental Disorder

I nearly missed this ending keynote.  I'm so glad I didn't, Greg Young is awesome at ranting.  He said developers have a disease - we overcomplicate things, when we try to simplify things.  We want to abstract stuff, we love to look for patterns and reuse when actually sometimes we just need to solve the problem.

In my notes I have "People come to conferences for answers, when they should be remembering to use their brains".  I assume that's a quote from him, and not a comment I thought of at the time, but I wholeheartedly agree with it - if a shiny new technology solved your problems, you'd be out of a job.  Your job is to take the problem and figure out how to solve it.  Not to drag and drop an answer into place.

Another talk that I can't do justice to, watch the video when it comes online.

…and finally….

At the end of the day, the Atlassian-sponsored community night was awesome.  I got to chat to (be prepared for gratuitous name dropping here) Martin Fowler; my old friend Simon Brown; my ubiquitous LJC colleagues Martijn and John; the Zero Turnaround guys; a couple of ex-colleagues from Evolution / Detica; a heap of LMAX and ex-LMAX guys; and, of course, bundles and bundles of new interesting people.

Summary (i.e the short version for those who can't be bothered to read this whole post)

Maybe it's wishful thinking, but the messages I took from QCon were:

• If you want to solve the problem your business has, you might want to model your system around their world.  Funny, that sounds suspiciously like Domain Driven Design.
• Synchronous is bad, mmmkay? 
• Hardcore understanding of what the computer is really doing seems to be coming back into fashion.  Hmmm, I wonder who started that…? (tongue firmly in cheek, we can't have been the only ones)
• "You can't tune something you don't understand" - testing and monitoring is kinda important.
• Our business is all about trade offs.  There is no perfect solution, they pay us because it's very very hard to work out something that's Good Enough.
• Ultimately it feels like back to basics: understand the problem; model the domain, and have sympathy for the hardware that's running your solution.

My Corporate Bit

QCon overall turned out to be a bit of an LMAX fest in the end, with Mike & Martin and Andy Stewart (our Chief Lord Business Analyst), all giving presentations there as well as me.  It's nice to be on home turf, and it's very cool to see that we have such a range of things to talk about that so many of us are invited to speak.

PS

I just found out there's a QCon in New York.  My invitation seems to have got lost in the post.  Don't suppose anyone wants me to speak there…?

Java Magazine: Intro to the Disruptor Part One

This month's Java Magazine features an article by yours truly, which is yet another intro to the Disruptor.  It's basically a summary of the stuff I've written in this blog, updated for version 2.7 - so the names of the classes should be up to date and the responsibilities follow the simplified pattern we use now.  If you were looking for an more recent version of my introduction blog posts, this article gives a reasonable overview.

This is intended as part one of a series, as it's a basic and high-level view with no code examples.  In fact, it probably could be used to document the C# version as well as the Java version, although I haven't taken a look at that for a while.  Next, I would like to give some more code examples of how you use it - as always, any suggestions welcome.

New Disruptor Presentation Unveiled to the LJC!

A few weeks ago, I presented my new "User's Guide to the Disruptor" talk to the London Java Community.  Since it was very kindly hosted at Skillsmatter, there is a video of the presentation available, and the slides are below.

Concurrent Programming Using the Disruptor

View more presentations from Trisha Gee

The presentation is a little different to the ones we've done before.  Previously we've gone into how it works and why it's fast.  This time I wanted to step back a little from the internals and show how real developers might actually use it.  The example is somewhat contrived, but the idea is to give some hints on how to break your problem down into something that will work with a Disruptor at the heart of it.

I thought the event went really well.  It was a tiny bit completely intimidating, as there were no lightning talks and I was the only attraction.  Seeing over a hundred people turn up after work, before beer, to hear you talk is a humbling experience.  Fortunately, I think the audience was perfect for the presentation - they had heard of the Disruptor but hadn't seen anything very detailed about it, so my walkthrough of how you might use it seemed to go down well.  I certainly got a lot of very sensible questions (which hopefully I've remembered to repeat for the benefit of the recording), and people had some good ideas about how and when to use it.

I ran the same presentation to a different audience at QCon London a week later, I'll post a link to that if/when it becomes available.