GOTO Amsterdam

Three airports and three hotels in a week, and I don’t know whether I’m coming or going.  Add to that a mere four hours sleep last night, and this might resemble the ramblings of a mad woman (more than usual that is).

GOTO Amsterdam was a different affair to GOTO Copenhagen, which is not necessarily a bad thing - it’s great that the events have their own personalities and aren’t cookie cutter versions of the same thing.
Great communal area for meeting people, in a unique venue

Amsterdam was smaller and shorter, and therefore felt even more intimate than Copenhagen, which didn’t exactly feel massive either.  The venue was beautiful and imposing (and not at all air conditioned!), which I think also contributed to its unique feeling; the timetable felt less intense (although both conferences had a reminder that the next session was going to start, great for moving people at the right times); there was a different mix of attendees and speakers (fewer Danes and more Dutch for a start); and the coffee was marginally better in Amsterdam.

Both conferences were very friendly, but Amsterdam felt even friendlier - possibly because it was smaller, or maybe it was me because I was already in the Conference Zone, but people were coming up to chat to me from the very first minute, which is great for a shy person like me…
The Java Track
Anton Keks demonstrating simplicity in Java

I was very pleased to see Anton Keks kick off the Java track with a talk to pull us developers back to reality.  Instead of running off to find a shiny new language to fix our problems, we can toss away overblown frameworks and enterprise architecture and write nice, simple Java.  We can even go against basic conventions to make our code more terse and readable.  While I’m not sold on all suggestions (e.g. not using curly braces for single-line if statements) I’m totally behind the theory, and it led nicely into my Disruptor presentation.

At Amsterdam, rather than being relegated to a smaller room up a lot of stairs, my Disruptor talk was in the main, grand hall. This is not always a Good Thing, because standing on a large stage tends to separate you from the audience, and one of the things I like to do is have a lot of questions and interaction from the audience.  I think I pulled it off better than I have in the past, just because I was aware of the problem.  I even forced some of the audience to move from the back to closer to the front to give the illusion of intimacy - I totally didn’t expect hat to work!  The session went really well and I got good feedback - it might actually have gone better than in Copenhagen, but I think having given the same presentation the previous day probably helped.  And although I like having it videoed so more people get a chance to look at it, it’s nice when it isn’t - you don’t feel the pressure of having mistakes immortalised and replayed infinitely.

I missed all of the Agile stuff at Copenhagen, so I tried to make up for it in Amsterdam.  Interestingly I felt like I saw things from two different types of practitioners.  

Firstly, you get the war stories of trying to fit agile into an organisation that isn’t used to working that way - conferences have been showcasing these for quite a few years now, and it’s still really important to continue showing the different types of obstacles and how to overcome them (and why - the benefits you get when it starts to work).  What’s different I think is the types of company that are now trying out agile are the sorts of organisation that never would have used it in the past, because it appeared too unstructured and not rigorous enough.  I think this is a good sign of the increasing maturity of agile and its acceptance into common practice.
The other types of practitioners are those who’ve set up their whole organisation on Agile principals, from the ground up.  These companies are waaaaay ahead of what you read in books, and have problems that are really only just starting to be talked about as these companies grow up and scale up.  LMAX falls into this category, but I was both surprised and pleased to see other organisations doing similar things to us and facing some similar challenges - in the past I felt that we were alone with no-one to learn from, but it seems I was wrong in that.  I’ve now got a few ideas I want to take back with me that are certainly worth discussing back at the mothership.
The Lego Keynote was interesting, it’s fascinating to see how another industry works to balance creativity and constraints (costs, lack of manual dexterity in small children, marketing/branding guidelines etc).  I’m still mad at them because of the horrible Lego Friends thing aimed at girls, but I did come out of that thinking I really really want to work for them.  Not sure it actually helped me in my day job….
The keynote taking lessons out of Zen and the Art of Motorcycle Maintenance"" was quite thought provoking.  The main things I remember were around combating frustration and boredom - we need to create working environments which allow you to step away from a problem and come back ready to face it again.  And we need to allow ourselves to do this.  
Multiple sessions, including this one, talked about flow - how when you’re in the zone (as a developer) you can be creative and productive.  Creating environments and processes that not only enable flow but encourage it is going get the most out of your developers.  As a bonus, it’s going to attract other great developers to join you.

