These transcripts were captured live by a captioner. As such, there may be small errors. If you spot any, please feel free to submit a pull request with amendments.

Hello, everyone. So, thank you Keziyah for that great talk. I thought that was wonderful. I don't know about you, but, when I was at school, I studied a whole bunch of different things like maths, geography, what have you. But I never was taught the skill of learning. I was expected maybe to kind of already know it, or pick it up as I was going along.

And this talk "Learning to invest in your future" is about the why and how of focusing on learning as a specific skill independent of the things in technology and software, or other things that you want to learn.

So, it's true. I am a maths graduate. Actually, I'm old enough that there wasn't a department of computer science when I was at university. I'm also old enough to have an eight-year-old son, and, when I was talking to him about this talk this week, he said he's really looking forward to when he grows up and can finish school, because then he won't have to learn anything ever again! [Laughter].

I did not break the news to him, but that's not how it's going to turn out! So, here we are, five per cent already through 2020. As at the beginning of efficient year, it's a great opportunity to look forward and think about what you're going to achieve that year, and, like every year in my career so far, I'm excited by it, but also intimidated, because I know full well that I'm going to spend a lot of this year doing things that I don't really know how to do very well. I'm going to be doing things that I've never done before, and it is genuinely exciting be with but also intimidating.

So, I we would like to tell the story of some people who set out to do something very difficult that had never been done before, starting 58 years ago. This chap, John F Kennedy was President of the United States, and here he is announcing there will be a manned mission to the moon, taking a human to the surface of the moon, and bringing them back safely. And it is kind of interesting to - I heard a great story recently about how he came to decide to do that. The fact is that, at the time, the USSR was winning the space race. They had put artificial satellite in space - Sputnik - and put a dog in space, because that's a thing, and they put a person in space and brought them back alive, Yuri Gagarin, and did that before the US had.

One of the senior figures in NASA at that time had been Wernher von Braun. He said the moon missions should be done because it was so ambitious that it would lay the level the playing field. There was so much of an advancement that needed to be done, that neither country had an advantage. So, JFK publicly announced by the end of the decade they would have achieved this. He set a monumental engineering challenge, but also a huge learning challenge. These people were going to be building new things - enormous new things, and huge quantities of new things.

They were going to be using new tools, and the new tools, some of the things that they used as their new tools were the things head to build. And they were going to be working in new environments, and I choose to believe that this is not a Hollywood back lot, this is the environment of the moon. A lot of things have never been tested in that environment. Well, nothing had been tested in that environment, but even in space, things were rather new. It's interesting to think about who NASA chose to achieve this.

This is the Apollo 11 mission control room, the famous photograph with one female person right in the centre, and Jerry Griffin is one of the flight directors of this mission, and he said in an interview, the average age of people in this room is 27 years old. They hired people straight from college based on written applications, no interviews, and put them straight to work, and then they found a place where they could work effectively. A quote from Gerry Griffin: "This task had never been done, but they weren't afraid of it. It was a lack of fear. It wasn't a lack of knowing that it was risky, but they just weren't afraid of it. They didn't have any problem of washing away old experiences that didn't apply any more."

One particular person who I would like to bring to your attention is this fellow, his name is Steve Bales, the guidance officer. His responsibility is understanding and interpreting the output of the computer that is in the lunar module as it is descending to the surface of the moon. And, he, if you've ever seen a movie about the moon landing, that the infamous 1202 computer error, they all had numeric codes, and it is up to this guy, Steve Bales to work out what that means and whether they need to abort the mission. He didn't know the answer. He had a deputy, Jack Garman who did know the answer. Steve Bales is 26 at this time, Jack Garman 23. Between them, in 15 seconds, they came to the conclusion that the 1202 error was probably all right as long as it didn't happen too often! Which is yes, a debugging technique I still use! [Laughter]. 58 years on! It's worked well!

So, building new things, new tools in new environments, is exactly the daily reality for people who work in software. There's no escaping it. That's like the biggest example I could think of doing that, but for anyone who works with software, this is what happens, what you do every day. The pace of change in software is ludicrous. We're building new things. Every problem is at least subtly different. If it wasn't, we would use the thing that solved the pre-exist ing problem.

