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’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.
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…).
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?