Becoming a Fully Buzzword Compliant Developer

Transcript

Gee: This is a semi-serious talk, it genuinely outlines some of the ways I stay up to date in technology but there's also a certain amount of tongue-in-cheek nature. We all know that managing our careers, I hope you know that managing your careers there's a certain amount of hacking the system or figuring out how to look good or how to look as good as you actually are at stuff. Some of this is around hacking the system that we have to work within in order to manage our careers. Some of it is perhaps not being nice to the system.

I am a developer advocate for JetBrains, I mostly work with IntelliJ IDEA. I mostly work with IntelliJ IDEA, that means staying up to date in terms of technologies, largely Java, but more generally, architectures and things like that. I need to understand what developers are doing, what trends are coming, what seems important, what perhaps doesn't seem important right now. This is a very important but difficult part of our job, how do we actually figure out what to invest our time in, in learning or finding out more about? I'm going to let you into some of the secrets of how I do this, specifically for my job.

What qualifies me to talk about being a fully buzzword-compliant and give you career advice? You look like you don't need career advice from me, you're fine. I have an all-star LinkedIn profile, therefore I am good at what I do. I'm not sure, I'm good at attracting recruiters to try and recruit me for inappropriate jobs that I don't want to do. As parts this, I have been endorsed for a bunch of skills and technologies. I want to tell you how to add some of these new skills and technologies to your LinkedIn profile, which is important because, this reflects our entire net worth as human individuals.

Tips on Surviving the Technology Industry

Basically, this talk is about how to survive the technology industry, how to stay on top of this tsunami of skills, and trends, and architectures, and processes, and all the things which are happening around us, how to try and stay sane in this not-so-sane world.

Let me give you an example of the insanity of our industry. In the recent past, like maybe about 5-ish years ago, I started doing Developer Advocacy, about 6-7 years ago. Around about the time when I started doing this, we were talking about asynchronous programming, NoSQL, distributed version control, JavaScript, HTML5, continuous delivery, DevOps, and cloud. About 2 years ago, when I did my first iteration of this talk, we were talking instead not about asynchronous programming but specifically about reactive ways of programming. We weren't talking so much about NoSQL, we were talking more about Big Data, how NoSQL might be a solution to that.

We weren't talking about distributed version control anymore, we were just all doing Git. Everything else here, everything in gray is all the stuff we stopped talking about because we were just doing it. This is the things that became normal and we stopped seeing it at conferences because we just do it now. I can't remember the last time I talked about HTML 5 because it's just what you do.

On top of that, today we have more things to worry about as well, things like blockchain, containers, Serverless, security, machine learning/artificial intelligence, and maybe even ethics seems like a good thing to start talking about as well, certainly in conjunction with machine learning and artificial intelligence.

That's quite a lot of things to look at. We've seen some of the things which we were talking about which we're now doing, some of those things have evolved into something slightly different. Let's look back a little bit further and see if we can learn a little bit from history. We were talking about things like Prince2 and Scrum. No one's talking about Prince2 and Scrum anymore, I think there was a talk about Scrum at this conference but, generally speaking, everyone's just doing Agile, in some forms, with a little A. No one's talking about Subversion anymore, basically Git won that war. No one's doing Flash anymore, that's all HTML 5 and JavaScript. No one is doing AWT front-ends, we're not doing Swing front-ends, we are not using Java for front-ends because it's a ridiculous technology for UI technology.

Then, of course, test-driven development is dead so we're not doing that anymore. Oh, wait, no, it's not dead, we are doing that, that's a good thing to do. Static typing, we don't want any static typing anymore. Oh wait, TypeScript, we should have some static typing, that's a good idea.

You can see, in our industry, the trends come and go. Some stuff just dies and we never see it again, some stuff evolves into something else, some stuff comes in and out of fashion depending on who's the loudest voice at that time.

How Can We Avoid Extinction?

It's crazy, how do we figure out which of these buzz words are important? How do we figure out what to invest our time in? It's really not about what's important, it's actually about, "How do we, as individual developers, avoid extinction? How do we make sure our skills stay up to date so that we can get that next job?" Not that anyone in this room is actively looking for a new job, I know you're all very happy in your current roles. You don't have to put your hands up in front of the camera, it's fine, but you do want to make sure that your skills stay up-to-date and that we don't become extinct, and we don't get too narrow, and that we can move into the sorts of roles that we want to move into.

Step One: Awareness

Step one to avoid extinction is denial. No, it's not, it's not denial. It's awareness, step one is awareness. Let's figure out what's actually happening, what does the landscape look like. Now, you're at a conference, so this is quite a good place, you're already well on the way to step one because, just looking at the agenda, you can see the themes and trends that are current right now.

