Upcoming speaking events

In theory, I am busy writing material for my upcoming speaking events, rather than writing terribly illuminating posts on my blog (see what I did there?).  In actuality I am being lazy and have pretty much taken January off for a recharge.

In the spirit of doing something which ticks both the event-speaking and blogging boxes, this is a quick update on the conferences I'm confirmed for so far.  Put the following dates in your diary - these are my first international solo speaking events:

7th March - QCon London - Concurrent Programming Using The Disruptor (sadly I can't stay for the whole conference as it clashes with the only holiday I had booked for 2012).
23rd May - GOTO Copenhagen - Concurrent Programming Using The Disruptor & War Stories.
25-26th May - GOTO Amsterdam - Concurrent Programming Using The Disruptor.

The presentation will be more of a user's guide to the Disruptor than anything we've done before.  An hour isn't a lot of time to cover all the functionality everyone might want to see, so I'm still trying to work out the balance between giving an introduction/overview for those who haven't seen it before, and going into some of the cool features that have been added since I first started blogging about it.  If there's anything you would particularly like to see covered, let me know - I'll put the most frequently requested things in there.

Ideally I'd run a workshop session at some point, but that will require quite a lot more preparation, so I'll only do that if there is interest in it (if someone wants to fly me somewhere interesting to do that so much the better!!).

Maybe I'll see you at one of these events?

Christmas decorations teach me a lesson about troubleshooting

And now, after an absence of several weeks, you get to see how long it takes me to write some of these posts.

I was putting up the Christmas decorations one Saturday when my worst fear was realised¹ - one of my three strings of lights was not working.

The first two went up fine.  The third lit up when I plugged it in, and in less than a second went out.  Curses.  This is not what I wanted, this was supposed to be a short exercise in making my tiny little flat look festive.

So I set about the tedious task of starting from the end closest to the plug and replacing every bulb, one by one, with a spare one to see if it magically lit up again.  When it doesn't, you take the spare back out and replace it with the original bulb.  I remember my parents going through this ritual every Christmas, the tediousness of this activity is more memorable than the fleeting joy of shinies.

While I was doing this, my mind was back on the job I'd been doing at work the previous week - battling an Internet Explorer 7 performance problem.  We have automated performance tests which give us an indication of the load time for our application in Chrome and IE, and some time in the previous couple of weeks our IE performance had significantly degraded in the development code.  Due to a number of too-boring-to-explain-here circumstances, the last known good revision was four days and nearly 250 revisions earlier than the first revision that showed the performance problem.

Since we couldn't see anything to indicate it was an environmental problem, the logical next step was to pinpoint the revision which caused the problem, so we could either fix it or get performance gains from somewhere else in the system.

The most obvious way to do this, given there were no obvious suspects, is with a binary search of the revisions.  Our last known good revision was 081, our first poor performing one was 240.  So the thing to do is to check revision 160, see if it falls on the poor or good performance side.

If 160 proves to be a poor performer, check revision 120....

...if 160 is fine, test revision 200...

...and keep splitting the revisions by half until you find the suspect.

So of course that's what I want to do with my stupid Christmas lights.  I do not want to sequentially check each light bulb, that has a worst-case number-of-bulbs-tried = n, where n is the number of bulbs (probably a couple of hundred, although it felt like several thousand).  So, in computer speak, O(n).  The binary search algorithm is O(log n).  At university, this Big Oh had no context for me.  But when you've taken 10 minutes to get a quarter of the way through your Christmas lights, and you diagnosed your IE performance problems... well, actually it took days.  But the point is, a binary search for the missing bulb would definitely have been a Good Thing.

I know you're dying to know if I tracked down the problem in Internet Explorer - I did.  What's the worst case when you're doing a binary search?  It's when the thing you're looking for is veeeery close to either your start point or your end point.

The revision number I was after was number 237.  Sigh.

And my Christmas tree lights?  Well, through the boredom I remembered that modern lights are in sections, so they have a sort of built-in binary search - well, limited segments will go dark if a single bulb is out - which allows you to narrow down your problem area.  Since the whole string was out, I figured something else was probably wrong.

Turned out the plug had come out of the socket.

So:
Lesson 1: Theoretical computer science does have a place when you care about how long something takes.  When it's you feeling the pain, you'll do anything to make it stop.

Lesson 2: When diagnosing a problem you will always biased towards what you think it is, in the face of actual evidence.  I was afraid I would have to search the whole set of lights for a blown bulb, so that's the problem I was looking for when the lights failed.  In actual fact it was a problem with a much simpler solution.



¹ - OK, "worst fear" in this very limited context only - it's not like I lie awake at night in July afraid that one of the bulbs on my Christmas lights has blown.

Video: Why we shouldn't target women

If you have a Parleys subscription, you can watch the whole "Why we shouldn't target women" panel from Devoxx 2011 a month or so ago.  Watch me attempt to monopolise the whole panel as if it was my idea or something...

How to make your CV Not Suck

When you're applying for a job at LMAX, your CV (or résumé, for our American readers) usually comes through me and I decide whether to call you for a technical phone screen.

I'm going to let you into a secret.

I'm going to tell you the criteria I use when judging your CV.

Now, you could say this is a foolish thing for me to do, because now when you apply you'll be "cheating" and writing your CV to pass these guidelines.

Good.

LMAX isn't the only company that's going to judge your CV based on these criteria. I firmly believe that an increase in quality of the CVs in our industry can only be A Good Thing.  An increase in the quality of your CV is definitely A Good Thing for you.

Even more importantly, if I get CVs that do not pass these basic criteria, now I know you either don't read the LMAX blogs (shame on you), or you're not able to follow simple instructions (bodes poorly for your ability to learn within the company).

The thing that you have to keep in mind when you're writing your CV is that the reader really does spend less than a minute reading it.  It's not fair, true.  But it's the way humans are. I'm not in HR or recruitment, I have a proper job as a software developer, and I need to get back to that as soon as I can.  When I get CVs in batches of up to 12, as I regularly do, I'm not free to spend more than 10 minutes going through all of them.

The Easy Stuff
You must be able to spell
You really must.  There are things called Spell Checkers and they are amazing.  Some of these new-fangled pieces of software even show you your errors in this cool squiggly red underline in your document.

I'm reading your CV in Open Office, and if I see red squigglies under words that aren't technologies or acronyms I'm going to wonder how good your attention to detail is.

You must use capital letters in the appropriate places
It's traditional to start a sentence with a capital.  It's also traditional to use a capital "I" not "i" when referring to oneself.  We're not 14 years old, we're not writing an SMS to our mates.  We're applying for a proper job paying proper money.

Correct grammar is appreciated
Whether you're a native English-speaker or not, you need to get someone else who is a native English-speaker to check the prose in your CV to see if it scans correctly.  For me, it's not about being prejudiced against you because you're not a natural author, it's a) attention to detail again and b) your ability to make yourself understood.  If your sentence construction, choice of words or simple comma placement is off, I'll have to read that sentence a couple of times to parse it and it's going to trip me up and ruin my flow.  I want to get a good feel for you from reading your CV, so if I stumble a few times I'm not going to feel like I connected with you.

