Staying Ahead of the Curve

I had an interesting discussion last night at the LJC developer sessions, and it's a topic that comes up again and again:

How do I stay ahead of the curve?  There are so many technologies out there, and more coming along, I can't even keep up with Java, let alone the other JVM languages, HTML5, JavaScript frameworks, NoSQL, Big Data.... argh!

Technology, particularly development, seems to move at an ever-increasing pace.  Sure, the Internet makes it a lot easier for us to get access to information than in the Olden Days, when people probably had to read papers and books, and physically meet up to share knowledge, but that just makes the sheer volume of information even more overwhelming.

So how do you keep on top of all those technologies?

You don't.

You can't.  If you devoted yourself to learning the same way you did at university (pfff, well, theoretically you devoted yourself to learning...), you could still never master every technology out there, and every new language and framework that pops up daily.  Even people who pick a technology stack that's suitable for purpose (let's go with the old favourite Spring/Hibernate combo) can't read every blog post about those technologies and see every conference talk that was ever videoed.  To be the best even at Just Java, you'd have to be a master of concurrency, understand garbage collection, have read all revisions of Effective Java, know every detail of all versions of Java, including all the changes coming in Java 8, be aware of all the JSRs in progress.  They'd have to have read about waterfall development, the Mythical Man-Month, XP, Scrum, Lean, Programmer Anarchy, so that they could know they are working in the most effective way for the business and team they are in.

All that as well as working 40 hours a week on the day job.

So to expect to know the ins and out of all current (and maybe dated) technologies, and all upcoming ones - not knowing which are just fads and which are going to be the Next Big Thing - is impossible.

But don't you ask candidates how they stay current when you interview them?

Yes I do. And actually it's their willingness to at least try, and their ability to filter out and select the things to investigate or be aware of that interests me, not their deep understanding of Scala when they're working in a JEE environment (for example).

There are two reasons that I can think of to "stay ahead of the curve":

1. To be more effective in your job
2. To get your next job

If you're aiming for point one, it's a little easier to filter out the noise and focus on what's relevant.  In your place of work, there are going to be hard limits on new stuff you can use.  For example:

• Your systems guys will not allow new languages, even JVM ones, in a production environment.  In which case, you don't need to worry about learning them in any detail.
• Your company has paid a heavy subscription fee for their existing database, therefore they will not be trying out funky NoSQL solutions.  Fine, you don't have to research them.
• You're working on a messaging system with no UI.  In which case, you can let the new JavaScript frameworks rise and fall without worrying too much about them.
• You work for a consultancy that specialises in government work, and documentation is sacred.  So, don't worry about going to a bunch of agile/lean conferences, you probably won't be able to sell it to your customers.

Now I'm not saying these circumstances apply to everyone.  And I'm not suggesting these are necessarily the best situations to be in.  But you can look at your current position and, if you intend to stay there, it might rule out a lot of the technology/process learning that's available.

Point one suggests good places for research.  For example:

• You're using Spring dependency injection and you don't speak XML fluently.  So you might research Spring wired up via Java and annotations, or you might look at Guice, or you might do a bit more reading around good practises in XML, or tools you can add to your IDE to make your life easier (Eclipse and IntelliJ both support XML refactoring).
• Your Ant scripts are killing you, and you don't know where your library jars should live.  You could read a lot more about Ant, you might look into Maven, Ivy, and Gradle (hint - gradle is awesome if you don't like programming in XML).
• You spend all your time coercing objects into something Hibernate-shaped, and not actually delivering new functionality.  Maybe you could become a Hibernate guru instead of just poking at it like most of us do, or you could investigate different persistence frameworks or mechanisms.

You get the idea.  If you feel pressured to keep learning and you're not looking for a new job, there's plenty you can be doing within the framework of your day job.  The best thing about this is that you might even be able to persuade your boss that you need to do some or all of this learning on work time, leaving you more time for your kids/spouse/drinking/XBox.

I'm really much more motivated to learn skills to find that great new job

Point two is a bit more tricky.  When you're looking for a new job, it seems like every job description contains all technologies under the sun; it seems like interviewers expect you to be an expert in all sorts of different areas; it's impossible to tell which jobs are good and which are poor, so you apply for everything and try to learn everything to get to the interview.

Now if you're already at the applying-for-a-new-job stage, you might not actually have time to learn everything under the sun.  And if you're still working at the current place and just looking around to see what's out there, you might not have time to train yourself up on all those great new JavaScript frameworks while doing the day job.

How on earth do you pick which things to focus on?