We're using new tools, languages, frameworks, libraries, editors, shells, operating systems, et cetera. You can't know them all. So, at some point, you're going to have to be picking up new ones. We work in new environments. AWS this year is going to be 14 years old. And they've been releasing new services at a rate of more than one a month on average since 2006.

I don't believe there's a person on Earth who knows all of them, and even if AWS - and that's only one platform. You're always - whenever you push your code somewhere, it's going to be using some platform feature or some framework feature that's new to you. So, we're constantly, constantly learning as we go. How do we learn? How do we learn anything - not just software.

Talking about playing a musical instrument, or learning to swim well, or something like that? Any kind of skill you want to learn is learned through practice. Doing a thing over and over until you're good at it. Doing a thing over and over until you're good at it. There's no escaping the fact that if that is what practice is, then at least at the start, you're doing the thing over and over without being good at it. There's going to be mistakes. There's going to be missteps. Things aren't always going to work out correctly as you want them first time. It's tempting to think of those things as failures, but, if you keep learning as an explicit goal in your mind, they're not failures but great successes.

So the thing that you need to do in order to learn effectively, accept these mistakes, find or create a safe space where mistakes are okay, where things don't have to work first time. If all you ever do is write code that is pushed straight to production, then that might be very exciting, but it's not a great learning environment. Once you found or created your safe space, and you've sort of pre-forgiven yourself for not being perfect, you can even start enjoy mistakes and relish them. Here's a still from a video from SpaceX. They're learning how to land rockets on a boat in the middle of the ocean. And they put these videos out of all the things that have gone wrong, and they celebrate it. I think that's a wonderfully kind of healthy attitude, because if they already knew how to do it, and they were confident it was going to work and then this happened, it would be not so great a result, but they explicitly are setting out with the goal of learning.

So, talking about stepping outside of your comfort zone, there's a quote, "If you never push yourself beyond your comfort zone, you will never improve." That quote comes from a person whose office organisation skills I greatly admire. His name is Anders Ericsson, and he is an educational psychologist. In the 1980s, he studied the differences in how people practise between high achievers in lots of fields - academics, music - and he found others don't perform so highly. Also, the type of things that people who are high achievers do when they're practising is qualitatively different from just doing the same thing over and over and hoping to get better at it.

I think it might be known rather well nowadays, but he coined this phrase, "Deliberate practice". It describes the process of deconstructing a skill to the point where the individual elements can be practised in isolation. Let's say, for example, I want to sell socks online. I'm going to build a website to do it. I might need to deconstruct that. I might need to learn front-end, server-side, and datastore technology. I might need to know about query planning, HTTP caching, CSS specificity rules. This season of these things can be practised in isolation. When I come to put them together it's going to be that much better and performant, cheaper to run and make me more money selling socks.

I talk right now about how learning to do something, or skills acquisition, as it is sometimes called, is treated and modelled. There are several models of how people acquire new skills. This is one I particularly like, but there's a slide at the end with a link to references with a bunch more. In the case of me learning React, when I remember that React exists and it's a thing that can help me build web pages, then I start to understand it by copying and pasting code following tutorials, and then I can get to apply that knowledge by using React in my own new websites.

After that, there comes a phase of analysis where I start to understand more about how React works and what its limitations are, and I begin to be able to evaluate it, know where it is strong and weak and how it compares to other things in the same space, and, then eventually, if I'm so motivated, I can move to creating, or extending core React or using it in new ways that haven't been thought of before.

All this is - if you think about a skill that you've acquired recently, something you've learned to do, you might recognise some of these phases, but they're blurry. It's not like you suddenly flick between them. I bring this up to point out you probably need to be somewhere in this region before you can apply deliberate practice because you need to be able to decompose the thing into individual components. And this kind of means that at least at the beginning, you're going to be putting in work without really feeling like you're learning, and that can be very damaging to your motivation. If you understand why it is happening, then, hopefully, you can push through.

Once you get to the analyse phase, everything accelerates. You start to be able to ask and answer your own questions. Learning because deeper, motivation becomes much more intrinsic. But you do have to accept that it will take some time before you feel like you're learning when you pick up something new. And it's hard work. Oh, sorry. It's hard work. Maintain focus, keeping in mind the thing that you've isolated when you have other things to do, and it is cognitively difficult. Taking breaks is totally recommended in this situation.