The way that I do this is I use sites like InfoQ - this video will be available on InfoQ, so that's all. If you just look at the sections on InfoQ, that shows you some of the areas which, apparently, are interesting, where the trends are, where the information and up-and-coming stuff is. If you look at the articles themselves - I don't mean read the articles, don't be silly, I mean look at the headlines in the articles and see what technologies we're talking about. We're talking about things like HyperScript, a JSX alternative, on standard JavaScript. Let's just assume that about half of these will be a new JavaScript framework or something to do with JavaScript, which is no longer fashionable, will be replaced by something else tomorrow, and then, replaced again the next day, because JavaScript is like that.

Python is now super trendy again because of machine learning. Playful leadership, that sounds fun, literally. Event-first thinking, so event's still trending with JavaScript. Goodbye, JavaScript, hello C#, JavaScript's coming and going. DevOps and cloud. Still Monolith to Microservices, we're still talking about monolith to microservices, I thought that was done. Kubernetes, that's big for the last year and this year, and, of course, artificial intelligence.

Just looking at the front page of InfoQ - I think it was yesterday or the day before - just looking at the front page gives you an idea of what sites like this and their authors think are important, up-and-coming trends, or things that are important for developers to know right now.

There are other sites as well, you've got DZone. DZone has its own sections which are interesting to find out about. We're talking Microservices, we're talking about time series data, Big Data - apparently, we're still talking about Big Data. Low-code, this is fascinating because I open this up to take a screenshot for this presentation and I thought, "Low-code application development," and I did not know what low-code was. I actually went away and read that article so I could blag my way through low-code. That's the point of what I'm talking about, you read these things and go, "What's that?"

DevOps of course, Cybersecurity, Java - I had to highlight Java because I'm a Java person, Java is still relevant, it is not dead yet. Then, of course, there's other sites, we've got cloud, and AI, cloud IDEs. As an IDE vendor, I wonder if we care about that. JavaScript of course and other stuff here.

You can use these sites to just get a feel for what's up and coming, what's trendy. Also, you can do a quick Google - this is what I did last week to see what I should be putting in this presentation – quick Google for, "What are the top 10 tech trends I need to know right now?" Just the TLDR, don't read the article, just look at the headings, it's fine. That's how you get started. Autonomous things, augmented analytics, AI-driven development, digital twins - that popped up 2 years ago as well. Edge computing, immersive experience, blockchain - blockchain is back. Smart spaces, digital ethics and privacy, quantum computing.

If you look at a lot of these different articles, you can see the commonalities between them. Blockchain comes back in there, so perhaps blockchain is an interesting thing to start looking into. We can use the amalgamation of this data to figure out what's trending, what seems important, and what doesn't. Of course, on top of that, as I mentioned, Twitter. This is my TweetDeck, and I don't read Twitter, I just pop in and out. You see trending words and who's talking about what.

You can also sign up to a bunch of newsletters. I highly recommend this last newsletter here because I slave over this every month - it takes me half a day or so - but every month, all of my hard work of reading all of this stuff and figuring out the trends. I dumped that into one single newsletter so that then all you have to do is just read that newsletter and you don't have to do the work that I do. Please do subscribe to that; that will mean my job here is done.

Once you've got all these links, all these interesting articles, save them all to Pocket, let them die, never read them. That's how it works.

Step Two: Speaking the Lingo

Step two, speaking the lingo. Now that we have actually started surfing the tsunami of all of these skills and technologies, we can start dropping these things into conversation as if we know what we're talking about. You work with people like this, you know this.

Now we've done our research, we know that what we're doing is we're building containerized reactive Serverless microservice blockchain big data and machine learning applications. That's what I'm working on right now. Let's break this down a little bit. Containerized, what does this mean? Containerized is Docker, except for Docker that's so 2 years ago, now it's all about Kubernetes. All the talks that I saw at this QCon were largely Kubernetes and Orchestration, but the most interesting talk for me, here at QCon, was "Why Developers Shouldn't Care About containers?" It says, "Imagine a world where developers don't even need to know what a container is." Great, I don't care about containers anymore because this talk says I don't need to care about containers, so I'm not going to find out anything about containers. I didn't even go to that talk.

Next up, Microservices. I think Microservices has been such a trendy word for so long now that we're were well past the chasm now and we're all doing Microservices or pretending to do Microservices or wishing we were doing Microservices. We don't need to invest our own personal time upskilling as developers doing Microservices because either we're doing it at work already or we're not doing it at work already so we don't need to learn about it, so we don't care. Microservices is fairly well established, rightly or wrongly, but that's where we are with Microservices.

Serverless - well, I'm a Java developer so I don't care about Serverless because I work with Service, so let's just skip that one.

Blockchain is something to do with money or possibly Bitcoin. I'm hoping some people in the audience aren't getting angry at me for saying that because this is not true, but I don't really know much about blockchain. Something about encryption, and contracts, that's as much as I need to know to understand, that’s blockchain stuff. At a conference like this, there's a bunch of talks on blockchain. If you really care, you go and find out about it.

