Be an Ambassador!

You know how I keep banging on about attracting different types of people into programming?  You know how we say we need to get them young?

Typical Mathematician?

A little while back I decided to put my money where my mouth was, so I signed up to be a STEM Ambassador.  STEMNET is an organisation that aims to inspire children to go into Science, Technology, Engineering and Maths careers, and it does this by creating a network of mentors (people like you and me) and schools.  So schools can publicise the sorts of events they're running, and find mentors in an appropriate field for this event.

I was a STEM Ambassador years ago, when I worked at Ford STEMNET came there looking for people like the graduates to come and talk to kids - STEMNET likes to have a large proportion of their ambassadors close(ish) to the age of the kids, so they grab graduates working in large organisations and apprentices.  Those just starting out in their careers often think they don't have a lot to offer as mentors, but they're wrong - making that transition from education to work is a worrying thing for kids, so speaking to people who have recently done this is dead useful.

Typical Engineer?

I cheated when I was an ambassador the first time - I volunteered at my old school, where my parents were also teachers, and helped teach ICT to the boys in year 9.  It was eye-opening for me - ICT is not programming.  Tech-savvy kids were bored and the other kids didn't really know why they needed to learn Powerpoint/Word/Excel.  Personally I thought the Powerpoint lessons were useful - I was working in a large organisation where we were expected to give internal presentations, and had never been taught how to use a presentation tool, despite having various NVQs in IT that taught me all I would ever need to know about Word and Excel (these were very useful qualifications and that knowledge was relevant for many years - and no, this is not sarcasm).  But teaching kids Powerpoint when they're 13 is not useful.  By the time they get to use it their knowledge is rusty and out of date.

We were taught BASIC programming in my primary school.  And it was basic - 20 GOTO 10 stuff.  It wasn't that hard.  I mean, it wasn't for everyone, but it was fairly easy to get going, and you got the point of it - you told the computer what to do, and it did it.  I think that's what has always appealed to me about programming (insert joke here about programmers preferring computers to people because they do what they're told - if you're not a programmer, then you really don't know how much the computer can rebel against you ever damn step of the way, like a child.  A very stupid child).  I was really struck by Jason Gorman's idea that learning programming was quite a lot like learning music, and he proposed a grading system for programmers similar to that of music.  I can see the similarities between music and programming, certainly in my background - in primary school we were given introductory lessons in both music and programming as a whole class, and those who showed an interest or aptitude for either subject took up lessons at lunchtimes or evenings.  With music, that's fairly straightforward, many schools have access to at least one music teacher for the usual instruments.  For programming, this is much more difficult.  It's usually a keen teacher who's self taught leading this class.  Which is great, but many schools do not have this keen teacher.  And this keen teacher, should he or she exist, is looking for someone to learn off as well, just like the rest of us.

Typical Scientist?

We are the people the schools are looking for.  We have the experience - years of it.  We have the context for that awkward question "but when am I ever going to use this stuff?".  We can show them why it's fun.

But what's in it for us?  Well, it looks great on your CV, of course, and you'll get to network and meet with other professionals, including those in different but overlapping fields.  Kids also have really interesting approaches to problems.  It has been known for groups of children to provide novel answers to problems that have stumped professionals.  And doing something like this is really great for your confidence - if you can speak about what you do in front of a group of children, all staring at you, then speaking in meetings or conferences becomes infinitely easier.  I honestly believe that all the times I spent in a classroom helping out one or other of my parents is the reason I'm more relaxed speaking at conferences than I ever thought I would be.

Typical Technologist?

Sadly, I let my Ambassador status lapse when I got a "real" job in London, it became so much more difficult to create the time to go into a school, since clearly it needs to be during work hours.  But nearly ten years later, after talk of Devoxx4Kids and a bunch of other initiatives to get kids coding, I decided I needed at least to get my CRB (now DBS) checks done so I could work with children if the opportunity came up.  If you sign up as an ambassador, STEMNET will sort this out for you for free, which is one of the main reasons I chose to sign up with them again.