When you study something for two hours and then go for a walk, your brain is still processing, and, when you're sleeping, you learn things. You wake up better than when you went to bed. They had a great phrase which I've already spoiled for you in the MIT AI lab in the 1960s where they studied learning in relation to computer programming. They had this idea that, as computers became more and more come pleased, they would approach the complexity of the human brain, and teaching someone a skill and programming a computer would become basically the same thing.

I'm not so sure that's worked out, but they had this phrase, "It's hard fun" rather than hard work, because you get to the end. I don't know if you've ever run a half marathon or something like that, and every step is a bit of a chore? You say right, I'm signing up for another one. Because it's really fun. It wasn't fun whilst you were doing it. That's what they mean by hard fun. I would like to talk about specific techniques that I've used effectively that other people have told me they've used effectively and you can read about for effective use of the time that you can find in your safe space to learn.

I left it downstairs, but there's a book called Apprenticeship Patterns? It's one of the best books on career development I've ever read. They say feedback loops are the fundamental way to improve your learning experience. Feedback loops: you have a question, you get an answer, like, "Does this work?" I will try it. You get an error message if it doesn't work. Automate the boring stuff to make those as quick as possible.

There's a few reasons why fast feedback loops are especially important. Firstly, you can just do more things, you can try more things. Secondly, and this is often mentioned in the context of test-driven development where you want quick-running tests, if you don't have a fast feedback loop, you will get bored, they say. I find that insulting that if my test takes more than 30 seconds, I will go to the coffee machine and play pool, and stuff. But it can make it more exciting if things are quicker, for sure.

There's a deeper reason as well. Psychologist and Fortran programmer called Daniel Kahneman who won the Nobel Prize in Economics, and he studied intuition which in this sense is accurately making technical decisions without analysing every step of the process. He found like firefighters were his famous example, deciding when to leave a burning building. They don't do a lot of analysis, they just feel it.

He said that intuition is a thing that can enable you to make quick and accurate decisions under certain circumstances. You need a predictable environment - so there is no intuition about lottery numbers - you need practice - the more the better, and you need feedback, the quicker the better. So, when you hear someone who is able to very quickly make an accurate assessment of some new technology or some new technique, it's likely that they are using an intuitive way of making that decision, and it's important that they should be able to step back and provide analytical reason if you ask them to, but this quick decision-making is enabled by fast feedback loops.

Secondly, I would recommend you to find and focus on your fundamentals. I'm sure you've already found, and will continue to find, that there certain skills, knowledge, technologies, that come up again and again when you're coding on different things. It's somewhat the opposite of chasing the shiny new things. For me, I think the fundamental things that have been very helpful to me are understanding the model of the web, clients and servers, requests and responses. Knowing about the JVM in Java, and Clojure, and knowing about Linux, bash scripting, and a little bit about the kernel.

It took me a long time to recognise those are things, if practised in isolation, could bring benefits broadly across lots of projects. I think you should be aware of tools and frameworks that tell you don't need to know the basics. Like here's a new client server tool kit which abstracts http and you don't need to know it. That's a lie, because as soon as it works like you don't expect, then you will need to know, and you've taken a short cut, which now you have to backtrack, is going to cost you more time in the long run.

The Pragmatic Programmer calls these "evil wizards" which is a great phrase. I talk about something now we are all doing here today: social learning can be fun. It really can. Finding people to share your learning journey with. Not everyone enjoys the same things. You can't force someone to be your social-learning buddy.

People learn in different ways, but if you talk about your learning and what you're interested in, people, and people you will - you will find people who are interested in going with you. Accountability partners. Books, study groups at work, at uni, or your friends are great, and, if you can't think of what a good book to start with, I would recommend a series of books Seven Things in Seven Weeks. You spend seven weeks in a row, each one on a different programming language. You bootstrap to the comparison stage of learning, and you see so many of them in comparison to each other. Book-study groups at work, I've got a lot out of those.

It's great because you also get to know your colleagues better, you get to know - well, you get - if you choose a nice book, like the Seven Languages one, everyone is a beginner in some bit of it, so it levels the playing field of some being experts and wanting to dominate the conversation. Group working, pairing, especially with people you don't often pair with on learning projects, is a really, really great way as well.