I know about Big Data because I used to work for MongoDB. Big Data is where you stick as much information as possible into data lakes, and then, have no freaking idea what to do with it, that's Big Data. What we need, once we have Big Data, is we now need machine learning to go and figure out all of the stuff that we don't know, and just set these algorithms off to find interesting stuff. I actually have a degree in computer science and artificial intelligence, which of course I have never used, but still, machine learning to me sounds a little bit like things could go horribly wrong. Particularly, when you talk about encoding our own stereotypes and understanding of the world into machines so that they can make our mistakes much faster and much more often.

With machine learning, you can't just go and build a hello-world machine-learning app, so that's something that maybe I'll look into later when it feels slightly less scary.

What we can do though is let's look at this last word, reactive. Reactive, that sounds interesting, all the other stuff sounds like architecture-y and difficult to prioritize in my spare time as someone trying to skill myself up, reactive sounds like something that maybe I might actually be able to look into and play with as a developer.

Step Three: Enough Knowledge to Be Dangerous

Now we've identified that, let's move on to step three, enough knowledge to be dangerous. We're going to do step three just on the reactive section. This is literally something I had to do for a talk on reactive programming here at QCon London, I think it was 2 years ago. I had to go away, find out what reactive was, and have enough information to give a 15-minute presentation about a technology I didn't fully understand. That's what developer advocates do.

Reactive is an overloaded term, as you may know. Who's doing anything with reactive, anything? Not many of you. I'll be more specific, who's doing things like RxJava, Reactive Extensions? That's more of you than said you were doing Reactive programming, interesting. Reactive is an overloaded term. We have things like reactive systems, we have things like reactive programming, and we have functional reactive programming.

This is my first part of my confusion. When I'm building a reactive system, what does that mean? When I'm building an application which has the word reactive in there so I can add it to my CV, what does reactive mean? I saved to Pocket one of these articles I read on one of these websites and this is when I started actually reading the articles in Pocket. It says, "Functional reactive programming was very precisely defined 20 years ago. The term has been used incorrectly to describe technologies like Reactive Extensions. Most libraries claiming to support FRP are almost exclusively talking about reactive programming and it will, therefore, not be discussed further." This is my justification for going, "Right, I don't care about functional reactive programming now. Strike one thing off my list. Not important."

Then, when I continue reading that article, it shows me a bunch of other stuff like, "Reactive is a set of design principles. It's event-driven versus message-driven. Instead of thinking about programs, we think about systems, or what about the resilience of reactive systems, and what about the elasticity of reactive systems." That's just the heading from the article, just skim the article, you don't have to read it in depth. Having read that, reactive systems sound hard. However, reactive programming is available in all good languages, and some bad ones too. I'm going to focus not on reactive systems, which is about resilience, and messaging, and architecture-wide stuff, I'm going to look at reactive programming for which I could write a hello world application, which is all a developer really wants to do.

Let's look at reactive programming. Obviously, I go to Wikipedia to find out what reactive programming is. "In computing, reactive programming is an asynchronous programming paradigm oriented around data streams and the propagation of change." What does that mean? What it means is, every time you go and Google anything on reactive programming, you get these bubble diagrams which mean nothing, and you spend the whole time going, "Ok, so time is one of those axes and you've got before and after, but I don't really understand what that means." All you do is you read so many reactive-programming articles until this makes sense. I think it's a bit like monads and functional, it's just something that you just have to bang your head against until you get it. Well, that's certainly how I found it. Yes, bubble diagrams, that's a nice way to understand reactive programming.

What I do is I go away and I read all of the articles I saved that mentioned anything about reactive programming and figure out which reactive programming library I should be using. It seems to me that RxJava is the one that's most talked about, probably because Netflix, everyone wants to be a Netflix. I'm going to go away and implement something in RxJava. Note these words here, "RxJava for easy concurrency and back pressure." We're going to come back to this later.

Step Four: Code

I'm ready for step four, coding. Now I've done my homework, I've done my research, I've surfed my tsunami of keywords. Now I can actually sit down and try coding something. Most of us, as developers, the first thing we usually want to do is start writing the code on something. "How do I learn something?" "Write code." That's fine but there's not a lot of point in writing code for some framework, library, tool, or whatever that is dead or dying, or something that actually is not that interesting to you, or not relevant, or not valid. Before you move on to step four, you have to do steps one through three first. Figure out what's important, figure out what's interesting, and then, start diving into doing some code on something that's relevant and interesting.