Another great thing is the induction - they're not going to let you loose with the kids without providing a bit of help and guidance.  It's only a couple of hours out of your day, and, if nothing else, gives you an opportunity to meet interesting people in other STEM jobs.  On my induction there were surprisingly few IT people (maybe 3-4).  There were various apprentices, structural engineers, dentists, ex-teachers, PhD students and... oh I've totally forgotten what everyone did, but it was interesting and sciencey.  And about half of the inductees were women, which enormously surprised me.  I couldn't help but wonder if programming is lagging well behind the other STEM jobs in terms of women doing the role, but I don't think you can draw a conclusion based on a group of people who either chose to be mentors or were pushed gently (or not so gently) in that direction.

The induction covers stuff that I've already talked about here - like why you should do this and what teachers, students and ambassadors get out of it - and some basic dos and don'ts for working with kids.  Nothing too scary, and even though I've done this before I found it useful and made me more keen to be involved.  The minimal commitment is one event a year, and this can even be something you've arranged yourself (like going into your own kids' school).  And although I've signed up for the London area, it's not necessarily geographically constrained - one of the ideas I liked the most is taking kids for a Skype tour around your office, showing where you work, how you work, etc.  I think that will help blow away some of the preconceptions around programmers anti-socially sitting in their own rooms hacking out lines of code, for example.

You'll notice the rather lovely drawings littering this post.  The first exercise we did in the induction was to draw a stereotypical scientist, technologist, engineer, and mathematician.  The point of being an ambassador is to help combat these stereotypes, giving kids real role models to look to, people who can help them see what's out there for them.

These kids don't necessarily want to be Bill Gates, Steve Jobs or Mark Zuckerberg.

Some of them want to be just like you.

My Summary of GeeCON, Krakow

Last week I was in Krakow, Poland for GeeCON.  Which was excellent!  I find it really interesting that conferences all have their own personalities, that they are not all the same.

GeeCON had its own distinct personality.  If you're a Java/JVM person based in Poland, I would highly recommend it - more than 90% of the attendees were Polish (probably the remainder were largely speakers) so this conference is very much for you.  The quality of the speakers was really good too, I learnt a lot off many of them.

From a speaker's point of view, there were some cultural things which took a bit of getting used to.  One of the good things was that the audience was very keen on asking questions, they were much more interactive than a typical London audience (for example).  However, I'm accustomed to quite short questions, and I found that the audience liked to give a lot of detail in their questions and frequently ask more than one at once - this meant that all the speakers really needed to allocate a lot more time for Q&A than expected.  One of the other things I found unusual was the number of people who would walk in and out of the room during sessions - this wasn't just everyone fleeing my session (I hope!), I saw it happen in all the talks, even the keynotes.

My stuff
On the first day I was on a panel about diversity in IT, which was basically about women programmers (again).  It was a good panel to be on, actually, because there were a range of opinions, including downright disagreement, which made for a more interesting discussion.  Sadly it left the audience with too little time to contribute though.

On the second day I was presenting "What do you mean, backwards compatibility?", which elicited a lot of responses from the audience.  I think I got the balance right between providing food for thought for any Java programmer, and enough of a look into what we're considering for the new MongoDB Java driver, that it felt like I satisfied the two audiences - those who are interested in MongoDB with Java, and those who... aren't (yet).


But it wasn't my experience as a speaker which really made GeeCON for me.  For the first time in ages I felt like I learnt something as an attendee.  I don't know if that's because a) I only had one presentation to prepare so I had time for a lot of sessions b) we have some specific problems we're trying to solve on our code right now that we're looking for answers to or c) the conference inspired it, but I came out of a lot of sessions excited about things to try.

Testing
My first take-away point is to try Spock.  I've been told for ages that I need to give it a go, but the session really sold it to me.  It seems to have features that will solve specific things we're looking at right now, including:

• Simplifying mocking
• Annotating tests with properties (e.g. @Slow)
• Running the same test with different sets of data, instead of having to copy-paste the test a bunch of times
• Reporting of failures, particularly power assert and @Unroll, make diagnosing failures much simpler.
• Using BDD terms as keywords (given/when/then) means the tests really do document themselves.

I'm totally sold on it.  I was concerned, because we're writing an open source Java library and I want the unit/integration tests to be understandable to Java developers, and I worried that adding Groovy tests might make the learning curve steeper.  But I think it's an idea worth playing with.

Asynchronous IO
So one of the things we're working on is trying to figure out the best way to provide an async Java driver.  Erik Onnen's talk around performance network programming on the JVM was really interesting.  Most usefully, it compared sync to async communication, outlining the pros and cons, and how you can do it on the JVM.

Build the right thing before you build the thing right
The first keynote was about Pretotyping - Patrick Copeland from Google was talking about ideas and innovators, and blowing away the myth that all it takes to make money is a single great idea.  He highlighted how really great ideas aren't necessarily successes, and some ideas that sound great don't feel right in practice.  Pretotyping is a way to test things like:

•  Would you use it / do it?
•  How would you interact with it?
•  Is it socially acceptable to use it in the circumstances.

Because it's very low tech, very low effort (think post-its and note pads, not HTML prototypes) it facilitates fast failure (therefore reducing the cost).

The session was videoed, so hopefully it will be available to see.  If you're thinking of An Idea, I highly recommend this talk.

Many users = anthropology, not user experience

Joel Spolksy, the man who inspired me to start this very blog (well, earlier incarnations of it) talked about the experiences of growing stack exchange.  This was interesting because it was not about the technology, but about subtle things you can do to influence user's behaviour - for example, reputation rewards "good" behaviour, and a better reputation means you are trusted to do more on the site.

This was another inspiring talk if you're interested in creating a product or company.

As always, I also met a lot of really interesting people who gave me a lot to think about.  I've come back more motivated than ever to work on my various projects.

So, Krakow is beautiful, and GeeCON is a good learning experience.  Go next year if you can!

How are you using MongoDB with Java?

So, like one of my presentations, I have a question for you.  Actually, I have more than one question for you.  I'm not going to bother with survey monkey or whatever, I want to share the answers so please, answers in the comments:

1. Are you using the Java driver for MongoDB in your application?
2. Are you using the Java driver directly, or are you using a third party library like Morphia, Spring Data, the Scala driver, your own abstraction layer, etc?
3. If you're using a third party library, why did you choose that over using the Java driver directly?
4. If you're using the Java driver directly, what do you like about it? 
5. If you're using the Java driver directly, are there any areas that give you pain?  Areas for improvement?
6. Which version of Java are you using?

Feel free to leave additional information if you have it.  And this is a public blog, so if you're really mean I'll just delete your comment.  So there.

Good overview of the NoSQL hype for Real Developers

Last Tuesday I went to a London Java Community talk which promised to debunk the hype around NoSQL.  Whether you're already bought into a NoSQL technology, or you're just wondering what all the noise is about, it's worth an hour out of your day to see Akmal Chaudhri's comprehensive summary of the technologies out there.

Skillsmatter recorded the whole thing, as usual, so you can watch the presentation for yourself.  I promise neither I nor anyone else from 10gen paid him to mention MongoDB so much.

2013 is looking a lot busier than I planned...

So, despite promising myself that I would only do one event a month for the rest of this year, looks like I'm going to be a bit busier than that.

In case you're wondering what I'm up to (or, even better, hoping to see me talk or meet me), here are my confirmed engagements:

15-17 May - GeeCon, Poland
18-20 June - GOTO Amsterdam - whole day tutorial on the new (unfinished) MongoDB Java driver.
24th June - STAC Summit, London - something MongoDB-shaped (i.e. not Java-specific)
27th June - Technology Transformation Network, London
1-5th July - In Dublin, hoping to talk to a MUG or JUG while I'm there.
22-25th July - JavaOne Shanghai (CON1148). So excited to go to China!
August - Looks like I'm going to be in Spain a couple of times (Madrid/Seville).
11-12th Sept - Love to go to JavaZone, Oslo.  We'll see.
22-26 Sept - JavaOne, San Francisco.
30th Sept - 2nd Oct - GOTO Aarhus - very pleased I can make it this year!
17-18th Oct - GOTO Berlin.
28-30th Oct - JAX London.
December - YOW Melbourne, Brisbane, Sydney - Australia.  I've never been to Oz, I can't wait!

If you've either clicked through those, or you've already been stalking my talks, you'll see I haven't actually made up my mind what to call this year's main presentation:

1. What do you mean, Backwards Compatibility?
2. Design is a process, not an artefact
3. Design is a process, not a document

This is mostly because when I signed up for some of these conferences, I thought I was going to be talking about how hard it was to write backwardly-compatible libraries (which it is).  But when I wrote the presentation, it turned out to be about software design.  And then I found out artefact/artifact can be spelt two ways, ho hum.

I'm still not sure yet if this will actually be the same (but evolving) talk under two different guises, or if they are two subtly different talks.  I guess we'll see what I end up writing the week before I'm due to present "Design is a process, not a document".

How Mechanical Sympathy got me to the airport on time

Lets talk about mechanical sympathy.  Martin Thompson has been making this term very popular in software development, so it's best to read his description of why he used the term.

I had a perfect example yesterday.  I'm about to drive to the airport and the car won't move (I'm a modern tomboy, I can write stories about hair and stories about cars). Not at all.  It's stuck.  I can't reverse out of my parking space.

The first thing that occurs to me is something is stuck under the car.  Like a cat.  Those buggers hide in the stupidest of places.  So I get out and check there's nothing wedged against the wheels, which seems like the most logical thing that would stop the car moving.

(OK that's not true.  The first thing that occurs to me is oh-my-god-I'm-going-to-miss-my-plane-and-I-haven't-got-a-backup-plan-to-get-to-the-airport-and-I've-already-paid-for-parking-and-I-would-like-to-cry-now-but-that's-not-going-to-help)

Since there's nothing under the car, the next thing that occurs to me is the handbrake is stuck on - it feels like it's the rear left wheel that won't move, and I know (probably as I had a similar problem on my previous car, my lovely but ancient MX5, or maybe because I've seen far too much Top Gear) that the handbrake applies to the rear wheels.

I also suspect that the handbrake jamming this is the correct answer because I put the car through the car wash on Monday, and the known issue of the brakes jamming on some Volkswagens always manifests in my car after the car wash.  I should probably just let it get dirty.

Because I'm big on tests, and scientific theory, I test this hypothesis.  I rev the hell out of the car and force it backwards.  OK, I'll be honest - this wasn't a test.  This was a brute force attempt to unjam the handbrake. But it did provide a suitable test - when I got out of the car to inspect the offending wheel, I could see skid marks on the floor where the wheel had been dragged, rather than rolled, over the tarmac.  Oops.

So my (limited) knowledge of how a car works has provided me with a hypothesis, and reasonable proof that it's correct.

That's all fine, but I'm still not on the way to the airport yet.  How did I fix it?

What do you think I did? Well, I drove it back and forth a view times, hoping the jolting and extreme discomfort of the brake pad against a moving wheel would unlock the brake (from previous experience, the brake clicks off, rather than simply easing off).

Of course it didn't work, and I'm probably going to have to replace that tyre much sooner than expected.  Ooops x2.

I sat in the car and pumped the foot brake millions of times - a trick that either inexplicably worked on the MX5, or simply distracted me long enough and the brakes fixed themselves eventually.

This didn't work, not surprisingly (not the same brakes after all).

Finally, I got out of the car and kicked the wheel a few times.  Hard.  I figured this might jolt the brake back into position.

It didn't

Then I used my brain.  That's not going to work when you unconsciously put the hand brake on when you leave the car to kick the wheel.

So I took the brake off, then kicked the wheel.  Hard.  A lot.

And it worked!!!

And this is a bit like diagnosing performance problems (no, really).  My basic understanding of how the car was put together, plus some experience with similar problems in the past, gave me guidance on where the issue was and what might be done to fix it.

So, what have we learnt today, boys and girls?

• A basic understanding of how the hardware works can prevent you calling an expensive expert to do a simple fix.
• Always have a backup plan (Disaster Recovery/High Availability - if not hardware, then at least some sort of process).  I was much more stressed because without the car, I had to come up with a whole new transportation plan with a very limited time budget and having no knowledge of or experience with alternatives.
• I need to drive my car more, because then a) I would have either discovered the problem sooner, or b) it would never have got to that point.  I'm going to say that in this tenuous analogy, the equivalent is to do testing in a live-like environment, and actually do DR scenario testing.  Then you know how your hardware and software behaves under abnormal circumstances, and have some concept of how to get back to normal.

