Staying Ahead of the Curve

Last Thursday I gave a keynote at GOTO Berlin to address the problems of deciding how to learn a new technology/framework/process (Spoiler Alert: it's not by putting it into production).

I presented a shorter, more succinct version of this talk at The Lead Developer.

During the talk I show an example of how not to implement lambdas, and I also demonstrate a very crude performance test for using parallelStream. I'm not going to link to the performance test as it's not a shining example of how to write these sorts of tests, but if you're desperate you'll be able to find it in my Github repo.

I also talk about how amazing Spock is, so if you're interested you can read more about my experiences with Spock.

This talk was built off an earlier blog post I wrote, about how to decide which technologies to invest your personal time in.

EDIT: The talk has been updated for 2016 and the Agile aspects emphasised in a version presented at Agile Manchester.

I'll leave you with this crude decision chart and the mind-map of potential ways to play with a technology. Remember, learning to say "no" to a technology can be very powerful.

Decision Flow Diagram

Approaches to trying new technologies

PS I'm thinking of writing a book, Career Advice for Programmers. If you're interested, let me know (because, you know, I've got loads of spare time for another project, sigh...).

Presentation Abstract

We all want to stay ahead of the curve - after all, that's what you go to a conference for. But have you ever considered how being ahead of the curve might be dangerous?

Using a new language before you understand it, putting a technology into production so you can learn it, abandoning "old practices" before you've got the benefit from them… These things are common practice, under the guise of Progress and Keeping Up To Date.

But while we shouldn't be running around like headless chickens chasing the next Shiny New Thing, we do need to see to our Continuous Learning and, of course, we should Embrace Change.

How do we balance these two extremes? And how do we see to our own growth and learning as techies while meeting the needs of our project, team and organisation?