Reactive programming - I can write some code now. Apparently, with RxJava, what I need is an observable and I have a bunch of other interesting stuff I can do with RxJava which I couldn't do before. Before I started doing the reactive programming, I'd written a presentation on Java 8 for streams and lambdas so that I could learn Java 8 streams and lambdas because that's how developer advocates work, you will see. I thought, "Well, this looks quite a lot like my Java 8 stuff." What I'll do is I will take my Java 8 streams and I will turn it into RxJava. If I do that, they're almost exactly the same. All I have to do is change some of the words, and I've changed the method, return type, because it works in a slightly different way.

This is the naive approach to learning a new piece of technology, this is how you learn our RxJava, this is how developers play with new technologies. I'm going to change the method signature because it works in a slightly different way. I'm going to change the parameters. I have to change some of the words, some of the ways I create my steam, I don't create a Stream.of, I do an array. I subscribe instead of collecting. I don't need this distinct word anymore, I don't know what that was for so I just throw that away because it doesn't work on RxJava. Then yes, I'm done, I've converted my application to be reactive. Job done.

There's a slightly subtle point here, I had to do one tiny thing to get this actually work, because when I did that conversion, it just didn’t work, it just sat there. It processed three elements, and then it just stopped. I didn't really understand what it was so I had to add a magic incantation here. It turns out that those words, "Easy concurrency," and "backpressure," particularly the word backpressure is really important in RxJava. Who knew?

It turns out that, if you know about reactive programming, part of the point is to externalize the fact that, when you've got events flowing through your system, you have to be able to deal with what happens if they're coming through too fast or faster than you're processing. What do you do with the events that back up here? Do you drop them or do you try and parallelize or what do you try and do? It's a really important thing to think about, but it's a completely different concept to using Java 8 Streams, which is an API for pausing collections. This is a completely different way of thinking.

How did I solve this problem? Well, you know where I went to solve this problem. I Googled, "Why is it not working with RxJava?" and Stack Overflow came up and said, "Hey, look you need to put this magic incantation of concurrency on flatMap." Then, all my tests passed. That was fine, I just got it all working. I didn't actually need to understand very much about how stuff was working under the covers, which is terrifying and actually that's how a lot of us developers work when we're coding stuff, particularly when we're learning inside the job. We spend a lot of time going, "Why isn't it working? Try this, try that. All the test passed. Fine, leave it alone, walk away." It's done. Of course, if you've got tests, that's great. Sometimes you don't have tests and no one complains about it, so you never touch the code ever again.

Step Five: Update CV

Step five is easy, we're running this really quickly, which means it's good because actually what I would like to do is answer loads of questions, if that's possible. Start thinking of questions because this is going much faster than I expected. Step five, update your CV. This is easy, just put "Reactive" on your CV. Oh my goodness, I went through this so fast.

In Summary

Let's do the summary really slowly. Step one, awareness. It's amazing how few people actually do this. I'm speaking in terms of developers but anyone working inside technology, I know that we are quite often overwhelmed by the amount of terms, and technologies, and changes, and processes that come our way. Often what a lot of us just do is, "Oh, no. Don't think about it, it doesn't matter." Or we get massively overwhelmed and we start to burn out because we think we have to learn everything. We don't have to learn everything, the first thing you need to do is just literally find Zen in surfing the tsunami. Just listen to all the terms which are coming, listen to the trends. You don't have to know everything about everything, you just need to be aware of them. That's the first step.

How do you do this? This is fairly straightforward, get yourself on Twitter, you read Twitter. Don't read everything, just let it come your way. Newsletters, like I mentioned, user groups. Who's a member of a user group here? I'm disappointed in you. Who is a Java programmer? Oh my goodness, you all have to join the London Java Community because it's an enormous community, they have loads of events. The reason why I'm standing on the stage talking to you now, the reason I have my current job now is because of the London Java Community. It was astoundingly good for my career, I cannot over stress how important the user group was for my career. The events are free, you go to them in the evening - you don't even need to go to them, just see what the events are on, and you get the idea of the trends which are coming. If you go to the events, you'll meet people who are doing from the technologies you're interested in.

You speak to those people and you say, "Is it interesting? Is it useful? What business problems are you solving? Is it enjoyable for you to work with? Is your company hiring?" that kind of thing. User groups are enormously useful, and you're here in London, and it is just such a fantastic place for user groups.

You saw my two children here earlier, I recognize, not everyone can go to user-group stuff every single night. It is worth joining and being part of the mailing list, seeing the events which are coming along and, every now and again, going to the events which are on technologies which are interesting to you. I'm still a leader in the London Java user group, by the way, so that was not a completely impartial piece of advice.

Blogs and tutorials. There's a load of stuff, blogs and tutorials, online. There's a really good site which has got occasional good bits of Java blogs like Idea, the Idea blog. That's the one I write for, by the way, the blank looks coming my way. Blogs and tutorials - the internet is amazing, there's so much free stuff out there, there’s so much stuff that you can just skim it and figure out what's going on without having to pay for it. It really is quite lightweight.