Well, it's surprisingly easy.  Just pick the ones that interest you.

But what if I'm falling behind on technology X and it turns out to be The Next Big Thing?

Well, by the time it becomes the next big thing, you'll have heard enough about it to know whether or not you care  - either because it interests you or because it's so big you should care.  And by then, there will be plenty of knowledge out there (blogs, courses. conferences, books...) so you'll be able to pick it up much easier than when it was at the embryonic stage and no-one really knew what to use it for. Java is, what, 17 years old now, and people are still starting to learn it now.  No-one said you had to have coded with Java 1.0 in order to be effective in a Java 8 lambdas world.  In fact, you could argue that those who learnt it early on might be less able to adjust to the current state of play.

So.  Learn something because it interests you, or it's fun, or you personally can see the value of it. Even the process of learning something new is valuable, even if the thing you learnt is not - it exercises those brain-muscles so they're used to picking up something unfamiliar and playing with it.

But I see a thousand jobs for Scala/HTML5/<insert tech here>! Should I learn that?

Have you looked at Scala?  Do you like it?  Do you want to learn a whole new language?  Do you want to spend the next two years of your career working in Scala?  Because if you learn it to find a new job, and you do find a new Scala job, then you're going to have to use it, and to continue to learn it. And if you don't really give a crap about Scala, then why bother?  Have you looked at the types of companies that are advertising jobs for Scala?  Do you want to work there?  Again, if not, don't bother.

In our industry, particularly if you live and work in places like London, New York, Silicon Valley, there are lots of jobs, even in these Tough Economic Times.  You don't need to take any old job (unless you need a job Right Now, in which case I would advise you take Any Old Job and work on the side to find The Right Job to move to imminently).

The point is, you're freaking out because there are all these different technologies and all these jobs that are looking for different combinations of all these different skills, and this is a Good Thing.  You've been looking at it wrong - you think you need to be everything anyone wants, so that someone out there will pick you, like some sort of school sports team selection.  But it's not like that - the selection power is in your hands.  You can wade through those millions of job postings and find the ones that interest you.  You can invest in becoming skilled at the things you like, the things you enjoy, the things that scratch your intellectual itch, and you can then find a job that matches those skills.  Even better, if you're active in learning those skills, and visible at it (stack overflow, your blog, communities...), you're going to improve your chance of getting a job in the area that fascinates you.

You don't have to be good at everything.  Just find the things that interest you, stuff you feel motivated to learn about, and then when you find a job that uses those skills, you know you're in the right place.

So in fact, there is only one reason to stay ahead of the curve:

1. Because you want to.

So it's much easier to figure out what to spend time learning and what to ignore for now.

You don't have to stay ahead of all the curves.  You just have to stay within tolerance of your own curve.

Upcoming Events (and Trisha Freaks Out A Bit)

My next few talks are where I finally start speaking about MongoDB.  After 4 months working for 10gen, I still feel completely under-qualified to speak with any authority on the subject.  It's very different joining a company with an established and growing product, to joining a very young company and being in on the development since practically day one.  But I've been working on designing the Brand New Java Driver, so that's what I'm going to talk about.

At this stage, the new driver is still very much a prototype, and we have a lot of ideas to explore, so I'll be talking about things like design considerations, and the process of developing the driver, more than definitive guides on how to use it.  I've found working on a library very different to working on a platform or internal application.

19th Feb - London MUG: Into to the new Java driver

5th March - QCon: Tutorial (well, more like hack-session) on the new MongoDB Java driver

8th March - QCon: Making Interviews Rock (with Dan North)

14th March - LJC: How to give technical presentations

21st March - LJC: Possible speaking slot (TBC)

26-27th March - DevoxxUK: Talk TBC

18-20th June - GOTO Amsterdam (maybe!!)

Looking at that list inspires a number of different emotions:

1. Fear.  OMGIhaven'twrittenanyofthosetalksyetandthey'reallgoingtobeterrible.  Also OMGIsignedupforfivetalksinMarchalonewhatiswrongwithme?  And OMGhowcanIgiveatalkongivinggreattalkswhatifthattalkisterriblenoonewilleverlistentomeagain.  Etc etc.
2. Pride (in a good way).  Last year, QCon London was the first solo presentation I gave at a conference.  This year I've had to turn down more conferences than I even spoke at last year, and I'm being encouraged to talk on a range of subjects that interest me.  I miss the comfort of presenting on the Disruptor, a subject I got to know very well, but the variety is fun.
3. Astonishment.  I'm presenting with Dan North.  And it was his idea.  He wants to be on stage with me and co-present with me.  This is mental, Dan's pretty much a role model for me (don't tell him I said that) and it's crazy to be doing something together.

Now I tell you all this not to share with you my #FirstWorldProblems, some sort of desperate bid for sympathy (although I'm always blown away by the nice things people say to me when they think I need encouragement).  But because people keep telling me again and again how they could never do public speaking, how I'm so lucky it doesn't scare me, how they have nothing to say that anyone will want to hear.  And they're wrong, because I'm not lucky.  I'm stubborn.  It does scare me, especially new material that people might not like.  But it can be fun, and it's worth pushing through the (very understandable) reluctance in order to get the payoff from the times it does work.

Anyway enough of the moralising.

As well as the speaking gigs, I've also got some interesting interviews lined up, and I've been asked to write a lot of stuff for various publications.  I'd like to say that's why I'm not blogging, but since I haven't started writing those yet either....

Interviewed at Devoxx

Yolande Poirier from OTN interviewed me at Devoxx about my new job at 10gen, Women in IT (bet that surprises you), how to be a role model, and Agile.  Enjoy.

Wrap up of 2012

Fortunately for me, the guys at JAXenter chased me for a summary of 2012 and my predictions for 2013 - I say "fortunately" because otherwise I never would have got around to doing it, and that would be another year slipping away silently into the abyss.

Here it is in all its glory.

Devoxx: The Problem with Women - A Technical Approach

As well as talking about, you know, actual work-type-stuff, I was encouraged to give my "Technical Approach to Women" presentation at Devoxx.  This went so well at JavaOne that I thought it would be difficult to top.  Also, I wasn't convinced it would work at Devoxx, because the theatres are not well suited to audience participation - the seats are warm and comfy, the room is dark, the speaker is on stage in front of a massive screen....

I was incredibly impressed with the audience.  There were literally hundreds of people, most of them men.  To me, it proved once again that the men in this industry are determined to "fix" this problem of gender imbalance.  And they're happy to extend that to improving diversity as a whole, once you highlight the bigger problem.  It says to me that this is not naturally a misogynistic industry, where you have to fight against the boys club to get anywhere.  It says to me that we are all in this together.  After all, in the "real" world the geeks are still outsiders, and different, so we're used to embracing our different-ness - whether that's because you're the only girl in the room, the only Java developer at a .NET conference, or the only techy at a dinner party.

Conferences are a self-selecting audience, I know - these are the people who are investing time and money in advancing their careers, or at least encouraging their employers to do.  But for the punchline of this session, these are exactly the right people.  We need to go out, tell everyone how much we enjoy our jobs; tell kids that programming is cool, and show them it's fun; mentor other people, and each other, and be a role model.  I don't care what gender you are or what colour you are or what your dark secret is - you are the role model to inspire someone.

Just do it.

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.

Webinar: Processing High Volume Data Feeds with MongoDB

Hot on the heels of my very first MongoDB webinar, I was... encouraged... to do another.  Here at 10gen we've been running a series of webinars around using MongoDB in the financial services domain.  Yesterday was the last in the series, and was presented in association with C24 - John Davies, their CTO, did most of the talking, and demonstrated their product for automatically turning financial messages from one format into another.

(Slides and webinar available here - and you're not going deaf, the sound doesn't start until about 3:44 into the video)


It was a fun webinar to do, actually - I didn't know anything about C24's iO tool, so I learnt quite a lot as I watched John navigate the demo.  My background in trying to debug raw FIX messages probably skewed my questions, I was definitely more interested in how to use it as a developer and what it could give me if I were doing production support.  It's a dead interesting tool - I know for a fact that many organisations, banks in particular, spend a lot of time translating stuff from one format to another, before making some decision on on what to do with the contents.  This tool does all the heavy lifting so you can get on with the interesting stuff, the stuff your business actually needs you to do.

In addition, as someone with more of an FS background than a NoSQL background, I was very interested to hear how lots of the financial institutions are using MongoDB already - the combination of not having an enforced schema but supporting structured data, supported by fast execution, makes it a good fit for a lot of the problems they're trying to solve.  Yes, it's my job to say nice things about MongoDB, but when businesses are already using it because it makes their lives easier and meets their needs, it gives you a warm fuzzy feeling that the product must be doing something right.

I enjoyed giving this webinar, I think if I do any more I will suggest pairing on it (we all know two heads are better than one, right?) - it gives you some of the feedback and energy that's hard to get in a darkened room talking to a microphone.