Harder and fluffier
I don't care which versions of Spring you've worked with
I know you need a checklist of technologies on your CV so it gets past the non-technical recruitment agents and get picked up via automated searches.  This is a bigger problem with our industry than one I want to tackle right now.  So I'll let you off having buzzword bingo on your CV.  However, your CV needs to be more than just a list of technologies you have used vaguely, or perhaps once read about.

It's useful to me if a) you put the technology check list in a single place on your CV, b) you give an indication of your level of proficiency in that technology (novice/competent/master) or length of time you've used it in a commercial environment, and c) you organise them in some useful fashion - preferably the ones that are appropriate to the job you're applying for near the top, or at least those you're happiest with at the top.  Alternatively put the checklist of technologies next to the role you used them in.

Often I will completely ignore this section because I'm more interested in your ability to learn and your passion for what you do.

I want to know about your passions
In the old days I used to fast forward to your hobbies and interests, but these days we're encouraged not to put those on the CV in case you're judged against them.  Which seems like political correctness gone crazy, but then when you think about it you can infer a lot about a person from their hobbies and interests, and therefore you could be pre-judging them based on some criteria that is not at all associated with their ability to do the job.  For example, if they have hobbies that take them all over England I might infer they have a car and can drive - OK, it's a dumb example, but you get the idea.