Step two, speaking the lingo. Now I got an idea of which technologies are coming, of which things seem to be trending, which things are interesting, which things people find easy, difficult. Now I can start sounding like I know what I'm talking about. "Wouldn't a Reactive approach solve that problem?" Then, step away from the conversation and let everyone else argue about it. You look really smart and you don't actually need to know anything about reactive, just be aware of the words. I'm half joking but I'm not 100% joking.

Step three, enough knowledge to be dangerous. This, I would say, a good yardstick. I'm back in London, so I can have my London mentality is "Enough knowledge to blag your way through a conversation in the pub." I would like to specifically talk to the women and underrepresented groups in here as well. You know, the white men are doing this all the time, they're just telling you they know all this stuff, and you're like, "Oh, you sound really knowledgeable." They're no more knowledgeable than you are. We need to step up and start engaging in these conversations as well. You just need to have enough to be able to have a pub conversation about something. The other guideline is "Enough to blag your way through an interview." In London, sometimes a conversation in the pub and an interview, they're sometimes the same thing. It's the guideline, "How much information am I going to need to know to sound like I know what I'm talking about?"

How do you get that much information? Well, you still use the free resources, the Twitter, news groups, blogs, etc. You can go a bit more in-depth by doing online courses, some of which are paid for but there's plenty of free online courses too. There's a bunch of short 5-minute screencasts on stuff which will give you an idea of what it feels like to program with something, what it feels like to use a particular tool, technology, language, framework. By watching those things, it's almost better than you having to code and get in the dirty code in its own right. The online videos and stuff are really useful.

Of course, conferences. You just jump straight to step six. You're already here and, I assume, you might work to pay for this conference because it's not super cheap. You're already way down there, you've got plenty of knowledge on you. The first QCon I came to was about 2007, I came as an attendee, and I was overwhelmed and blown away by the amount of information that there was out there, particularly really exciting stuff that I wasn't doing in my day-to-day job.

About 4 years later, I ended up in a job doing a lot of the stuff that I'd heard about at QCon London. At a conference like this, you can look at all these things and go, "What's interesting? Is it the process stuff I'm interested in? Is it the technology stuff? Is it the architecture stuff? Which companies are doing what interesting stuff? Where do I want to steer my career so I can start doing the types of things that sound interesting?"

I'm going to date myself a bit, this was like 12 years ago I heard about pair programming, I heard from Dan North about behavior-driven design, I heard about selenium for UI testing, I heard about GWT for using Java to write web front-ends, which was an astoundingly bad idea but we ended up doing that anyway. When I heard all that stuff, I'm, "That's where I want my career to go." I invested in learning more about that and finding the types of companies that were doing those sorts of things. Amira's laughing I forgot that Amira worked me when I was working on GWT. Yes, it was a great idea, I'm sure it was fine.

Step four. Only when you've done steps one, two, three should you start coding. You can start coding on whatever you want to but I wouldn't arbitrarily pick some technology to start learning with. I'll give you an example. When Java 2 came out - slightly dating myself - when Java 1.2 point came out and this new framework Swing came out, I started writing applications and applets actually in Swing because I'm, "Oh, this is the new technology. I'm going to need to know this when I graduate university or I will not be able to get a job." I spent a whole year of all my spare time creating this Swing Applet. Then, of course, once I graduated university, I never used that technology ever again, because we were doing JSP, and HTML, and web front-ends and that basically threw away all of that time because I hadn't done my homework of, "How likely is it that companies are really going to be doing this? What trends are really on the rise? Is it just a case of one person said, "Applets and Swing? That seems like a good idea."?

Where can you learn about stuff for coding? All of the previous - Stack Overflow, a big heavy important resource for when you're coding, and books. I know a lot of us don't read actual paper books anymore, a lot of us don't even read Kindle books anymore because there's so much stuff on the internet that it feels like we don't need books. Once you start going in deep on one particular topic or one particular framework, it is worth getting an actual physical book and reading information about, "What is the mindset behind this technology or framework? How am I supposed to be approaching it?" Instead of actually just hacking it together so it just works, which is what we do a lot of the time, actually trying to think about it in terms of the right way to do it, and the books are sometimes the way to do them.

How do we start coding? In which places? We can have our own pet project. One of the things which can be interesting - I'm not going to talk about if it's good or not - it can be interesting to employers if you have a GitHub profile with pet projects in there. They don't have to be perfect, they can be literally just toy-pet projects, but the fact that you have some pet projects there available can be interesting to employers. For senior developers, it's not so important, but for juniors it's quite a good way of breaking that barrier into your first, second, or third job, because it's very difficult to differentiate yourself between the other juniors. For seniors, it's not as important, but it's worth having a pet project if you're trying to showcase, it's a portfolio of your code, if you like. This is one way to try out new codes.