So, after the end of a long week…
Despite the extreme tiredness, the unexpected heat and unwelcome hay fever, I’m feeling pretty creative and full of ideas right now.  I’ve thought of quite a few things I’d like to present on - more fluffy things than just the Disruptor - and I’ve got some projects I’d love to work on.
I really hope that survives past moving apartment (today - argh!) and going back to work.  Events like these are designed to make you think and to try and help the industry move forward, it would be a shame to lose that momentum in the every humdrum details of life and work.

GOTO Copenhagen

So,  before everything gets pushed out of my head, GOTO Copenhagen.

It was my first conference "alone", in that I didn't have friends and colleagues from LMAX or the London Java Community there with me.  And certainly at the start of the conference, I wasn't the only one who was standing around, hoping someone would talk to me (in all honesty some of the photos above are a little unfair - the schedule was a very nice, simple phone app so most people spent a lot of time playing with their phones).

It actually turned out to be an advantage to be alone, as I met a lot of interesting new people.  I was impressed actually by how local it feels - i.e. many of the speakers and attendees were from Copenhagen or at least Denmark.  I liked this, because the alternative is that the conference feels like lots of the usual suspects travelling from place to place, doing the same thing and not really giving much to the city it's hosted in or getting much out of the location.

There was a bit of noise on Twitter, although not as much as at larger conferences.  Actually I think that meant that those who were on Twitter were awesome at connecting up in real life, so I met a bunch of new people who'd originally seen me or spoken to me on Twitter.
War Stories; Coding with the Stars; Coding Using the Disruptor
My sessions were a bit of a mixed bag.  I presented my war story on tracking down a performance problem in IE7, but the most interesting thing about this session was seeing the other two speakers' war stories.  At the end of ten minutes of me talking extremely quickly at the audience, I had no questions - so either my explanation was crystal clear, or I blasted the audience into submission with my caffeine-fuelled nervous energy.  I'm guessing no-one wanted to ask "Can you repeat all that please?".
On Wednesday I paired with a member of the audience on a coding kata - I was really hoping to show TDD (old-school, not TDD as if you mean it), a bit of how to pair (i.e. how you communicate during pairing and why it's dead valuable), and some attempt at showing how you think about your design in a vaguely Domain Driven way.  Although I covered all those areas, I think an hour was barely enough to do one of them justice - I think the tension between showing those three things meant I didn't demo any of them particularly thoroughly or well.  Still, the most interesting thing there was comparing my session with Steve Freeman's, which was directly after - same kata, same language, and totally different approach.  What I hope people got out of this was that there is no One Way to Rule Them All.  
Also, Java is not a good language for getting results in an hour.  Sadly.
My main event was my Disruptor presentation using car assembly as an analogy, which readers of the blog may already have seen in one of its previous incarnations.  At least this time i didn't get a red unsmily face on my feedback like I did at QCon London (whoever you are, tell me what you didn't like!!)

Keynotes - they always force you to learn something new