These days, given that I'm trying to find great team members to work with me at LMAX, I'm looking for things like: your blog; any contributions to open source software; your involvement in a Java User Group (or other extra-curricular activity).  I'm not going to discard you if you don't have any of these things, but if you do it's definitely extra brownie points for you.

I want to know if you worship at the altar of technology, or if you're business-value driven
Either of these things is fine - we need people who are very business-focussed and people who are rabid about technology, as well as all those in between, to build a good team.  Another axis of interest is people/process - are you passionate about people, about building a good team, about helping them to deliver?

Getting a feel for where you sit on these axes is not for me to discard you, but if you look like you're strongly in one of these camps and I feel like we need a team member to really push that area, then you stand a much better chance of getting a phone interview.

I'll get an indication of where you are by the way you talk about your roles and your achievements.  This does not help me:

Senior Developer on a web administration application.  Product was implemented using JavaScript, HTML, Spring, Hibernate, JMS, and MySQL.

This is much more useful:

I was part of a team of four developers implementing a web based administration application, commissioned to enable internal users to update the settings of our reporting tool.  This saved the support staff approximately 4 hours every week, as they no longer needed to manually update the database. We used agile techniques such as daily standups and weekly iterations in order to provide quick feedback to the business.

(I made both of those up, by the way, before anyone starts trying to sue me for stealing something off their CV).

Here I can see:

1. The size of the team, and your ability to work in a team
2. You understood the business need you were trying to fulfill
3. You have worked in an agile environment and at least pay lip service to why you were working that way.

I don't really care about the specific technologies you used, the fact that you mentioned web-based and database gives me enough of a feel.

Sometimes prospective employers really do stalk you
Personally I think claims that prospective employers will check every facet of your web presence are somewhat over-exaggerated.  If I barely have 60 seconds to read your CV, I'm not going to check you out on Facebook, my life is too short.

However, if you claim to have written a book I will look it up on Amazon.  If you have a publication or example code, I will glance at those.  If you've worked for a company I've worked for in the past, I'll look you up on LinkedIn to see if we have any common connections (or worse, to see if I should remember you and simply don't).  I'll also use LinkedIn if your CV is not screaming yes or no, to see if there's an extra dimension in your profile which will tip me one way or the other.

So be aware of your web presence, particularly something that is aimed at your professional image like LinkedIn, and make sure it represents you the way you want it to.

In Conclusion

This post might be simply a good way to increase my own workload - every CV I get from now on may be an automatic pass, and then I have to call all of you before I can start weeding you out.

But I don't mind too much about that.  I get concerned sometimes that good people are not getting the interviews they deserve, not just at LMAX but across the industry, because they get almost no good CV advice.  Frequently the people who are the first to read CVs are agencies who are not technologists.  By all means, have words on there that will make your CV appear on their search results.  But you need to put something on there for me, a real developer, because strings of keywords tell me nothing about you.

If I can improve the quality of just one person's CV with this post, I'm happy.  If I have given you that first step towards that job you really want, then that's even better.

Video of our JAX London session

At JAX London Mike and I presented "Understanding the Disruptor - A Beginner's Guide to Hardcore Concurrency".  This is the session we initially previewed to the London Java Community a few weeks earlier.  The content is the same, but the feel of the presentation was quite different to us - the venue for the LJC event was more intimate, and it was easier to interact with the audience.  At JAX, we were up on stage, which was pretty cool actually, but meant that it felt more like a lecture and it was less easy to connect with the audience.

We received some really great feedback on this presentation, and it was brilliant to see a lot of the speakers from JAX there watching us.

Interview by the Oracle Technology Network at Devoxx

Tori Wieldt from the Oracle Technology Network interviewed me at Devoxx.  Because I was there to be on the Why We Shouldn't Target Women panel, the interview is just another platform for me to air my views on this subject again.

Yes, I am actually wearing pink....

London Java Community Open Conference

Saturday was, hopefully, my last conference of the year.  My lucky readers should start to see some posts which are not simply me gushing about another opportunity to hang out with awesome people and learn about interesting "stuff".