Alternatively, if you don't feel like starting a whole project from scratch, because it can be quite a lot of work, join an existing open-source project. For example, when I was at MongoDB, I worked on the MongoDB Java Driver, which is open-source, but also on a project called Morphia which is basically like Hibernate for MongoDB. That was quite an interesting open-source project too, so people would come in, submit some pull requests. We particularly like pull requests which improve our documentation, that's always really good too. This is a good way to get involved in a project that already has a mature codebase, and perhaps see how other people work with a particular technology, and learn from other people without having to start from scratch.

Sometimes you can find a project at work, it might be on another team or it might be something you do on 20% Time. Does anyone get 20% Time? I'm really impressed, more than two people. 20% Time sometimes might be a good place to start trying out new technologies. There are different ways of trying stuff out.

Step five, update your CV or LinkedIn, and then, you can add your buzzwords to your buzzword bingo card. Buzz both of them, Reactive Java and RxJava.

This URL, it we'll have a link to the video of this when it's published, it's got a link to previous video of this talk, obviously all the slides. All of the resources I mentioned, I've written a bunch of stuff about career advice because it's something I feel quite passionately about because I learn a lot of this stuff the hard way. Please do go and visit this.

Questions and Answers

Participant 1: Thank you very much. A lot of this really resonates with me because at my first job, I got really entrenched in a really proprietary system where I didn't really learn anything new and I had to do all this to get my second job. Now my second job is consultancy where I have lots of choice of tech and all that sort of thing. It works, it totally does. Now, I'm overwhelmed with all of the things that are being discussed at work because so much is discussed at work. I've got an ever-increasing list of things that I want to learn, some professional and some personal. I don't know how to prioritize stuff that I do for professional stuff versus stuff I want to learn for personal things. Basically I'm stagnating because I can't decide what to focus on. Do you have any advice in that regard?

Gee: I absolutely do, I've always got opinions and advice. That's a great question. One of the blog posts I've written is how do you stay ahead of the curve and how do you prioritize the stuff that you want to learn about. This talks about how you learn the things. Yes, it's very hard, there's always stuff that you need to learn at work. Examples I can think of, how can I more effectively use Spring, how do I understand annotations so it's not magic that I don't understand? Versus "Ok, maybe I'm interested in Kotlin or other the JVM languages that we're not using at work, how do I prioritize those?" When you have time outside of work to invest in that, then you can do a bit of both.

Now I have two kids and I have no time to invest any of that stuff, I'm, "I'm only going to learn the stuff that I want to learn," because work is work, and if they want me to know something, if they want me to be effective at my job, they need to invest in me or they get less than optimal work.

It's easy for me to stand up here and say, "Your work should pay for that or give you time for that," but that's the reality I would like our organizations to work towards. If your job needs you to be effective at a particular thing, they should be investing a certain amount of time in that," Maybe in 20% Time, or training courses, or conferences, or whatever. When it comes to investing your own personal time, I firmly believe you should work on the things that you want to do, because there's two reasons. One, it's your personal time and you want to do stuff that you want to do, you should enjoy it. You don't have to work on technology in your own personal time, by the way, you can go running, you can hang out with your kids, you can hang up with your friends. You can go drinking because you are in London and that's what you do in London. I do it in London.

If you're investing your own personal time, you should enjoy it, you should do something you want to. The reason that's good too is that, if you're learning something that's not applicable to your current role, it will become applicable to your next role. If you're investing in learning, say, Kotlin, probably you're going to be looking at jobs which are Kotlin-heavy and you'll have the skills for that. If you invest in what's relevant for your current job, you're just going to continue having the same job again and again because you've got the same skills and you have to apply them again in a different company. If you're going to invest your own time, only work on the things that you want to work on.

Participant 2: I have just two questions. The first question, you shared very useful links like trying to find from InfoQ website and DZone. From last year, I discovered ThoughtWorks’ TechRadar, I find it quite useful, so I don't understand your opinion about it, and why you did not like to share.

Gee: I was just thinking, when I was talking to you, about prioritizing the things to learn, I was, "I should have put TechRadar on here." I actually used to work for ThoughtWorks for 3 months, and so, I should've put that on there. TechRadar is a really good way of figuring out like what's up and coming, what companies should be investing time and resources in, and therefore, as a developer, "What skills do companies want?" so TechRadar is a good resource to figure out what's up and coming. ThoughtWorks, is for you to spend a bit more time on Kotlin, that would be really interesting - just saying. JetBrains invented Kotlin - ThoughtWorks aren't paying enough attention.

Participant 2: The second question from a .NET developer. When you try to learn new stuff I find quite trendy and quite new stuff going on in Java or in Python world and in Go world, but what stops me to go there is because it’s not in our stack. What would be your advice? Should I be exploring the new stack and those frameworks? I feel I can't get investment back from them, or anything back from those, so should I just step to my own ecosystem in .NET framework or should I ... ?