I did make it to the airport on time, because adding padding to your estimates is a Good Thing and gives you a bit of space for contingencies.  So this story does have a happy ending.

Here endeth the lesson.

Devoxx UK 2013

Last week was the first Devoxx UK, bringing the brand from Belgium and, more recently, France.  And I think it was a HUGE success.

Of course, disclaimers first - I was on the programme committee, so I might say that the whole thing was awesome.  Although in all honesty, even being slightly involved in the organisation of a conference is a lot of work, and you can't wait to see the back of it (and I didn't do half as much as some people).  Note to self - never speak at a conference you're on the programme committee for, it's too much work.

As a speaker and attendee though, Devoxx was really brilliant - great speakers, interesting content, awesome friendly atmosphere, good venue, parties with free drink and good opportunities to speak to people.  There were downsides: limited coffee availability, no free croissants, um... I'm really struggling to think of anything else, and none of those are show-stoppers (especially when the venue is in Islington, so you can step outside and get whatever you want).

All throughout the run up to the conference we kept hearing it was a conference "for developers, by developers" until I was nearly sick of it.  But it was a mantra that kept us on track when we were deciding on content, and it really came through on the two days of the conference.  Pretty much everyone on stage was, or had been, a developer, the talks were a good balance between "useful" stuff for our day jobs and "interesting" stuff for techies <insert joke about some being "useful" and "interesting">.  The future track excited us with things like like hacking on the Raspberry Pi, and the rest of the conference had a good mix of Java SE, EE, methodology and Other Stuff.

