 Okay, my name is Alan Gardner, I work for a company called the Small World, we're a small private social networking site. Basically it's an invite-only kind of Facebook. We are currently hiring as well, as I've just cheekily mentioned at the start, so hit me up afterwards if you're a front-end developer who's looking for employment. What I want to talk about today is learning, basically, how to take yourself up to the next level, which kind of fits in quite nicely with Dave Hoover's talk earlier on. I thought I would lay out just now what you've actually let yourselves in for. I'm going to try and keep it fairly short because it's lunchtime next, obviously. So I'll cover a bit of background about why I'm actually doing this talk, and then I'll cover the various things that I think kind of fit into the test-driven development theory, or sort of forgotten the word, never mind. Just as a show of hands at the start, does anybody here not know what test-driven development is? Hey, excellent, that makes my talk a lot easier. I'll just say before the start, just as a kind of disclaimer, I'm not going to tell you some kind of secret magic way of learning. I can't make you stronger, faster or smarter. I am probably not qualified to give any kind of learning guru-style talk. But what I have done over the last five or six years is do a lot of learning. So I just want to pass on to you the things that I've learned while I've been learning, or rather the way that I've been learning. A lot of this is common sense, incidentally, so if you're expecting any real nuggets of wisdom, then I hope I don't disappoint. I'll start off by saying that learning is our own responsibility. It's up to us to learn. It's not up to other people to teach us. Certainly a lot of us, as we go through school, you're basically not exactly force-fed, but you're given the subjects that you have to learn. Later on in school, you do get to choose, but it's still very much a case of the teacher teaching you and you sitting there and absorbing the material. Later on in life, when you go to university, you go to college, you start work, and then you have to start learning for your work. The onus is very much on you to actually improve yourself. It's on your own personal development. So what actually is learning, and certainly what is deliberate learning? Well, I think that the key point to the whole of this is to learn deliberately. When you sit down to actually learn something, you don't want to just read a book or turn up to a talk. You actually want to figure out what it is that you want to get out of that, and that's why we turn learning deliberately. I should also mention at the start as well that there is a book by the Pragmatic Programmers, Pragmatic Thinking and Learning, which is a fantastic book if you're wanting to learn more about learning, and this is pretty much the shoulders on which this talk is standing. So why am I actually standing here just now looking rather nervous, shaking, sweating a little bit? It's because many years ago, well not that many, 2005, I decided that I wasn't actually doing what I wanted to do. My work at the time was wanting to send me to do an MBA and have me going on a kind of management style track, and I wasn't really wanting to do that. I was wanting to get into coding. So I funded myself back through university. Going back to university was kind of daunting at the start because I knew I was going to have to sit exams again, which I hadn't done for like 10 years. And I knew that just because of the fact my work at the time was allowing me to work part-time hours, there was no way that that was going to end up being the part-time hours that they'd originally said I was going to end up having to work more. So I was going to have to stay on top of all the studying that I was doing. So I kind of naively at the start just decided, well at the end of every week I'll sit down with my lecture notes, and I'll go through them, I'll read them again, I'll maybe take some notes, and that way when I come to the exams I'll have something to work on. And that did work pretty well at the start. But something I figured out completely by accident was one day, as it was eventually going to happen, my work decided that I needed to work on a day that I was supposed to go to a lecture. So I missed the lecture and I had to get the lecture notes from one of my friends. A life being the way that it is, my photocopier was actually broken at the time, so I had to hand write the notes out. It wasn't too much, six pages of minified slides. So I wrote the lecture notes out, and this was maybe about Monday or Tuesday of the week. The next day I handed the guy back the notes, and at the end of the week when I was going through my studying again, I realised that that lecture out of all the lectures I'd had that week, even though I hadn't attended it, was the one that just came straight to me like that. So I thought, that's interesting. So I figured that what I should do after that is every time I got to set lecture notes that night, I would sit down and I would hand write them out. Now, it's a bit laborious, and I have to admit that sometimes I didn't always do it. But for the lectures that I did that for, the learning really stuck. So when it comes to the exams at the end of the term, the studying just flew through. I had never done studying that easily before. And I thought, well, you know, this is kind of weird. So every semester after that I did exactly the same thing. Another thing that happened, quite by chances, my wife happened to be out of the house one day when I was studying for my exams. And I was kind of a bit bored, and I was reading through my study notes, and I started actually reading them out loud. And I find that that helped even more, that hearing the actual words that were down on the paper was also helping to keep the knowledge stuck in my head. So when you actually go to university, or at least I find this when I went to university that I went to, they split up your time into lectures, tutorials, labs, because the lectures are there to present the material to you to introduce you to the topic. The labs there to give you the practical experience to actually turn what you've learned in the lecture into something that you can work with. And the tutorial is there for answering questions, consolidating the knowledge, you know, discussing it with your class, et cetera. But there's one thing that I didn't realise the first time I was at university, because I was too busy drinking three, four, one vodka shots at the Union. But the reason that there's gaps in the timetable that you don't have lectures, labs, tutorials, the whole way through the week is that you're supposed to, you know, study the material for the rest of the week, which I actually did this time round, and coupled with the way that I was actually studying, it just made learning so much easier, and it stuck for a lot longer as well. So I had no idea why this worked, or even how it worked, or if it was a, if it was a thing or not, I just happened to know that helped me. At the conference, the Scotland on Rails two years ago, I picked up Andy's pragmatic thinking and learning book. And to read in this, I discovered that there was actually some of the things I was doing were some of the recommended ways that you learn. And I'll come back to that in a bit. But it was interesting to find that there was actually theory behind what I'd been looking at. So this is all well and good talking about learning. But I'd mentioned earlier on I was going to link this into TDD. Now, this is going to be a fairly tenuous link. So stick with me. It doesn't always work. But I like to use the analogy because I think there are some similarities between the two. I'm certainly not suggesting that when you're learning, you should write automated tests for the thing that you're learning and then run those automated tests at the end of every time you do a study session to figure out you've still got the knowledge in place. But what actually is the reasoning behind TDD, the reason that TDD works, the reasons for that are the same reasons why, if you deliberately learned that that works as well. So TDD or test driven development. Well, you may well be familiar with this, but we have, well, we start off with a failing test, something that describes the expectations you have of the piece of code that you think you're going to have to write. You then write enough codes to have that test pass, just enough code to have that test pass. You then move on to refactor your system to take into account when you code you've added, you maybe need to clean up the design, remove duplication in your code, various different things that you can do in refactoring. Check that your design actually still works or is still as you assume it to be. And then you rinse and repeat. Well, in a similar way for learning, you start off by identifying a gap in your knowledge or identifying something that you want to learn. So you basically have a failing test. This is something I do not know. You then learn that thing or you do learning. And at the end of that, hopefully you should be able to answer the questions that you have. Do that particular thing that you want to be able to do. And you then reconcile it with the knowledge that you already have. So tying in, well, this new thing I've learned, how does this actually affect all of this other stuff that I know? And how does all the other stuff that I know affect this as well? And rinse and repeat. So, well, start off by, in fact, sorry, before I go into talking about the various different stages of the TDD life cycle and how it potentially fits in with our learning. I'll just say that the reason that I think that learning ties in with this is more than just because of the fact that you can fit the different parts of learning into the red green refactor cycle. For a start, one of the things that's great about the human brain is that it's actually a great deceiver. It's a complete liar. It will convince you that you know something until you have to answer a 25-point exam question on it or stand up in front of close to 100 people and tell them about it. But in actual fact, you'll find that when you actually go to explain that, you don't know nearly as much as you thought you did. Or there's gaps in your understanding. In the same way that, or sorry, one of the things I find really helpful for me when I'm using TDD is that it allows me to stay up front what my expectations are. I can say this is what I expect this to do. And I don't know if you've had this happen to you before, but it happens to me all the time. When I'm actually writing the description of that test that I'm about to run, I quite often think, well, actually, no, that's completely wrong. That expectation, this should do this, or this assert that this does this. Well, actually, no, I don't think this should. This actually should go somewhere else. So you're testing before you even start on your learning, before you're even stepping into the actual software that you're going to write, you're already discovering things that you thought was the case that actually aren't. Another thing, and this is maybe a bit of a negative thing, but I think one of the things, or one of the arguments always gets levelled against test-driven development is the amount of time allegedly that it takes longer than non-test-driven development. And I think it comes down to the case of efficiency. Efficiency is described as the maximum productivity for the minimum effort. But people often confuse productivity as being a short term issue, rather than a long-term issue. But it's not, it's a long-term issue. If you write something very quickly, just now, and are very quickly productive immediately, but at the expense of not being so productive later on, then over the timescale you're actually not being more efficient. And in the same way with learning, although when you're learning deliberately, you're probably going to be repeating yourself quite a few times, because repetition does help learning, especially if it's different forms of repetition, if that makes any sense. But you're still maybe not learning the fastest way. You're not just picking up a book and reading it. You're going through the book, you're reading it, you're taking notes, you're doing various other different things that I'll come to in a minute. But what you do at that particular point in time, that slightly longer time you spend learning up front, will completely take out the need to go back and relearn it later on. You won't have to be constantly reaching for the reference book, because you'll have it committed to memory. So the first step, the red step, identify how do you know what you want to learn? Well, there's various different ways that you can find out what you should be learning or what you want to learn. But I'm going to talk about the motivations for learning, first of all, if that doesn't sound too touchy-feely. But I'm actually going to completely simplify it and set it into two different camps, basically learning for fun and learning for profit. Learning for fun basically means that you're interested in a particular topic, you think it's cool, you think it's a great new shiny thing, you want to play back with it, and that's fine. There's absolutely no reason to give yourself a reason other than that. That's just things that are fun to learn. You'll find things that are fun to learn very easily, especially when you're procrastinating around the thing that you should be learning for profit. They seem to come up amazingly often. But learning for profit, I would say, is not just learning because it will give you money, it's learning because it will give you something. So it might be a university degree, it might be a better job, it might be a higher wage bracket, it might be a Ferrari and a house in Italy, I don't know. But for whatever reason, learning for profit doesn't necessarily always come as easy as learning for fun. If they're one and the same, then that's even better, because you're enjoying learning it and you're going to make some sort of progress afterwards. So as I've said, learning for fun is easy. Just pick something you think is fun and go off and look at it and see how it works and play about with it. Learning for profit, however, is not always so easy. Because you need to figure out, you know, how am I going to learn something that's going to be beneficial to me in this particular job? How am I going to learn something that's going to be beneficial to me in the kind of lifestyle that I want to have? So in test driven development, we quite often write the code that we wish we had. So you'll write a mock object and I know that's contentious, so I don't want to start that argument. But if you have a mock object, then you will stub out the methods that you hope that that object will have when it actually exists. And by that, you're basically creating your interface upfront so that you don't have to worry or certainly it's a lot easier to create that object in real life afterwards. In the same way, when you're learning for profit, one of the best ways I find to do it is to write the CV that you wish you had. Now that doesn't necessarily mean writing, you know, Lord of all I survey CV. You probably want to take it in manageable steps. But by writing down what it is that you actually want to do the actual goal that you have for the learning you're going to do, you can then go and say, okay, say for instance, you're just starting out, you want to be a Rails developer, you know you're going to have to learn Rails. So you go off and look at some job sites and you see what else are they looking for. You realize you're going to have to learn Git probably as well, probably some agile methodology, HTML, CSS, all these things that you can possibly learn in. So you start adding these to your learning list. Now you don't necessarily actually have to build a writing list, sorry, a learning list, you know, I'm not talking about a big diagram on the wall, you can if it helps. But what you should definitely do is figure out the goal that you have for that learning and figure out why you have that goal. User stories, although much misused, I actually think fit in quite well here. So you could say something like as a Ruby programmer, I want to learn metaprogramming so that I have a deeper understanding and knowledge of the language and its structure or something along those lines, just something that encapsulates why you are actually learning what you want to learn. Now, as we probably all know, goals in themselves are not doable, you can't do a goal, you can't do being a Ruby programmer to a certain extent. But you can set aside tasks which will help you work towards and achieve that goal. So the tasks that I set myself out when I'm doing the various different types of learning and all the rest of what I'm doing, is I use those to kind of represent tests that you would use in test driven development system, where you're setting out the expectations at the start, you're setting out what it is that you hope to learn from that particular session that you're learning in. One of the things that I came across from reading Andy's book was actually very similar to the way that I was learning anyway, and it's a methodology called SQ3R, I don't know if anybody's familiar with SQ3R, but it's an acronym that basically stands for Survey, Question, Read, Recite and Review. Survey basically means that you take the book or the learning material that you're about to cover and you skim through it. You have a look at the chapters and the contents of the book, you take a look at the back to see what it's kind of about and what the context is, and from that you can kind of get an idea of what it is that you hope to get out of that piece of learning material. Question then has you set out questions that you want to have answered by the end of it, so you might decide that, say for instance, you're reading the book on metaprogramming, you might want to find out more about blocks, or more about the Ruby Object model, or any of those kind of questions that you think will be answered by the book. And in particular, you want to try and get to the questions that really matter to you. The ones that are the reason that you're actually learning this thing in the first place. And those questions effectively become your tests, so that when you've done your learning, at the end of that, you can sit down with your questions and say, can I actually answer these questions now? And if you can answer those questions, great, can you answer some more questions? If you can't answer those questions, go back, study the material again. Also, and this is probably a bit more unique to us as programmers, but if you can develop or figure out in your head a mini project that you can do to test this at the end of your learning, even better, because there's nothing quite like taking a real world example that you actually have to work on that's not just the sample in the book to point out the bits that you're going to have a sticking problem with. So, as I said, we'll take as example a metaprogramming Ruby, which is another pragmatic programmers book. I don't work for them. Other pragmatic programmers, sorry. Other metaprogramming Ruby books are available. And it's one that happened to be reading just now. So, doing a survey of that book would have you look through the titles, sorry, the chapters in the book and you would see things, you know, as I mentioned before, object model, blocks, code that writes code, all these kind of things. So you start writing down questions. So maybe one of the questions would be what's so special about the Ruby object model that allows you to use metaprogramming techniques? What is a block and why would I use it and when would I use it? Those kind of things. And possibly you might have a little project to try and implement as you're going along so that you're not just following the set down examples that are given to you by the book. You're actually thinking about this yourself and you're using your own problem solving techniques to actually get the answers. You can't just nip to the page at the back of the book that gives you all the code. So, now that we've identified what the problem is, we want to learn. Or basically, now we have a failing test. We want to make that pass. And this, I suppose, is kind of the crux of it. How do we learn? Well, I know that I mentioned before the process that I went through in uni of writing down my lecture notes by hand and then going through and reviewing those and writing my own notes, then reading those out loud. Well, I wouldn't expect anybody to actually hand write out the entire contents of a book. That would be completely insane and no point in doing it whatsoever. I mean, you can if you want if that floats your boat. But what you should really be doing, or rather, if you look at SQ3R, what it suggests that you should do is the 3R part of the SQR, which is reading, which is reading through the initial material, or if it's the case of a screen cast watching it through once, a podcast listening to it, a talk just sitting actually listening to the talk. But what you should not be doing at that point is taking notes or engaging yourself in any of the actual practical examples. Just watch it through and absorb it. Let it settle into your head. Next, the recite part is go through it again. Read that chapter again. Skin the chapter and take notes. Watch the screen cast through again and take notes. Listen to the podcast. Watch the video of the talk, wherever it is. Go through it again and the second time actually take the notes that you would have taken the first time because it allows you to absorb the material in the first place and get the context. And in the second time when you go through, you can delve into the nitty-gritty. After you've gone through the recite part, you go to the review part. And the review part is where you take the notes that you've taken and you review those. You read them to yourself. You go and discuss them with a discussion group. You go on to a forum. You go and talk to your local user group. Various different things. But the purpose of that is to actually have you explain what you've just learned to other people or try and explain it to yourself. So you'll point out those gaps in your knowledge that you have. And you'll also come to a greater understanding of the material itself as well. There's a quote from or a famous medical quote anyway which is see one, do one, teach one. Which my colleague Bruce Handley pointed out to me the other week which basically extols the fact that you see a particular operation being done. You then do one yourself to give it a go and then you teach it to somebody else because there's nothing quite like teaching something to somebody else to actually cement your own understanding of it. So, oh yeah, sorry. Another thing that I learned from Andy's book and this again was something that I just stumbled upon by accident was the using multiple senses when you're learning. If you use more than one sense when you're learning something it's more likely the brain will treat that knowledge with a higher priority. So if you just read the book then it will have less of an impact on you than if you read the book and it's out of light to yourself. Bizarrely enough, and you'll find out why in the book but handwriting something is completely different to typing something out in a computer. It uses different mechanisms within the brain and it basically lets that knowledge stick with you longer. But it doesn't just have to be handwriting out notes. It could be things like even just chumming your fingers on the desk as you're actually watching a lecture. Something simple like that. Not necessarily something you want to do if you're sitting next to somebody else because it might irritate them. But just swinging your leg. Anything that involves other senses while you're learning promotes that particular piece of information so it will stick. It's a weird human fact that it is the way that it is. So another thing that's very important and this is something that's actually coming into a bit more prominence now but take regular breaks when you're learning. Don't sit down for a 12 hour marathon session to try and finish a book in a day or something along those lines because it's a lot of diminishing returns. It's the tired of you get the less you learn and the less you actually get out of that time so you're not actually efficiently learning anymore. You're just basically trying to cram stuff in your head. That's why cramming before an exam doesn't really work or it works to a limited effect anyway. It's important to let the information that you've taken and settle. It's important to let what you've been learning settle in your head. And there's very good reasons for this. One of the things that Andy talks about in the Pneumatic Thinking and Learning book is the fact that there are two modes of operation in the brain. There's left mode, which deals with logic and linguistics and there's, sorry, I say left mode, it's actually not left mode at all, it's linear mode. And R mode, which confusingly is not right mode, it's not right brain, it's actually rich mode and what that basically deals with is your creative side but more importantly, it's a very, very good pattern matching piece of wetware, I guess is the term that he uses but it basically is Google for your brain. It allows it to go and search every single memory that you've ever had asynchronously and pull back some pattern matching results that you've never seen before. Or sorry, now you have seen before but you weren't aware that you had the information for. So the reason that taking a break is actually very helpful when you're learning is that it turns off linear mode because the two things can't work at the same time, you're either thinking about something actively and you're doing a linear mode task such as problem solving or in fact writing on your computer is something that happens in linear mode. So if you are carrying out these tasks in linear mode, you're not using rich mode and rich mode is actually very helpful because it will take something that you're learning just now and it will pattern match it to something that you wouldn't have thought of necessarily by actually thinking about it. So it's the reason why if you go to bed thinking about a problem, you'll quite often wake up in the morning with a solution because our mode's been sitting working all overnight. So make sure that you take breaks between your periods of learning, not just so that you don't tie yourself out but also so that you can get more out of the actual learning experience itself. Another thing that you can do and this is to do I guess with the review cycle is go along to a local user group because, and I don't say that just as an organizer of a local user group come and see me afterwards if you want to talk up on Aberdeen. But if you actually go to one of the user groups and you talk about something, you'll very quickly be told whether you're right or wrong. In fact, most cases you'll be wrong and it'll be interesting to find out why you're wrong and to find out what other people's thoughts are about it. And also the fact that you've actually had to sit and prepare a talk upfront as well will cement your understanding a bit more as I mentioned earlier. So now that you've come to the end of actually doing the learning that you want to do, you've gone through the chapter or you've watched the screencast, are you now able to answer those questions that you had? Has it actually brought up more questions? So do you now have passing tests as I guess what I'm trying to say? Can you implement that app or implement a feature in that app that you were thinking about based on the knowledge that you've just learned? Does it make you think differently about that particular task that you did when you started? The next part is refactor or reconcile as we're talking about from a learning point of view. The purpose of refactoring is partly to tidy up your code, partly to make sure that what you've just written, you take the duplication out of it, you make sure it's all cleaned up. But another part of it is also to make sure that you look at that very small bit of code that you're working on and take it back into the big picture of your app. Have you actually implemented what you meant to implement? Does it affect the design of your app? Where does it take you to next? Where does it take you on? So what tests should you be writing next? And it's kind of similar with learning because once you've learned something, you then want to put it into context with what you already knew. You want to make sure that if you have been reading the rest of the metaprogramming book, does this new chapter actually shed a bit more light on something that you were sticking on earlier? Does it even make you think, oh, hang on a minute, actually I've just realized that something that I wrote two months ago actually could be vastly improved by using this new technique that I've just learned. Or maybe not even that, it's just the case of actually learning this particular thing has made me think more about this other completely unrelated thing because it's triggered something in my brain. Again, that's our move. So I like to split the recon style phase into three different parts. The past, the present and the future. The past being, how does this affect what I already know, which I've just covered. The present being to add what you've just learned or to add the fundamental parts that you've learned out of that particular thing you've just learned. Add it into your daily or weekly learning. If you do catas, those kind of things, add it into your catas, does it help? Is there something else that you can maybe do there to cement your understanding? The other thing as well that I should probably mention is that not all things that you learn have to be at your fingertips. It is all right to go and read a reference book. You don't have to become a walking encyclopedia but you should learn the things that you need to know straight away or that you use often. And the very fact that you use them often will cement them in your understanding anyway. But try and identify ways in which you can turn that learning into experience. And the main reason that you want to do that is because learning as a shelf life or knowledge as a shelf life, it will stick around in the useful parts of your brain for a relatively short space of time before it will disappear and then you'll have to go and learn it again. The more time you spend learning up front, the less time it will actually take you to pick that knowledge back up again. But you have to figure out what's actually worth sticking around or having sticking around. And what can I look up in a reference book because I only use it once or twice. If there's something that you think will actually be useful but you don't tend to use it on a daily basis in your job then add it into a cata or add it into some form of monthly review or something that you can just kind of refresh yourself. Oh yeah, I remember that now. And it will keep that knowledge around and keep it useful for you. Effectively, what that is doing or the experience you're getting from that is developing the equivalent of intellectual muscle memory. So just in the same way as you can teach yourself to play something on the piano and you will just know how to play it because the muscle memory in your fingers just picks it up in the same way if you learn something and it's going to be useful to you, keep it around so that it basically will become part of your repertoire for one of a better word. It's something that you will be able to pick up quite easily or to recall quite easily. So the other part or the final part of the reconciliation is to look at the future. What does what you've learned just now or so where does what you've learned just now take you next? I mean, it might be as obvious as the next chapter in the book or the next screen cast in the series or something along those lines but has this actually opened your mind now to something else? Is there something else that you want to learn? Is there something else that you figured out? Actually, I don't know that and I probably should. So it figures, it helps you, helps to take you on to what you should learn next. Okay, so just to conclude. Nice and early. What I've been talking about just now is you want to learn deliberately. So don't waste your time by learning something that you don't necessarily or sorry, are not necessarily going to get a lot out of. Make sure that you know why you want to learn what you're going to learn before you go into it. Now I'm not saying that it has to be a boring chore of sitting down and actually writing out all the questions or drawing up a chart to see what it is that you want to learn but just find a way to make the thing that you're going to spend time on useful to you because if you're just basically going to read through a book and it's just going to be something that you basically consume and you don't actually get anything out of it, then is that actually going to be worth it for you? Are you spending that time wisely? Identify what you want to learn. So as I was saying before, you can do techniques like writing up a CV that you wish you had or just taking a look around the job ads to figure out what everybody else is learning or even just something fun that you want to try and do yourself as well. I set the expectations up front and say exactly what it is that you expect to learn from this. I expect to learn this, I expect to learn that, I expect you'll answer this question, I expect you'll do this type of app. And then you go through the learning process of absorbing the material, reciting it, so taking your notes, et cetera and then reviewing it. Practice, practice, practice. It's an often heard cliche, but it's absolutely true. If you do not practice something, then it will disappear because as a shelf life, again, it's why cramming for exams doesn't work because you chuck it all into your head in the space of two days and then you go out on an absolute bender after the exam and you forget all about it by Monday. So by practicing these things time and time again, it ends up becoming muscle memory. The, yeah, sorry. Make sure that you take regular breaks and again, starting to sound like your mother, but taking regular breaks does help cement the knowledge that you've got. Not only does it rest your brain between sessions, but it also, as I said, fires up R mode, which will allow you to start pattern matching what you've learned to some things that might even be completely unrelated to what you're talking about. A handy thing to do for that incidentally, walking the dog, going for a shower, doing the dishes, apparently. And then reconcile what you've learned with what you already know. So I think that's probably it. It's time for me to show you a picture of my daughter and ask her some questions. Hello. Okay, so the question is, how many topics should you be studying at the same time? How many different things? Well, it's, again, it depends. It depends on what type of person you are. It depends how you learn, but I would tend to find limiting the number of topics, especially the number of disparate topics, will help you in your learning. It's not necessarily the case. I've found myself sometimes reading three books at a time. Don't know how much I've necessarily gotten out of all of them, but yeah. I think it's an important part. It's something that I didn't mention here actually, boredom is probably the biggest enemy of learning. If you're bored when you're learning, you switch off, you don't learn. You're not actually taking it in because you're thinking about something else, you're wishing you were doing something else. So try and keep it as interesting as possible. So from that point of view, yes, if something keeps your interest and you want to actually start learning it, then maybe you should go and learn it. Take a break from that particular thing. One of the good things about the R-mode operation of the brain is that you might actually find that there's a tenuous link between the two, just like there's a sort of tenuous link between learning and TDD. Any other questions? Early lunch.