Gee: Your question is basically "Should I go deep or should I go broad?", effectively. When you're talking about broad, you're talking about multiple languages. This is very much a personal thing, there are plenty of people who like to be jack-of-all-trades, in which case being broad is something they want to do, and it's also something they bring to the table in their career There are certain members of your team you may know, members of your team who can hop on this, or hop on this and hop on that because they've got broad, shallow-ish, but effective broad knowledge and they are happy in those roles because that's their skills and that's what they want to do.

There are other people who you probably know in your team and organization who are very good at this one thing but you can't stick them over there because they're out of the depth. If that's what they're happy doing, if that's what they're good at doing and that's what the organization has hired them to do, that's fine. In terms of going broad or deep, it's really about personal preference.

Some people talk about the T-shaped thing being broad-ish but a bit deep in one area. For me, I was always a bit more of a jack-of-all-trades but I've always stayed within the JVM world. I'm aware of what's happening with the other JVM languages but haven't really played with them. Since I've been a Java advocate, I've gone a lot deeper on Java, specifically Java the language. I also need to be aware of the other JVM languages and I need to be aware a little bit of the other stuff that's happening in the Python world, Go, and .Net as well because .NET is like a cousin of Java.

It's a personal preference thing. Do you want to be an expert in one thing, which sometimes makes some of us feel uncomfortable because we don't want to be an expert, or do you want the variety but sometimes that makes other people uncomfortable because they'll be doing stuff they're not 100% sure about? You have to pick it and go with it.

Participant 3: Where do you put that on your CV if you're aware of other stuff?

Gee: How do you shape it on your CV? For me, a lot of that is around the personal statement at the top of your CV, so you just set it out in the first couple of sentences, "I am - I don't know - a full-stack..." God, I hate these terms, things like, "I'm a full-stack Java developer. I have end-to-end experience and I'm looking for a role where I would use all areas of my expertise." Or, "I've been doing Java for 20 years, I know the language inside out, I'm looking for a role which utilizes my deep experience."

The thing about CVs, and I'm just going to do this very quickly but God knows I have CV advice. See, the CV does two things. One, you have to have the buzzwords on there to get past the machines, to get past the search engines. Stick the buzzwords at the bottom of your CV so it doesn't get in the way of the humans because the humans have to read the CV. Put a load of the buzzwords, all the technologies, everything that you are comfortable doing in the day job, not everything you've ever learned, the things you'd be comfortable doing in the day job, stick them somewhere on the bottom, perhaps put a number of years of experience against it in some sort of tabular form, but, right at the beginning, in your personal statement, say, "I am this sort of develop and I'm looking for this sort of role." Because that's the first thing, and possibly the only thing, a human is going to read on your CV.

Participant 4: When you've found your interesting new technology and you've learnt a bit about it, and you've maybe played with it yourself, and you think it's this great thing, you want to use it, how do you then go about convincing the gatekeepers in your company that this is something they should let you use in production systems?

Gee: I have another talk about that. I don't have a good answer to that because, a lot of the career stuff is learning about yourself, learning what your strengths and weaknesses are and how you inhabit the roles you do in your company. I've found that I'm very good at talking to people outside of organizations like this, I'm less good at persuading people inside organizations. I'm not very good at that side of things.

One of the places I used to work, one of the ways they used to do that is literally someone would go away, lunch times and evenings, and implement something like, use a new build system, use an alternative build system, and then say, "I've built it. It works," and people go, "Fine. We should start using that then."

Another way is, particularly for new languages, the Microservices' way of working is quite nice because you can try out a micro service in a particular language, as long as it's small enough, and then, you can see, "Does that work? Does that not work?" But it depends a lot on the organization. When I worked for the large investment banks, there's just no way of getting anything new in, that's the reality of your world is the architects who are going to be making those decisions. When you invest your own time learning a new technology, often you're doing it for yourself and not for work. It's very much a function of your organization. The only way I've really seen people being effective at that is literally implementing it in the technology or framework they want and then saying, "It's done. Tough luck." That's how you sneak it in.

Another way is using it in test frameworks, or test harnesses, or the testing language. For example, you can use Groovy or Kotlin to test Java, and then, once you got Groovy and Kotlin in there for testing, "Oh, ok, let's put it in production code because we already use it, so why not?"

Participant 5:Once you written your hello-world program, do you have any tips for retaining that knowledge? If you have your pub conversation a year or 2 later, you're still able to say everything?

Gee: No, I'm very bad at that. As an example, I gave this presentation 2 years ago and I had to basically almost rewrite the whole thing to remember what I was talking about. This is very much down to an individual, I know plenty of individuals that, once they've written something, they have that in their brain. The way that I learn is I'm great at exams because I'm good at cramming just before something, and then, all that knowledge falls out of my head straight afterwards. The way that I retain the knowledge is either by doing it all the time, so my Java knowledge is up-to-date because I do it all the time, or knowing that I need to set aside some time to rehearse in my mind, not necessary talks, unless I'm going to an interview.

