Agile++: When Agile Goes Well

If you see anything about LMAX - the Disruptor, Continuous Delivery, or even the selection criteria for hiring developers, you’ll see that LMAX is pretty keen on Agile.  However, no-one’s documented the Agile process there, as far as I know.  Although I personally had it on my todo list, I never had the motivation, the hook to do it.  And I realised eventually that’s because I’m not sure it’s a process that would work very well for another team, in another company, working in another business.

The agile process followed at LMAX is one that works for the individuals and the organisation there.  And that’s because they do one thing very well - they regularly examine the issues faced and adapt the process to try and combat them.  It’s an agile process that’s, well, very agile - it’s constantly changing.  Documenting it would only represent a single snapshot in time that would be out of date almost as soon as the next retrospective comes along.

Any process can inspire Cargo Cultism, and the last thing I want to do is give people a process to without the tools to know whether it’s the right thing for them or not.  It’s more important to understand your goals, check progress and improve.

I was talking this through with a colleague, Israel, and he rightly pointed out the tool that LMAX can share with everyone else - thinking.  Examining the problems, visualising them, and trying out different ways to fix them.

So at Devoxx Israel and I presented a session on “Agile++”, using LMAX as a use case of when agile methods work.  The session examines four specific issues encountered at LMAX and the steps taken to solve them, and it’s available on Parleys.  Enjoy.

Summary of Devoxx 2012

Devoxx topped off a crazy two months of conferences. I've heard people talk about the conference season in the past, and been slightly (OK, very) jealous of all that jet-setting.  I'll admit, however, to a slight feeling of relief that my focus until Christmas is pretty much going to be coding.  I hope.

Neal Ford's When Geek Leaks

So, how was Devoxx?  Well for starters, the calibre of the speakers and talks was excellent.  I learnt things in every one I went to - either something I could put into practice at work, or something I could do to improve my own presentations.  My favourite was Neal Ford's When Geek Leaks - Neal is a great speaker, and this talk was entertaining and informative. I'm also currently reading his Presentation Patterns book, which is extremely useful.  Although obviously I give a bunch of presentations and have found some very handy tips in here, it's dead handy for everyone, even if you're just presenting to your boss or team at work.

The great thing about Devoxx is being able to meet all the European-based people in the Java space. People fight to get to JavaOne, but Devoxx is a lot easier if you're based over this side of the pond. It's also easy to run into people in either the exhibition area (where lunch is served, so everyone ends up there at some point), or the central corridor between the rooms (which everyone has to go through at some point).  It was really awesome to have so many people grab me either at the MongoDB booth or when I was sat at the desks in the corridor.  I really like that venue for a conference, the only downside is the seats are so comfortable, people fall asleep in the talks.  Even in our presentation (how rude).

I have a lot of personal highlights from Devoxx now I'm finally free to think about it:

  • Another re-run of The Problem With Women.  If anything, this went even better than when I ran it at JavaOne. What I really loved about the session is the sheer number of men who turned up.  it's tempting to assume they're there to heckle, but in fact their active participation in the subject proves to me that the men in this industry are very much on board with trying to address the gender balance.  As always, I have so much more to say on this subject, so I'll make a note to write a separate blog post.  In summary, although there are differences in the contributions from the audience in these sessions, there are common themes and a willingness to get involved and Do Something.
Agile++ with Israel Boza Rodriguez
  • The exclusive premier of the new Agile++ talk, co-presented with a colleague of mine from LMAX.  The aim of this presentation was to talk about where you go when your organisation starts with a great agile grounding - what problems might you face and how do you tackle them.  Bit confusing for me giving this talk since I was still in LMAX-mode, and I'm very grateful to 10gen for not only allowing me to present this, but actually promoting it for us as well. I'd love to do this session again, I'd like to work out how to without having a split personality as an LMAX person and a MongoDB person.
Not everything can go swimmingly, so I should probably make an apology for giving the Shortest Talk Ever on Wednesday.  It was supposed to be a 20 minute talk about the benefits of open sourcing your software, but it ended up being more like a lightning talk.  Lessons learned: 1) no matter how much you think you have to say about a subject, having the speaker notes is still very important (to me) and 2) a bit more preparation, updating the talk given my new role, would have been extremely beneficial - as it was, I cut a lot of the content on the fly and had nothing to replace it with.  Oh well, you live and learn.
I also had a new experience on Tuesday, being on the MongoDB booth in the exhibition space.  This was really educational too:
  • I'm glad I had a week of intensive MongoDB training the week before, I could actually answer all the technical questions thrown at me - yay me!  It's true that educating people is a really good way to learn stuff.
  • People are really interested in MongoDB. Many are using it already, but even more are wanting to learn about NoSQL in general, and Mongo specifically.  It was really awesome that Stephan gave a massive boost to Mongo's reputation, describing how the central data store for the conference technology was MongoDB running on a Raspberry Pi.  You don't get cooler than that.  Numerous other speakers gave very positive stories of using MongoDB too, so we had a lot of people stop by the stand to ask us what it was all about.
  • Although I was nervous of being on the stand after Ceri's experiences, I didn't notice anyone doubting my ability as a technical person despite being of the female persuasion   I only had one conversation where the (male) developer I was speaking to kept addressing his questions to the (non-technical) (male) sales person instead of me.  But that's fine, I just kept answering the questions, and maybe I've made a slight dent on his (clearly subconscious) assumption that women aren't techies.  I still think the best way to address problems like this is to keep persevering, keep being visible, and to not let your assumptions about what other people are thinking override your own confidence in your abilities.