About today, there are conferences. Thank you for coming to this one. People come to a conference, and they pay a lot of attention to who is speaking and what they're speaking about, and it's true: Kevin and the team have put together a great programme together for you, but there are 250 other people here who you can learn from as well as us.

It's referred to as the "hallway track" where people you bump into downstairs. Like me, you may be rather nervous of striking up new conversations with strangers, and I can give you an ice breaker that someone gave to me which is, "What's an interesting thing that you've learned recently?" You can have that for free! Please use it. I like it, because if someone asks me that, I'm - I don't have to talk about myself, so the kind of shyness aspect of my personality is - doesn't sort of stop me from talking, because, "I learned about a particular type of pigeon, or how a browser works."

Meet-ups: people think meet-ups are like mini conferences, but there are a couple of big differences. You can meet the same people over and over, and you might find learning buddies there. But I run a couple of meet-ups in Bristol for the last few years, and I will tell you now if anyone wants to come to Bristol and speak at a meet-up, I will be in your debt, you'll be my hero and best friend straightaway, because the challenge of getting new speakers to meet-ups is constant.

So, if you're interested in learning something, why not offer to present about it at a meet-up? The organisers will thank you a lot. And, Douglas Adams in one of his Gently books, there's a section where talking about education, he says, "If you really want to understand something, the best way is to try and explain it is to to someone else. That forces you to sort it out in your own mind." This is a selfish and un selfish way of learning. It's unselfish because you're sharing knowledge, bringing people up with you, but it's kind of selfish because you're putting yourself on the line and you have to learn something yourself, and you'll become the expert in the room on this thing whether you want to or not. It's also fun.

Whilst on the topic of conferences and the hallway track, I wonder how many people know about the thing called the Pac-Man rule? A small handful. I will introduce it. On the left - we can practise it later - is a group of six people chatting in a closed circle, and the poor yellow person can't get into the conversation. They're very sad about it. On the right, the six people, they have remembered for the Pac-Man rule to step back and leave a space for new people to join the conversation. What have you been learning about recently? So, if you get a chance to practise that later, it would be great to see more and more people talking. Some more learning.

Keep a learning diary. I'm not sure if you can read it from there. That's my learning diary on top of my what I did each day diary. They're separate things. It's an old one from when I worked at Oracle, and I hope there's no secrets there! Probably fine. It's easy to forget how far you've come. I read my learning diaries going back several years, and like, crikey, I remember, there was a time when I didn't know that, and it's part of something I do every day without thinking about it. It's very easy.

Everything you learn is your new status quo straightaway. But also, reviewing your learning diary in 20 minutes or so, you can read through a year's worth of learning and you'll create connections between things that were not obvious at the time, and it's a way that you can find your fundamentals, and identify those things that are really like critical to your experiences, and like a slow form of feedback loop. Everyone reference differently. This is a well-established thing. Some people like reading. Some listening. I struggle really hard learning things from videos. I'm a reader. Podcasts I find it difficult to focus on. But everybody's different. There's nothing wrong with any particular style. Identify your style, and make time.

Whilst you're having your breakfast, listen to a podcast, or while waiting for your colleagues to arrive in the morning, read a blog. It's a great thing to make a habit of. It doesn't have to take a lot of time. It builds up and up over time. You end up with a very broad set of knowledge. So, in summary: create your safe space, and embrace missteps. Think about deliberate practice. Think about practising things in isolation. Create fast feedback loops.

I mention I'm a Java programmer. Java projects can be a pain in the arse to set up, can take ten minutes to get a "Hello, World" working. I keep a pre-canned "Hello, World" project in IDE minimised, and, when I have something I want to try, I can unminimise it, try the thing, does it work or not? Delete the code back to "Hello, World", and it's out the way. Get used to the JavaScript console in the browser. Learn keyboard short cuts for your favourite editor. Just get used to being able to do things quickly and get feedback quickly on your thoughts. Find your fundamentals, as I mentioned. Socialising your learning. It's super, super powerful.

Keep yourself a "Today I learned" diary, and find your learning style and engage in it. We still have, like I showed at the beginning, 95 per cent of 2020 left. I don't think it's too late for a New Year's Resolution. Try setting some learning goals for 2020, and be explicit about the fact that they are for learning and not for any particular technology.

So, you have got this. You've got this. Thank you very much for listening. And here's where you can go to find out more about what I said. Thank you. [Applause].