I know the set of interview questions people often ask Java programmers, and of course the interview questions are nothing to do with what you do in your day job, they're just interview questions. Before a new interview, I go and re-revise all those stupid interview questions they're going to ask you about concurrency that you never use in the day job. If you know that you're going to need a certain amount of knowledge, you need to set aside some time to re-review some of that stuff. The only way to get something to stick on your mind is to do it all the time.

Moderator: I've got a question for you actually, Trisha [Gee]. You've scanned all your websites, you've found the buzzwords, you've found the technology that you're interested in, you've learnt about it, how do you then go and identify a company that you can work with that uses that technology?

Gee: You can scan the job sites. You put in the keywords into the job search, you'll get a bunch of those. You'll just end up being in touch with a bunch of agents because that's how recruitment works in London specifically. You talk to the agencies and you say, "I'm looking for this kind of thing." Honestly, and I know I said this earlier, user groups are the best way to find these sorts of things. User groups and networking, real human beings, that's the best way. Open source too.

When I was at MongoDB, a lot of the people we hired working on the drivers were people who had contributed to the open-source driver software. We were, "We've seen this person's code, we've seen how they work. We support remote workers for the driver development, so we will hire this person." Open source is one way, user groups are another.

I quite like to go into the user groups where there was a presentation and you learnt something. What I preferred was the pub nights, not for the drinking, although that did feature heavily too, but it you go around and you chat to as many people as possible. You might be surprised, I'm quite a shy person, I found that really hard, but I would go and talk to people and say, "What do you do? What are you working on?" If someone's working on, say, Reactive or RxJava, then you say, "What are you doing in your company? Is it interesting? Do you like it? Is your company a good place to work or do they have ridiculous rules that I'm going to not work with?"

You do a lot of interviewing people who work for other companies to see if they work in the type of role, and the type of company, the type of team that you want to work for. It's really about people. For my first probably 15 years of career, I did everything through the agencies and you have to do everything in terms of search terms, and your CV has to look a particular way, you have to say the right words to the agencies. There's a trick to that, but I've been much more effective since I've actually spoken to real human beings about where they work, what do they do, what does that feel like.

It's not about some places are terrible and some places are good, it's about some places suit the way that you work and some places don't. When I worked at LMAX, we did pair programming, which I've never done before, and it turns out that's really how I want to work. It's a very effective way for me personally to work. Now I would go around and say to other people, "Are you working in a pair-programming environment? Do they really invest in it? How does it feel for you?"

Participant 6: We did love the speed of your talk so please keep up that speed. Within my company, there are also a lot of very experienced developers that are basically in the denial stage of extinction. Do you have any experience getting them out of the denial phase and then to move on to acquiring those new knowledge and new experiences?

Gee: When you say you've got experienced developers in the denial phase, are we talking about experienced developers who helped to lead the direction of the team or experienced developers who are good at just getting on and just doing it?

Participant 6: Just doing it, just stuck in doing their day-to-day job.

Gee: I don't have a lot of advice for that. I've identified that a big proportion of developers are "Just get your head down and just do the job." That's fine, except that it's sad because you just think, "You could be so much more effective if you knew about - I don't know - test-driven development, or automatic refactoring in IntelliJ IDEA, or the latest and greatest whatever." Sometimes the inertia of moving from Java 8 to Java 11, for example, is from these developers going, "I'm fine with 8, I don't really know what features are in 11." As a developer advocate, I really want to talk to a lot of these developers but I never get to see them because they don't come to user groups, they don't read the blogs, they're not on Twitter. They just turn up and they do the nine-to-five, they're what we call the dark developers.

I think, for now, as a developer advocate, I can't necessarily reach them. For you, working in a team like that, it's very frustrating but really you're the only person who can be, "Hey, look, this thing is cool," or, "Why don't you come with me to this user group?" One way to get teams like that involved in things like user groups is trying to encourage your organization to host a user-group event on site. You don't have to take them anywhere, you just say, "Look, after work, why don't you just go into the kitchen, or the communal area, or whatever," I know, it depends on the office, "just fall in there, grab a slice of pizza, and meet the user-group people." Sometimes that can be enough to help people open their eyes up and go, "It's quite interesting actually." It's a difficult problem, it's very frustrating for you, but to be, "Look, please, just look at this thing, it's really cool. We should be doing this."

Pair programming is quite a good way to gradually introduce some stuff to those developers. I know they're not always the best people to be pair programming with, but sometimes, you want to be using a new feature in a language, or using a new testing framework, or using the key bindings in IntelliJ IDEA, whatever. When you pair with them, they'll be, "That's quite cool," and they'll take it away. That is one way.

See more presentations with transcripts