Who wants to propose a session?

In many ways the London Java Community Open Conference was my favourite one so far, and not just because it's near home and I helped to organise it.  One of the awesome things about both Java One and Devoxx was the opportunity to travel, to see new places and to meet people you might not meet in London.  The scale, and the opportunities to meet key players in the Java world, were the things I probably appreciated the most from both of those conferences.  And you can tell from my posts I really enjoyed them.

But the LJC conference was probably perfect as my last one for 2011:

"How do you spell 'lightning'?"

• Being on home turf with awesome people who have really helped drag me kicking and screaming into the conference scene really brought home to me what an amazing year this has been.  This time last year, I felt I barely had the credentials to be a behind-the-scenes organiser for the LJC, and I didn't attend last year's conference because I wasn't sure how much I would get out of it.  This year, I'm at the conference giving two sessions, having made my international début already.
• With 120 people you feel like you can talk to everyone at some point if you want to.  I don't think I managed that, but I probably chatted in one way or another with maybe half the attendees.  The great thing about this is you see the wide variety of things people are working on - the technologies, the business problems, the team and company sizes, the methodologies. It's eye-opening and quite exciting.
• It seemed that a small, open conference like this drives content based on relevance.  We had no vendor pitches, although John was contractually obliged to mention Atlassian at least once every half hour (but as they paid for the beer, this was only fair).  People vote with their feet, and attend the sessions that they will get the most out of.  I liked this format a lot.
• I presented alone for the first time, not hiding behind Mike or Martin.  I found this surprisingly liberating.  I love working with those guys, but without them providing a safety net I actually found my confidence increasing as I realised I was perfectly capable of answering things I would probably have let them field.
• My second session was more workshop-like, and I wanted the audience to guide what we covered.  I thought it went really well, I loved letting the audience guide it, and I enjoyed giving it.
• I was honoured (and terrified) to be asked to be part of a Meet the Experts panel with people who actually know what they're talking about.  I was very very pleased to get away with not being asked any questions about being a girl or the length of my skirt.  We had a great discussion around writing high performance code, about different technologies and their applicability, and about the future of Java and JVM-based languages.
• I loved the venue.  The rooms were a nice range of sizes, all with projectors of course, but also whiteboard space and flip charts.  It looked like a 1960s version of the future - all shiny white surfaces and curving lines.  But it felt like a space to create and innovate in.
• Mike's Hacking the Open JDK session in the morning was excellent.  Again, this was another example of a workshop format working really well.  He gave some good background to compilers in general, and a good walk through of some of the code that's there at the moment.  He was happy to share stuff he'd learnt the hard way, and it made me want to get more involved in that side of things.
• The food was awesome.

Clearly people haven't had enough coffee yet.

My sessions were User's Guides to the Disruptor - a beginner's and a more advanced one.  The beginner's was an updated summary of the Disruptor stuff already covered in this blog - the ring buffer, writing to and reading from it, and configuration.  The second session covered  more advanced ideas: you don't need a ring buffer any more; cache lines and false sharing; worker pools; aggregate event handlers. This session was a lot less prepared and more collaborative, and I loved giving it.  Maybe that's my teacher-genetics coming out.

The aim of both sessions was to give people an idea of how to actually use the Disruptor - developers are definitely interested in how and why it works, but we've been evangelising a lot and now there are very sensible questions being asked about how to get it to do various things.  I'd like to run some more of these sessions in future, and to add more material to the blog.

And finally, a proper meal before more beer.

Back to the conference.  Were there any downsides?  Personally I had none.  If I had to suggest an improvement for next year, it's that we would like to see more novice speakers presenting.  The LJC has always been about nurturing this talent, and a small conference like this one with a friendly audience, many of whom you may already know, is a great place to practice.  The lightning talks showed the great variety (and abilities) of our members, it would be nice to expand this to full sessions.  As I found, filling a 30 minute session is not anywhere near as hard as you think!

I'm really looking forward to next year's LJC conference, and I'm totally buzzing from the positive vibe from this year's.

The LJC Associates modelling their lovely new t-shirts.  Mine fits!