And finally...
Robots seem to be cool again, and I, for one, welcome our new automated masters.  I was totally blown away by the choreographed dancing robotos on stage as a lead up to the keynote.  
I think the only way to top that for Devoxx UK is Robot Dancing Tyrannosaurus Rexes.  On caffeine.  Destroying Lego cities.

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 FowlerSimon BrownLJC colleagues Martijn and JohnZero 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.
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…?

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.


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.

A NYSE Product Manager and an LMAX Developer walk into a low latency trading seminar…

“What… exactly… were you guys looking to get out of today’s event? Because…“

"Because we’re girls?“

"Um… yes…“

Kim impetuously opts for The Truth: “We’re here to meet men.“

Our interrogator looks round dubiously.

"No, really, why are you here?“

Phew.  My reputation is intact1

Kim eloquently describes what her situation is as Product Manager and the criteria she’s measuring third party products against.  I explain how LMAX aims to be the fastest retail exchange in the world, and therefore low latency is a tiny bit important to us.  I talk about how we created The Disruptor on our path to achieve that goal.  The guys gathered around us look a little… shell-shocked.

I’m exaggerating for Dramatic Effect.  Before anyone starts getting upset about the only two girls at the event who weren’t staff or hospitality being singled out, you have to give the guys credit.  They approached us, engaged us in conversation, and had a very serious question about what we were after, and was there anything the vendor could do to either improve their offering or to make their sales pitch more appealing.

And don’t get me wrong - it’s brilliant being different in a situation like that, if people are brave / foolish / drunk enough to talk to you.  It beats the hell out of sitting in a corner trying to get up the nerve to speak to Strangers (been there, done that).

But it is quite a contrast, even from the Java events (JAX London, Java One).  There, I was in a select group of people of the female persuasion.  But I was also part of a community, and treated as A Developer.  At very specialised events (low latency, high performance in particular) diversity is almost non-existent.  You can count the number of women on one hand (if you can see any at all) and even the developers wear suits (poor bastards).  However it would probably be better if you could hide your surprise at hearing technical terminology coming out of a woman’s mouth.

But… I kinda like it.  Yes, I’m an alien.  Yes, I’m special.  But if it means you make the extra effort to speak to me, I can live with that.

1 “Extra extra, read all about it! Blogger And International Conference Speaker Only Does It To Meet Boys!”  Not quite Jordan Stalks Rugby Ace For Sperm Donor.  Which I really did see this morning.

EDIT: oh yes, and of course I forgot to plug my panel at Devoxx next week: "Why we shouldn’t target women"

JavaOne: Initial Observations

So I’ve been at JavaOne for the better part of three days, it’s time to record some of my observations so far:

  • The wireless access is rubbish.
  • <Gross generalisation> technical people are not natural public speakers.  Makes me feel better about the presentations I’m going to be giving (see A Beginner’s Guide to Hardcore Concurrency).
  • The sessions are less useful than getting out and chatting.  I’ve had a really excellent time, I’ve met: people from other Java User Groups; the Duchess girls; other Duke Award winners; the Azul guys; guys (well, girls) from O’Reilly books; JCP members and many random and awesome people.
  • Everyone thinks that Large is an acceptable default t-shirt size (it’s not).  Vendors - if you’re really serious about appealing to The Other Gender you need to stock XS, if not actual skinny tees.
  • If you’re running a conference, you should probably have your projection screens above the height of the audience members’ heads
  • People at JavaOne are dead friendly.  I’ve ended up in a lot of conversations just by virtue of standing alone for longer than 30 seconds.  It is noticeably easier to talk to people here than at the conferences I’ve been attending in London.  Not sure if that’s a location thing or a domain thing.
  • Socialising in London is great practice for this sort of event.  I am capable of taking advantage of free drink and still maintaining a conversation and staying upright in 6 inch heels.
  • I miss American breakfasts.  I’ve been gorging myself on pancakes, biscuits and gravy, and eggs benedict.  I’ll be calling my personal trainer as soon as I return.
  • Haven’t seen anything to contradict my view that San Francisco is not the Brit’s typical view of California - the weather is rubbish.  London has been hotter and sunnier this week.
  • Sharing an apartment with your CTO is not as weird as you might think.  Especially if you relegate him to the closet (no, that’s not a euphemism).
  • It’s difficult to remember to Tweet or blog when you’re totally engrossed in conversations with people.
Here’s a photo of me representing LMAX as I pick up the Duke Award we won for the Disruptor:

<div class="separator" style="clear: both; text-align: center;"><a href="; imageanchor="1" style="margin-left: 1em; margin-right: 1em;">

 (Thanks to Martijn for taking the photo).
I was grabbed for an interview which should be available (un-edited - erk!) on at some point, I’ll post it when it’s available (if it’s not rubbish).