For me, the highlights were:

• Kevlin Henney's keynote, reminding us that Developers Are Human.  Who knew?
• Sandro Mancuso's walkthrough of OO principals, and how they apply to us in our actual day jobs.  Sandro did a good job of taking quite a dry topic, that many of us dozed through at university, and showing us why we already use these principals and how understanding them will make us better programmers.
• Mazz Mosley had an entertaining talk about the Dark Side of Agile, walking us through the agile practices in The Government and highlighting many of the unanswered questions that teams have after switching to agile.
• Colin Vipurs's talked about Test Driven Development from the trenches - he managed to give a good intro for those who might not have done it in practice, but for those who may have been doing it for a while, this a) was a good reminder of good practice and b) gave a good insight into why we do it.  On top of that, he had solid advice on how to write better tests, that we could all take home with us.
• Martin Thompson gave the talk I was attempting to give at JAX London last year - what is performance and how do we achieve high performance in Java?  Where I failed, Martin really rocked it.  I'll be leaving that to the professionals.
• It would be rude of me not to mention this point - what a diverse conference!  We had developers of all shapes and sizes, from the suits to the mohawks, of all colours, and (by technical conference standards) lots of women.  Watch the video below and I think you can see it.  I was so proud to have been a part of it.
• ...and meeting everyone.  What an awesome conference for networking!  Of course, there was a large number of London Java Community people there (speaking, volunteering, and attending), and quite a few familiar faces from Devoxx Antwerp - it was brilliant to see them in London.  But I was also very pleased to run into people I've worked with in the past, some I haven't see for ages, and some I still see regularly.  And I met dozens of new, interesting people - you guys really made the conference for me.

