Trisha Gee has been a Java developer for over 12 years, and due to a low boredom threshold has worked in loads of different industries for many types of companies. Trisha is a developer at 10gen (the MongoDB people). She has expertise in high performance Java systems and is leader in the London Java Community. She is also involved in the Graduate Development Community. Trisha believes we shouldn't all have to make the same mistakes again and again. Trisha is a DZone MVB and is not an employee of DZone and has posted 60 posts at DZone. You can read more from them at their website. View Full User Profile

Staying Ahead of the Curve

03.04.2013
| 3028 views |
  • submit to reddit

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 learn 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.

 

Published at DZone with permission of Trisha Gee, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Vishal Jain replied on Mon, 2013/03/04 - 3:38am

I agree, nice article

Claude Lalyre replied on Wed, 2013/03/06 - 5:22am in response to: Vishal Jain

As technology is constantly evolving, we should not be focused on technology area. We should be assets and liabilities centric and be focused on functional capabilities. As the way of implementing functional requirement is changing constantly, we should just be aware of what it is possible to do and what kind of frameworks groups can help you to implement the functional requirements.

You should be functional-centric rather than technology-centric...




Lund Wolfe replied on Sun, 2013/03/10 - 2:37am

That's good advice about only learning the frameworks and libraries that you approve of and want to use on a daily basis.  Try to pick from those that are commonly used so that your knowledge will actually be useful (now and in the foreseeable future) and narrow that down to what you think is best from a developer/user point of view (user centered design, simple but powerful API).

Pick an area where you are weak or where the software industry is weak (and you have some interest) to make yourself more of an asset to your future employer.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.