The keynote on Dart was interesting, I started off feeling very sneery about some shiny new language from Google, but I ended up wondering if we could us it anywhere within LMAX - it's got curly braces and OO, but it's Javascripty.  In a good way (I think).
I took a lot out of Don Reinertsen's keynote and his session "The Tactical and Strategic Art of Economic Models".  Maybe it's just my OCD, but I really like the idea of having actual numbers to allow you to make decisions - understanding the cost of various options as well as the potential gains allows us to make much more informed decisions.  In fact, he points out these numbers don't have to be monetary, but having some uniform way to compare relative costs and benefits of taking certain paths is enough.  Even with average (i.e. not terrible) intuition the range of opinions on the cost of something is 50:1 - that's a big range.  And different people will make different choices based on what they think those costs are.  Michael T. Nygard's DevOps talk also uses numbers on cost to make decisions on whether to actually fix a defect or not.
Rich Hickey's keynote also gave some food for thought.  The main thing I took out of it is that "facts" only have context when associated with a time.  This makes total sense to me, and ties in nicely with some of the stuff we do at LMAX - for example, although it's not specifically time-based, the Disruptor sequence numbers make it clear what's the most recent event, and ensures ordering and repeatability.   It also ties in with some of the stuff in Dave's Continuous Delivery"" book (sorry Jez, everyone else except LMAX call it Jez's book) - everything, including your configuration, needs to be in source control or some other managed repository, this way you can always get repeatable builds, because its not just the code that impacts the way your system behaves, it's your configuration, your dependencies, so on and so forth.  Having everything trackable by time or revision numbers or something to tie it all together to allow you to get a revision from a specific time makes your releases more repeatable, and makes it easier for you to do things like track down defects on a specific build in production.

Speaking of Continuous Delivery...

There was a lot of good stuff at GOTO around this.  Dave's book was referenced on more than one occasion.  I don't know if it's because that's a conference with quite a heavy lean towards agile, but it seems that getting stuff predictably and regularly into production, and not just being able to compile it and run the tests, is becoming not just an acceptable thing for teams to strive for, but a desirable one.  It's definitely not an easy journey.  But it gives you all the great agile benefits like: fast feedback (from regular releases); decreased waste/inventory (as code is deployed to production as quickly as possible); decreased risk from both of the above things.  
On top of that, it could be argued that by striving for continuous delivery you're driving your design in a nice direction: modularisation, reduced coupling (e.g. if you want to make it possible to deploy individual components), separation of concerns (e.g. feature switches forces you to not have functionality tangled up in your code).  And then there are advantages to the organisation, as in order to create a smooth pipeline from the developer's machine to production, your developers will need to understand more about the environments the system is going to be running on, especially if they're writing/configuring tools to automate releasing.  They get particularly good at this if they're the ones getting the phone calls at evenings and weekends when the release goes wrong...
This moves nicely into the DevOps side of things.  It was particular interesting to hear Jeffrey Fredrick from TIM Group talk about the challenges they faced in moving from using managed hosting to an in-house infrastructure team.  It sounds like they've faced very similar issues to those LMAXare working on right now, and I'm very much looking forward to meeting up with Jeffrey back in London so we can exchange ideas.  It's so rare to find anyone with very similar problems to you no matter what your technology or industry is, and it'll be dead interesting to swap stories.

In Conclusion
I think GOTO Copenhagen is the first conference where I spent all the time in sessions - I didn't have gaps in the schedule, and on the whole I got something from all the sessions I went to.  I often feel like I won't have much to take back to work with me when I see new technologies that we don't need to use or people espousing TDD and pair programming, but these sessions, and the keynotes, all gave me something to think about.

Other themes I haven't really mentioned were the same sorts of things I heard at QCon London - e.g. there's always more than one way to do something, and sometimes it's enough to be simply Good Enough.
GOTO was a relatively intimate conference, with a limited number of attendees and relatively small rooms, so it felt easy to talk to new people and by the end of three days I saw familiar faces to smile at wherever I looked.
I'm looking forward to Amsterdam now, although my brain is already full and I'm not sure how much more I can fit in there!

What Do You Do and How Did You Get There?

So yet another interview with me is available, but this one is in written form.  It’s for the Graduate Developer Community, the aim is to show undergraduates and graduates what real techies jobs are like, and how people doing them they got there.

It’s long, but if you know anyone just starting out their career who wants to get a feel for where they might want to go, please point them at it.  The site has a number of interviews with people in different roles so it’s quite a good way to showcase the diversity of what’s available.

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.