I was giving my new presentation, What Do You Mean, Backwards Compatibility?  In this talk I share some of the experiences I've had in helping to develop the new MongoDB Java driver.  This is not really a MongoDB talk, although there are some examples from the new driver, it's more a talk about design, and how we as developers make design decisions every day, something I don't think we recognise very much.  As always, I'll post a link to the video when it becomes available.  However, I am hoping to give this presentation a number of times this year, so if you missed it there will be another opportunity to see it.

As usual, my take-away theme from a conference is probably influenced by the sessions I attended, so is as much a function of what I think is important right now as it is an indication of what themes are emerging in the industry.  But I came away from Devoxx feeling like there's a desire to focus on the basics - the OO principals that have been around for years; the good design practices that have been written about many times; and, most of all, a reminder that developers have a difficult job - we don't simply turn requirements into code, we are constantly doing tricky stuff like system design, and even trickier stuff like working with other people.

I loved Devoxx UK, and I wasn't alone in feeling a bit empty when it was all over.  To re-live a tiny amount of the event, or get a good feel of what it was like, watch this video by the awesome Roy van Rijn.

Devoxx UK 2013 - Long mellow version from Roy van Rijn on Vimeo.

As with all Devoxx events, the talks will be available on Parleys.  If you watch nothing else, watch Kevlin's keynote.