This is a repeat episode of Ruby Rogues. Here's the original link https://devchat.tv/ruby-rogues/131-rr-how-to-learn/

Sponsors

 

Remember, if anything goes wrong, one hand washes the other. Nobody saw nothing.

Hey everybody and welcome to episode 131 of the Ruby Rogues podcast. This week on our panel, we have James Edward Gray.

He gave you what you what you want. Why aren’t you at your post?

Katrina Owen.

Hi.

David Brady.

131 episodes and they still haven’t figured out how to shut me up.

Avdi Grimm.

Good Morning.

I’m Charles Max Wood from DevChat.TV. And this week, it’s just us.

Yay!

Yay!

How different is that?

Best guest ever. No, wait. [Chuckles]

We love our guests, but sometimes it’s fun to just chitchat amongst ourselves.

Yup. So this week, we’re going to be talking about how to learn. And I know we’ve done things related to this in the past, but we’ve only had 130 episodes. So I think we can bear to repeat a couple of things.

Oh, we’ve got tons of new material.

Yeah, there we go.

So this is Katrina’s idea. Katrina, why don’t you tell us what made you want to do this one.

There’s a post on Parley about how to read programming books and it veered into a lot of other topics around learning. And it’s something that’s near and dear to my heart because I started programming really, really late. And for the longest time, I didn’t actually want to talk about that out loud because it seemed like the only way to really become a good programmer is to start before you can walk. And then you learn to read best by actually reading programming manuals in order to learn how to read. And then you’re exposed to computers probably before you can walk as well. And then by the time you’re old enough to go to high school, you’ll actually be in college because you’re smarter than everyone and et cetera, et cetera, et cetera. Long story.

It’s actually preferable if your mom can swallow a graphing calculator so you can get started in the womb.

Preferable. Absolutely. So, it’s something that I’ve thought a lot about. And then I did a talk about how to, I guess how my misconception about talent shaped a lot of my attempts to learn early on. And so, the talk was a lot more about this myth about talent and then how to become better at things, how to practice and how to develop skill.

So I think this is the perfect place to start. And especially because I don’t think you and I totally agree on this. We’ve had some cool discussions about it. So tell us about the talent myth KATRINA:

I’m trying to figure out where to start. I grew up thinking that you’re born with a talent and your job is to find out what that talent is. And so because I didn’t know my talent, my job was to figure it out, and I would try a bunch of things. And every time I tried something new, I sucked at it and so it was obvious that that was not my talent. And I kept doing this. And I really wanted to be awesome at something and I just wasn’t. And then time goes on. I’m 25 years old. I don’t have a talent. I’m not good at anything. I also don’t have a degree in anything. And I don’t have any interesting work. I can’t get a real job because at this point, I don’t have any proper skills. And so this idea that you’re born with some innate talent to me was very harmful. And I finally decided to just go learn something useful, even if I couldn’t get very good at it, just so I could get a reasonable job, and decided that science would be a good choice. And then because I knew I wasn’t good at it, I

started working really hard. And it turns out working really hard is really good for learning something.

Yes.

[Chuckles] Yeah.

It’s like the cure, right?

It’s the cure.

It is the cure. And so, I realized that there are very specific techniques to developing skill. And you can use them very deliberately to become good at something. And I assumed that that’s good for any value of good, including great. And so I’ve read a lot of the research by Ericsson about greatness, about developing greatness, about the incredible hard work that people do to become great at whatever it is they do, be it music or sports or financial trading or whatever.

Yeah.

This is Katrina’s superhero origin story.

[Chuckles] That’s right.

She doesn’t even know it. [Chuckles]

Yeah, actually when you said it that time, I think we don’t disagree as much as I thought we did.

But this comes out a lot in modern parenting books. If you read modern parenting books, they’ll always harp on praising effort, not ability.

Yeah.

And so the idea there is if your kid comes home and they got a good grade on a test, our natural inclination seems to be to say something like, “Wow, good job. You’re really smart.” But that’s harmful because it implies that they just had this natural thing, that they’re smart. And then what if they go in and get a bad grade on a test for whatever reason? Maybe they’re just [inaudible] that day or whatever. So now what? They’re dumb? Or whatever. And there’s no path forward or backward. Whereas modern parenting books encourage you to praise effort. So they come home, they have a good grade on a test and you say something like, “Wow, good job. It’s clear you put a lot of effort into that,” or something like that. And then if you later get a bad grade on a test, then you have a path forward. “Oh well, I didn’t try hard enough at this thing and I could throw more effort into it,” or whatever. And we could get into, obviously there’s a lot of debate about even praising children as well. But let’s not get into all of that. But the idea is that yeah, the idea of this natural innate thing, if it’s natural and innate, it means you don’t have any control over it. You shouldn’t right? So if it fails you and leaves you high and dry, then what?

Yeah. There’s a dangerous undercurrent there as well, which is that you teach kids to value being smart. And that means that they will seek out confirmation of that behavior. And in the original study that they did that found out this behavior, they went back to these kids that they had told were smart and they gave them the option to do an easy puzzle or a hard puzzle and they all chose the easy puzzle because they wanted to get an A and look smart. And the kids that they told that they taught to value effort, they all chose the hard puzzle. And they got worse grades and they didn’t care, because they had done the harder puzzle. And they did a longitudinal study. They came back to these kids two or three years later, and the effort kids were all much smarter than the smart kids because they were constantly putting in effort and they were doing their homework. They were doing the effort. And as a result, by the time they were in middle school, they were all in advanced placement programs. They were all, well I don’t know if all of them were, but statistically they were several points up the scale than the kids that were praised just for the outcome. And yeah, if you praise effort over the outcome, then the kids, and I say kids but I was a special kid. I got told I was smart. I got told I was special. And so now, I’m 42 years old and I’m trying to figure out how to unwire this value system in my head and wire it to effort because I see how valuable it is. And the problem with valuing the outcome is you start looking for shortcuts to get there, to get to the outcome. And yeah, it’s like the opposite of talent. You end up hoping you’re just going to walk on the field and be great. And if you’re not great, you have no tools in your belt to deal with it.

So one of the things I find really interesting about this idea of effort is that the place where you learn is the place where you’re reaching, you’re stretching. And if you stay in your comfort zone, you don’t learn because you’re not stretching. So there’s this idea of a sweet spot or a discomfort zone that’s just beyond the reach of what you know, what you are capable of right now. And it’s not too far out of your zone. It’s not in your panic zone. Because in your panic zone, you just shut down and you don’t learn anything because you’re panicked. And there’s a lot research about the physiology of panic and how that gets in the way of learning. But learning to identify the sweet spot, or this discomfort zone, is really interesting because it’s really hard. It takes a lot of effort to stay there. And it’s exhausting. And it’s also worth it.

Wow.

It’s difficult to pick something like you want something just one or two levels about your current level, not ten levels above your current level, right?

Exactly, yeah.

It’s hard to find the thing that’s the right amount that it stretches you but not that it breaks you.

So have you guys heard about the NOPS trick? It’s a hack for staying in your discomfort zone.

No.

Oh, okay cool. So this is something from one of my picks that I’m going to pick at the end of the show, is a thing called PhotoReading but it’s a brain hack that I learned. And it’s an acronym. It’s NOPS, N-O-P-S. And basically, anytime you’re stuck or you’re flailing or you’re aware of discomfort while you’re practicing or while you’re trying to get better at something, while you’re trying to learn something, NOPS is the acronym. And it stands for Notice it, so just be aware that it’s happening. Own it and basically say, “Okay, yes. This is happening to me. I’m not going to deny that I’m uncomfortable. I’m not going to deny that I’m out of my comfort zone. I’m just going to own the fact that yup, I’m out of my comfort zone,” which goes a long way towards alleviating anxiety which you need to get unstuck in this place. The P in NOPS is really interesting. Push into it. And so what this actually means is yeah, if you can’t wrap your head around recursion, sit down and just write the stupid, simplest recursion program and write it over and over and over. Actually, the Push into it is actually push into the specific discomfort so if there’s something about it that you can identify that makes you uncomfortable, go there. Try to make yourself more uncomfortable is basically what push into it does. So if you’re in a social situation and you’re doing anxiety about talking to people, Notice it, Own it, Push into it means walk up to someone and start talking to them just to see how it makes you feel. And then the S is just Stay with it. So it’s Notice it, Own it, Push into it, Stay with it. And so yeah, you push into this discomfort. You increase the discomfort. And you try to stay with that discomfort. And what happens is you stay with it and your anxiety levels off. And then you back up a step eventually and you go back to the original problem and suddenly you’re like, “That’s easy.” Because what you’ve just done is you have just consciously and deliberately stretched your discomfort zone and you dragged the boundaries of your comfort zone. And you now come back to maybe this recursion problem or this other smaller social situation and you still might not know how to do it, but you’ve dragged your comfort zone out to where, “Now I can work on it endlessly because it’s now inside. I now approach it with curiosity and fascination instead of worry and anxiety.”

Yeah, that’s a good point. So we don’t believe in talent, per se, “magic talent”.

Can I chime in on that a little bit?

Yeah, yeah.

I don’t want to completely discount talent.

Yeah.

I think there is some aptitude that people have for certain things. And I think it drives them to certain things.

Please give examples, because I’m having trouble. I don’t know what you mean by talent specifically.

So for example, I’m just going to use sports as an example. So I have a nephew. He’s three now. But when he was a year old, he was running around. He was throwing a ball overhand. He could climb anything. And other kids just don’t really have that natural aptitude. Some of my kids, they were talking like crazy at that age, but they weren’t running around and throwing balls and doing those kinds of things. So I think we all have some natural aptitude to certain things. It’s dangerous to talk about those sometimes, because I don’t feel like at the same time, how can I put this? I think effort in many cases can trump this. So you may not have the natural aptitude for it, but if you put in the time to do it, then you become good at it. The example that comes to mind with this is if you real Malcolm Gladwell’s Outliers, he talks about how all of these people that get into these conservatories and things like this, he’s like, “Yeah, there may be some natural talent there, but they put in their 10,000 hours.” And he puts that up there as the magical number for effort. So yeah, they may have a natural aptitude. It may have led them to pursue the skills in that particular area, but they got into the program based on the effort that they put in to become good at what they were doing.

Yeah.

Let me throw one more log on that fire. I have a small child and she has a playgroup and I see lots of little children. And I look at them and I think, I don’t know if this is correct, but I think that I look at them and I go, “Oh, that one’s really graceful,” or, “That one’s really not.”

Mmhmm.

You know what I mean? And I wonder, is that an innate thing or not? What are your thoughts on that, Katrina?

I’m sure that there’s something innate. The thing that I question is whether it’s relevant when it comes to becoming great at something. I believe that grit and effort have a lot more to do with it. Now that said, I can’t jump very high. I’m not going to be a baseball player or a basketball player, whoever it is that jumps high. I’m not very good at sports. [Chuckles]

Hockey.

[Chuckles] Right.

Hockey

[Chuckles].

And I don’t care. So I’m sure that there are these innate abilities. I just don’t really know that it’s relevant in the larger picture for child who is more graceful as that someone who has been given more opportunity to explore his or her physical boundaries and has just developed this a little bit earlier as the other child. Has the other just not had this opportunity yet? And if you give that child, we’re talking about what, three-year-olds? If you do give them the opportunity, who’s to say that they won’t be very, very graceful at age eight?

Yeah, I think I’m starting to come around. So I used to be closer to I think what Chuck’s describing. I used to assign this default ability level. And I think I’ve over the years come around more to what Katrina’s describing. So my brother is one of those kids who everybody describes as having innate musical talent. And he was playing songs at a ridiculously young age. He was composing songs by the time he was 11 or 12, something like that. And it’s just this innate ability. So when everybody describes it, it’s like, “Yeah, from the beginning he could do this,” which isn’t actually true. It’s that from the beginning, he worked on this. If you start when you were three then if Gladwell is right, and that’s a whole separate topic, but if you need some number of hours to hit before you start and get good, my brother probably hit that in his teenage years, because he had all that early on practice.

I think we all generally agree on this. The value that I assign to this natural aptitude is more or less along the lines of we like to do things that we’re good at and we also get recognition for being good at things. And so whether we practice it because we want to be good at it and become good at it and get recognition or whether we have some kind of natural aptitude and we get recognized for doing something unexpected with it given our level or experience, I think that’s really all that it gets us. And the rest of it is effort. The rest of it is the time that we put in learning how to do it. And I think, as I said before, I think that can really trump the natural aptitude for some of these things.

I have two points to throw on that before we move on to another topic, if you want to go ahead.

Take your points.

Okay. The two points that I wanted to throw on is that natural talent, I was very talented at computers. I met my first computer when I was 13. And I immediately just had this intuitive understanding. I was completely unafraid to explore them, to break them, to write programs that made them fail. And I probably had my 10,000 hours in before I was 18. No, that’s probably not true. Before I was 22 though, definitely. And the thing is that I was a natural, which means again, I

pursued it because I was special and it let me say, “Look, I’m special.” It let me prove that I was special. And I was putting in lots and lots of effort because it was fun. Naturals have blind spots. This is common among all autodidacts. We have blind spots that you don’t have if you have a formal education in something that’s well-grounded and well-rounded. And so even to this day, I will come across things that we’ve known about in computer science for 30 years and I’m like, “I never knew that. Holy crap.” And what I have had to learn in order to succeed is the toolset of how to work and how to put in grit. And that’s my second point, which is that in Outliers, Gladwell basically discriminates. He basically says talent and grit are two parts of an equation and if you have grit, you can become world-class at something. And world-class doesn’t mean you’re the best in the world, but you can get into the top 10,000 of any field with just grit. Anybody can get to Carnegie Hall. Anybody can get into a symphonic orchestra, basically, in a large city somewhere, if they’re willing to sacrifice much of their life to do it. Gladwell then says if you take a natural and give them no opportunities or, like in my case, my parent’s didn’t go, “Oh, you’re a prodigy. Let’s send you to MIT prep,” or anything like this. None of that happened. So I was a very lackluster student. I flunked out of college and I continued being a natural. And I never really learned those tools until much, much later. But if you take a natural and then you give them a crap load of privilege, and Gladwell basically says it’s just luck, it’s just circumstance. Bill Gates lived a mile away from a supercomputer as a kid that he had access to. And he had the talent. And basically if you have this talent and this aptitude, you can not only become world-class but you can become the best in the world. And that’s where a lot of people get turned off by Outliers. They’re like, “Well, you’re saying I can’t be the best.” And I actually find Outliers to be a very inspirational book. I’m never going to be able to dunk a basketball from the free-throw line or from the three-point line, like Michael Jackson or [Chuckles] Michael Jordan. [Laughter]

Like Michael Jordan could do. I just don’t have that physical ability and I never will. I wasn’t born with that innate talent. No amount of basketball camp could get me to do that ability. But if I had started at age 5 playing basketball and had put all this effort into it, I could have played pro ball. And that’s the takeaway. There are only 10 seats on the Olympic rowing team. But anybody can become world-class and compete professionally at rowing if they use their grit. And so if worldclass is achievable to anybody, then certainly mere professional excellence is available to absolutely anybody that’s willing to put in effort and study and try and learn.

Okay. So I think the point that I would like to make about talent versus skill is that it may take some natural talent, it certainly takes a lot of grit, but I think the amount of natural talent that you need is enough. That’s the only amount that you need. Grit is the thing that will take you far. If you have only natural talent and no grit, you will not get anywhere.

Yup.

Yeah, I agree with that. Just typing speed and stuff. As my disease progresses, my typing speed is going way down. So if you say that innate usage of a keyboard and the ability to type fast is part of programming, then I’m going to say, “Eh, I seem to be getting around it okay.” But yeah, that would be one of those nice-to-haves but I don’t.

Right.

Just a quote for James. Ron Jeffries once said that he could successfully program by carving characters into bark with a pen knife and he would probably write better programs if he did. Because programming is about your thinking speed, not your typing speed. And he actually considered being able to type more than about 60 words a minute to be a defect.

What were you going to say, Katrina?

I’d like to go back to this idea of 10,000 hours. A lot of people attribute this to Malcolm Gladwell and Outliers. And really, it comes out of research from a fellow named Ericsson and a bunch of his colleagues. And people talk about the 10,000 hours as though 10,000 hours is what you need to become good at something. And that is entirely not the point of the research. The point of the research is 10,000 of a particular type of effort is what it takes to become world-class, to sit on that symphonic orchestra. And for normal people who are not necessarily aiming to be world-class because that takes a lot of effort, it’s very painful, it takes a lot of sacrifice, you might not want to be world-class. Just saying. So the 10,000 hours is not 10,000 hours of doing something. It’s 10,000 hours of a very deliberate type of effort to take you to a level, a degree of proficiency that is very, very rare. The 10,000 hours rules is about people who are at the very top of their field, the very, very edge of what is currently possible in a field.

Yeah, I think that’s a great point. My favorite example of that does actually come from Gladwell. He goes into deep detail of The Beatles’ rise to fame. And they spent lots of time basically playing music in German strip clubs where people weren’t exactly super interested in the music. [Chuckles]

And so that there, basically playing music all day long in these clubs, and they were bored. So they would play with each other. It was like, “Hey, what if we do this?” “Hey, what if we do that?” and all this kind of stuff. And so by the time The Beatles show up in America and basically become world sensations, music was just this thing they did. They practiced with each other. They tried crazy things. They had made up songs and just done all kinds of stuff. And it was that deliberate kind of practice that by then music was something they had a lot of control over. But yeah, it’s like Katrina said. It’s the way to mastery. And we know that from all these schools. Jumpstart Labs has gSchool and the other programs like it, they get developers jobs in six months. So they’re probably not getting 10,000 hours in that time period, but that doesn’t mean they can’t program.

But I can guarantee that they are not world-class at the end of the six months.

Right, yeah. Exactly. They’re not that. True.

So we’ve talked a lot about natural talent versus skill. And we’ve started talking a little bit about practice. 10,000 hours of practice, deliberate practice. I wouldn’t mind going into a little bit more about what practice is and is not and how to do it. What do you think?

Yeah, absolutely.

Yeah.

So I could kick it off?

Yeah, please do. I’ve wondered about this a lot, especially in programming. So go for it.

I read a lot about practice in my quest to become better at things like physics and math and later programming. My reading of this is a couple of things. People say that practice makes perfect. This apparently is wrong. Practice makes permanent. So practicing something will make it, it will optimize the neural pathways that you use to do that thing. So if you’re practicing something wrong, you will end up being permanently wrong. So that’s one important part of practice. Another thing that I’ve found about practice, or read about practice, is that there are very many different types of practice. And you do them for different purposes. So the basic five types of practice that I’ve come across and thought a lot about are drills, where you focus on a specific skill, a very, very narrow skill. And you have a lot of repetition and a really, really close, tight feedback loop. And you do it over and over to embed something more deeply neurologically. Then you have simulations where it’s like a safe environment to do something that is real-ish. So in sports, that’s where you have these games that are not official games. You just play against your teammates in pretend situations. And these often optimize for adding the types of things that you might hit three times in a season. But you’re optimizing the simulation so that you get it over and over and over again so that you can become better at being more flexible in those types of situations. And then there is case studies where you observe and reflect and think deeply and analyze. I usually hear about case studies in people doing MBAs and that sort of thing. But it’s also very typical in a lot of different fields, for example in chess, where people will study a particular board or a particular game and try to imagine or determine what the next move is going to be.

Very good [inaudible]

Yeah, and then they go check that against what the actual grandmaster did in that game next. And then when they discovered that they don’t have the same idea as the grandmaster, they try to figure out, “Okay, why is the choice that the grandmaster made probably a better choice?” And then you have what musicians and dancers and circus acrobats do, which is direct practice where you have a particular piece that’s a performance piece and you practice it until you know it so by heart that you can focus on the higher-level details of nuance and all that. And then you have imitation, which is a really interesting one, which I think probably is one of the oldest ways of learning that you have with old apprenticeships from the middle ages. And doing exactly what a master does without any judgment about why you’re doing it or what you’re going to learn from it.

And then in retrospect, discovering what you’ve learned from it.

Wow, there is so much great [inaudible] that.

Wow, yeah.

I know. [Chuckles]

I’m still typing.

I do want to hit on one point a bit. You mentioned multiple different ways in there how you can get stuck. Like you can be practicing the bad stuff instead of the good stuff. And I think Kathy Sierra’s been talking about this quite a bit lately, that in the beginning it’s way better to expose you to good stuff than bad stuff. We have this idea that you should see lots of different things and that you can’t really know what good stuff is until you’ve seen the bad stuff. And that may be accurate at higher scope levels and stuff. But at the lower scope levels, being exposed to good techniques and stuff is super, super valuable. And if you’re practicing that from day one, think about it this way. when you’re learning to program, if one of the first things you learn is write small methods, how far will that get you? Pretty far, right?

Pretty far, yeah. Brian Marick did a talk at Rocky Mountain Ruby this year and he talked about something that he took out of, I think ‘Thinking Fast and Slow’. And that’s this idea that there are some types of thinking that you do that is very deliberate. It’s very linear. And then there’s this other type that’s very synthetic and it happens at a preconscious level. And he talked about his wife who teaches veterinarian students at a college. And one of the things that they need to teach these students is how to recognize a cow that is healthy or sick. I think they call it bright or dull. The way that they do that is that on the one hand, they show them a lot of cows and on they have the student guess. Is this a bright cow or a dull cow? And then they distract the student with reasons. So their subconscious, their preconscious, is learning a bunch of signs, but not necessarily in a very explicit way. So when the student says, “I think this cow is bright,” then the teacher will say, “Well no, it’s dull. Look at the ears. They’re doing this.” So the next time, they’ll see a cow that has ears doing this and they’ll say, “Oh, this is a dull cow,” and the teacher will say, “Well, no. This is a bright cow because look at this other thing.” And so over time, they’re exposed to hundreds and hundreds and hundreds of cases and they build up this reflexive idea of what bright or dull means. And I think one of the really good things about what Kathy Sierra, or one of the interesting things about what Kathy Sierra has been talking about is exposing beginners to lots and lots and lots of good code is they won’t necessarily know why it’s good but they’ll have developed some sort of instinct and that they will start recognizing things that maybe later, maybe months later, they’ll be able to articulate why this is a good thing, particularly in comparison with some of the newer things that they’re seeing that are bad.

That’s a really great point. You don’t need to know why short methods are better to greatly benefit from writing short methods. If you do that, you will be better.

But if you write long methods and you get in the habit of it and somebody comes along later and says you need to write short methods, you actually will resist it. Or at least, I did. It was very common for me to write 50-line, 60-line, 100-line methods fifteen years ago. And that’s how I learned to program. And when people came along and said write short methods, my immediate reaction was that,” I’m going to have little methods. They’re going to be scattered all over the place and I won’t be able to understand my program.” I’ve since learned better. [Chuckles] You can understand your program and maintain your program better if you do actually learn to write small methods and pay the price to keep track of them.

Yeah, on top of that, oh, are--

I was just going to say that the metaphor I like to use is that it’s a really poor way to learn to ride a bicycle by learning every possible way to fall off the bicycle.

Yeah, one thing that I want to add to that though is that it goes back to Katrina’s point earlier where practice makes permanent. So it took me a long time to get used to doing TDD. And I conceptually understood why I should do it. People had pretty well convinced me that it was a really good idea. But I had been practicing so long doing it the other way that if somebody had taught me to do TDD from the beginning, then that would have been the permanent reaction. So even though I had bought in, I still had to put in the time to practice it the right way to basically undo the bad habit of just going in and cranking out a bunch of untested code and hoping that it worked.

Well there’s something really satisfying about being able to get something done. So that if you’re writing a 100-line method, you’re totally getting it done. It’s working. You’re delivering value. And now if you’re going to have to go learn how to do something that you don’t know how to do, it’s uncomfortable because you’re going to suck at it. And it’s really hard to suck at things. For me. Other people are probably better at it. But I hate sucking at stuff.

It really hurts.

It’s [inaudible].

Well, and I’m not a special child, right? So since I suck at it, I’m not smart.

Exactly.

It’s funny that you bring up sucking at things because I am a tournament chess player and that’s one of those things that’s, ugh, horrible. I don’t even think I’d recommend it to people because the only way to get good at chess is lose 5000 games. [Chuckles] It’s terrible.

There’s a meme going around the internet right now that just says, “Remember, sucking at something is the first step to becoming sort of good at something.” [Laughter]

I like that.

I have a question though. This is something I have been thinking about a lot lately and I don’t have the answer. So I’ll dole it out to the group, or I don’t think that could be answered. Katrina was talking about how you learn to recognize these different qualities in animals or whatever to tell if they’re sick. In programming we have a similar thing. We have code smells, which is how we learn to recognize that code is sick, so to speak. And we know these things we’re supposed to avoid. It’s come to my attention recently that one of the largest differences, I believe, between a programming novice and a programming expert is that we can filter these criteria. I’ll tell you what I mean by that. I get emails sometimes. I got one a while back about somebody who’d been listening to our show and they read Sandi Metz’s Cdr and several other things. They’ve basically gotten themselves to the point where they were getting a solid understanding of all of the things that are at play when we write software. So I need small methods and I need to do this and I need to do that. The problem was they were taking all of those things and trying to apply them all at once. And when you do that, you’re basically penalized. If you try to apply all the rules of programming at once, you pretty much can’t program. [Chuckles] Because whatever you do, you’ll be pushing against one of those criteria. And somehow, experienced programmers seem to develop this intuition of which criteria applies right now. Oh yeah, I know we’re usually supposed to do this, but in this case that’s not the most important thing. In this case, the most important thing is that I follow this other rule and that’s going to make up for the fact that I’m [slagging] this one. And there may be situations where you can follow all the rules or maybe most of the rules. But there are definitely cases where you have to make tradeoffs like that. And I want to know how is it that we develop that? What is it that pushes us over that line, being able to filter that?

I have a hypothesis about this. I think that it has to do with choosing to follow only one rule to an extreme in a bunch of different situations and seeing where that plays well to you and where it really screws you up. What are the pain points? What are the tradeoffs that you are making by following this rule? And I think that that experience and that pain and those wins are the thing that let you recognize that this situation here is a lot like this other situation where following that rule was not the most important thing.

That’s a great point. Because I do obsess over things. I don’t know. That’s how I learn them. I learn something new and I’m like, “This thing is amazing,” and then I go to my next project and I do that thing straight to eleven until the entire thing crumbles under its own weight. [Chuckles] And it’s like, “Oh yeah. That’s the downside of that.”

Yup. I wonder if that’s like what Dan Kubb was doing when he was on the show and he was talking about how he would do these conscious experiments with his code and he would change his style and do things in a specific way. It’s almost like the NOPS thing used positively. You notice a good technique and you decide to own it and then you push into it and stay with it and dial it up to eleven. And then you own it at that point. And then you can step back. At MountainWest Ruby Conf last year, I spoke about, gave a talk called ‘What’s wrong with the Ruby Object Model and why it’s a good thing’. And I showed this really hairy hack that I wrote where I basically wrote my own file open function just so that I could stub file open in a test suite. But you can’t stub out file open because the test suite is opening files all the time. So you have to write your own wrapper to file open if you want to stub out your program’s file reading. And I mentioned that this was a nasty hack and it’s a bad idea and don’t do it. But every once in a while, you’ll find yourself backed into a dark alley and all of a sudden, that becomes a local maximum of it’s one tiny little feature and all these bad ideas combined into one. And when you’re in that back alley, that little hack is like having this rusty shiv in your back pocket that you can haul out and go, “Okay I know how to monkey patch this to get my way out of this corner that I painted myself into.” And you wouldn’t ever use it again. So anyway, to the question of how do we find those, Steve Klabnik talked at LoneStar and he basically said go play and do gross things and then just don’t ever put them in production code or I will quit.

[Chuckles] Yeah that was a great talk. Okay. So we’ve spent a lot of time on the idea of talent and effort and practice and all of that. Maybe we should get into some concrete things. The thread on Parley was really good and had lots of concrete tips about how to learn. What do we think about going over some of those?

Yes. I’d like to actually divide it into two sides of this. It’s how do you start learning something and how do you get better at something.

Okay. Good point. Tips on starting learning something.

Alright.

I guess I’ll go. Let’s go back to David Brady’s meme. Sucking at something is just the first step at becoming kind of better at something. What was it?

Becoming sort of good at something, yeah.

Sort of good at something. I think there are several things to be aware of when starting something. The first thing is that it’s going to be painful. You’re going to suck and that has to be okay for at least 20 hours. And I think it’s very helpful when starting out to have a very small, very specific goal. Like I want to learn about Cassandra and so I will figure out how to take my log files and write it into something and then get out a time series. Or I want to have something that is very doable and very specific. I’m not going to read all the books about it. I want to be able to actually achieve some specific thing. And to me, starting to learn something new really has to involve doing something and not just thinking about something. Otherwise, I never get better at it.

Yeah. I like what you’re saying there about the small task. I still struggle with that sometimes, biting off more than I could chew. And success is addictive. [Chuckles]

Yes.

Yeah.

So it’s good if you have these little successes along the way, because you’re like, “Oh, I can do this. I’m getting this.” Whereas if you lay that whole mountain in front of you and start climbing, that’s a long way up.

I want to expand on that a little bit, just the idea of having a goal in mind. I think it’s incredibly important, particularly with tech learning. I’m not sure how much this applies to other areas. But with tech, tech learning I’ve found that I absolutely have to have an excuse to learn something. I’ve tried over and over again to learn things just for the sake of learning them. And I do. I still do it from time to time. But when it comes to programming languages or new database technologies or whatever, if I don’t actually have an application for it, it’s not going to happen. I’ll pick up a few things about it, but the actual learning is not going to happen. You have to have an excuse. And the excuse can be, and often is, an actual need in an application that you’re developing, in which case it should be not an application that you’re developing because you wanted to have that excuse but actually an application that you really want to have. Because you need that impetus. But there are other excuses that you can come up with to force, or that I can come with to force myself to learn. The one I’m sure I’ve mentioned before in our episode on doing talks is decide that I want to get better at something and so propose a talk about it and then if somebody accepts the talk then I have to actually learn about that. And so that’s another excuse. Btu yeah, with tech stuff I’ve never done that well, learning a new skill without something hanging over my head where I need to apply it.

So how do you determine, Avdi, okay, let’s take on the NoSQL databases. There’s a bazillion of them. Each one tends to be better at certain little things. How do you know when you should go learn that thing?

That’s a great question. When they were first coming out, I think I feel this and I suspect that we all feel this at times, is that when there’s a new technology or a bunch of new related technologies coming down the pipe, we feel compelled to get on top of it and know all about it. Because we’re geeks and we’re developers and we need to be on top of this stuff. And I think that’s true up to the point of you need to be aware of what these things do. you need to be aware of what the point of these things are, which might mean hunting down somebody who’s using them in production and saying, “Okay, what the heck is the point of using Mongo? Why are you doing it?” But that’s the end of it until you actually run into a problem where you really, really do need it. As far as I can tell, if I’ve done some inquiring around things like MongoDB and some of the other NoSQL stuff, as far as I can tell the only time you actually really need it is in applications where you’re doing tons and tons of writes. You’re just consuming enormous amounts of information from everywhere and lots and lots of clients are writing to you and you don’t have time. You don’t need the ACID compliance of a full relational database. And you don’t have time for the ACID compliance of a full relational database. You just have this massive scale of tons of writes. And there are a few other use cases for the Mongo case, like there are certain very specific types of documents where that makes sense to store in a DB like that. So that’s how much I know at this point. I’ve done a little asking around and I understand maybe three triggers which would make me, in an application, which would make me say, “Okay, I think this actually calls for Mongo.” And at that point, I will have a great excuse to learn MongoDB inside and out. But until that point, I’ve given myself license to not care.

I think what you just said, the license to not care, is such an important thing. When I’m teaching new programmers, I often try into their head that everything you look into in programming is a giant Alice in Wonderland style rabbit hole. So you have to think really hard about whether or not you even want to turn over that stone and look underneath it because you get so overwhelmed, in programming, if you don’t take some things on faith for a little while. But this is how this works. I’m way over-simplifying it, but let’s leave it at that for a while until you really need to go down. Because that’s a long trip.

So going back to having a particular goal, I think that’s also very important when you want to get better at something that you’re already reasonable at. Somebody emailed me the other day saying, “How do I get better at programming?” He was a competitive swimmer back in the day. I think he actually trained with Michael Phelps and stuff. And when he was training swimming, he had very specific metrics that he could measure. How fast, how this, how that. And with programming, nobody’s been able to give him metrics. It’s like, “How am I going to get better at programming? Well how am I going to know that I’m better? What am I going to get better at?” And so he had set some sort of training schedule that was like do one of these classes every month. Read a technical book every month. Write a side project, a side app every once in a while. And to me, those are not measures of accomplishments. They’re not really even goals. And it’s really hard. If you want to get better at programming, what part of programming do you want to get better at? Do you want to have more fluency in the language? Or do you want to get better at design and refactoring and testing? Like this OOD type of thing, if you’re writing in object-oriented language. Or do you want to get better at communication? Do you want to improve the expressiveness of your code and how you name things? Or do you just want to get better at understanding algorithms and data structures so that you could solve bigger problems? Or do you want to dive into one of the rabbit holes that James was talking about? Or do you just want to get better at problem solving detached from programming? Because there is a lot about problem solving that has nothing to do with turning it into syntax and making a computer read it.

Wow. That was awesome.

I feel overwhelmed just from that list.

Yeah, me too. [Chuckles]

I think there are a lot of moving parts in what we do. And I do think there is a fundamental difference between programming and, say competitive swimming just in that there are performances, there’s performance and then there’s creation. And it’s hard to even draw parallels between getting better at a performance, whether it’s a performance of a physical feat or a musical passage, versus getting better at creating things. I don’t know. It seems like we don’t have metrics. But what you can do is you can observe yourself traveling from the point of inspiration to the point of delivery. And you can make notes along the way, say about what are the things that slowed me down. And you can make sure that the things that slow you down next time are not the same things that slowed you down the last time.

Yeah. I think that’s true. And almost depressing. When we go to a new project, it’s like, “Well, I’m not going to make the mistakes I made on the last one.” So you make different ones, of course.

And hopefully you’ll make better mistakes.

Yeah, less damaging.

I think it’s very possible to make better mistakes. It’s very possible to work at a higher level the next time around. And you’re still nitpicking your performance but in the grand scheme of thing, they’re smaller issues than the last time.

I think mistakes are really interesting. I think that they’re a way that, it’s a thing that you can use very deliberately and say, “Okay, I’m going to do this thing,” and then I’m going to step back and say, “What do I not like about what I just did?” And even just considering that can give you ideas for maybe how you can do it differently next time. And then you change it a little bit and you step back again and ask, “What do I not like about this little thing that I did now?” And this can give you something to focus on. And I think it goes back to even though we don’t have metrics, we can set goals. We can be very specific about the thing that we want to try to improve.

Can you illustrate that? Is there something that you’ve worked on recently that you looked back or that you worked on a while ago and said, “Wow, that really sucked. I want to get better at that.”

Yes. Well, let me say, “Let me do refactorings,” and it’s something that I do a lot. I recently solved a children’s song. Solved in the sense that I wrote a program that outputs this children’s song. And it’s a cumulative song. So there are a bunch of these. There’s the 12 days of Christmas cumulates one phrase for every, so this was one of these cumulative songs. And the first version of this is a really stupid big conditional that has a ton of duplication. And I’ve refactored it over the past week or so. I’ve refactored it, I think four times. And every time I refactored it, I stepped back and said, “What do I not like about both the choices that I make in refactoring?” like in the sense of, “Where did I go? What are the things that I tried?” and also, “What do I not like about the code at every step?” And so each time I refactored it, it was different. I chose a different path. And part of my reflection on this was, “Well, did that path lead me to a place where I didn’t know where to go next?” or “Did it make it easier to take a small step and another small step and another small step?” So that’s one of the things. Another example would be with testing. And I guess it’s back to refactoring. It’s how small can the step be? So I’ll try to notice as I do a refactoring, are there any places where the tests are red for a long time? And then if they are, I try to go back to the last place that it’s green and find a different step, a smaller step, so that I can run my tests often and that they’re never red for a long time.

Cool.

So in the thread on Parley, one of the big topics, actually what started the thread, was how to read programming books, manuals, things like that. And there were a lot of good techniques given in the thread. And I think it might be worth it for us to just hit on some of those. I’ve been doing this a lot recently. Finally sat down and decided to learn JavaScript from the ground up and figure out all these things I didn’t know about it. So JavaScript, Jasmine, CoffeeScript, Backbone, et cetera. I’ve been spending a lot of time on that. I used these techniques I have for how to read books. And so I go about it. I know Dave and I have a similar structure, although his has a few twists, mine doesn’t. I’ll bring it up here just in case it’s useful. But when I want to read a technical manual, like an involved book like the Pickaxe or something, the first thing I do is get an overall familiarity with it in that read the back of the book, read the table of contents. Usually the short ones, like technical books, often have the short table of contents and then the expanded detailed table of contents. Get the lay of the land, maybe thumb through chapters a little. See what’s big and what’s not. Oh, this is half the book, things like that. And then I’ll actually go through and do a thorough page-by-page read. And I know there are different techniques. A lot of people like to read the book slowly and do the code examples and stuff as they go. I will do that on the occasional rare book. ‘Understanding Computation’ is the most recent one that I can think of where I literally worked through the code samples. But more often than not though, I actually prefer to read it away from my computer and just absorb the content and roll it around in my head. And I will come up with questions, as I know like, “Hey, what if you did this but you did it this other way?” And then I may stop between chapters and go try that little thing. But I won’t typically type in all the code, I’m more loading it into my head. But then after I’ve finished a book, I go into this stage where I do some automations. And I’ve talked a lot about how I do automations and stuff like that, so I won’t go into that too much. But I will say that that step is really key to cementing it in my head. For example, when I learned JavaScript, recently I read ‘JavaScript: The Definitive Guide’ and then I went through the back of the book, the reference part, which just covers all the methods in core JavaScript, or functions I guess they’re more often. And I went through all of that and I do things. I’ve asked myself, “Will I be using this? How often will I be using this?” stuff like that. And I’ll take an existing set of automations I have at my editor, my Ruby automations, because I’ve worked on those for years and years and I really like them. And so then I’ll make a list of them and I’ll be like, “Alright, should I move this one over to JavaScript and if so, what would it look like there?” And then I’ll go through the JavaScript reference section. I’ll be like, “What are the JavaScript-isms that I don’t have in Ruby at all? And how should I make automations for them?” And that process of working through the little details like that gets me to the point, by the time I finish that series of automations, I’m actually comfortable to write with that thing, whether or not I have the automations or not. It’s not that I

need the automations before I can program it. It’s that it got me to think through those pieces. In the case of JavaScript, I think through how would you do scan in JavaScript? You know, Ruby’s method where you call it, give it a regex, and it hits every match. That’s a little more complicated in JavaScript. It’s not just a single method call without a few tricks involved. And so thinking through that gets me to a comfort level where I feel like I’ve leveled up confidently in that.

You hit on an interesting point, that there are actually two or three different modes in which we can read. And I love the second one that you described there where you get away from the computer and just sit down. There are lots of techniques for reading for information and studying from books and trying to aggressively power your way through a tome of information. But we forget that there’s another way of reading, which is like sitting down with an old friend and, or with a new friend rather, and just chatting and just exchanging ideas. And it’s the sitting down by the fire with a good book, that kind of thing, is if the book is well-written, you can do that with a book. And yeah, you start at the beginning and you read to the end. One of the things, I did a lot of speed-reading work in college before I flunked out. But it’s one of the things I did get that was useful out of there. And my speed-reading speed is actually quite high. And what I have learned is that there’s almost no upper limit on speed-reading. It’s pretty high. What there is a limit on is how many new ideas your brain can process over time, how fast your brain can process ideas. And it works out that it’s about seven seconds per idea. And so I talked in the pre-call about reading a book at about 80,000 words per minute. The reality was is I was familiar with all of the ideas already. I just needed them organized. And the book that I was reading organized those ideas for me. And so I was able to power through it very, very quickly. ‘Understanding Computation’ was a book that was full of new ideas for me, almost on every page. And it’s like hitting a speed bump every time. You turn the page and you go, “Ooh, new idea,” and I’ve got to sit with that and absorb it. And for those kinds of books, you can take your pick of whether you want to power through it or dive into it or whether you want to just sit and read it from one end to the other. Either way can be overwhelming, if you let it, which can be fun. But yeah, the only thing I would add to what you said, James, about the first way of reading is that if you really want to aggressively attack a book and just shove it into your brain, is do those steps where you start at a high-level scope and work lower and lower and lower. Do those explicitly and actually in writing. So sit down and say, “I’m going to spend 60 seconds deciding if I want to read this book or not.” And that is your purpose for the next 60 seconds. So you read the dust jacket and the front and the back and skim the table of contents and that sort of thing. And then at the end you write down, do I still want to read this book? Yes or no. You write, yes I do. Okay, now I’m going to take two minutes and I’m going to get the lay of the book. I’m going to get the layout. So the Pickaxe book, I would actually thumb through it, read the entire table of contents carefully. But then I would thumb through and get a feel for how big the chapters are. Oh look, we have this big first section that’s all about the theory of Ruby and how to program in it. And then there’s this huge reference section. Oh, and the reference is broken into core and standard library. Okay, that’s good to know. Because when you first get into Ruby, the distinction seems very arbitrary. Why isn’t StringIO in core? Why is it in standard library? I don’t know. That sort of thing. And then you write down, okay I now have the layout of the book and it’s approximately this. And you write it out. These are the pieces. And then you write the set of questions that you want, almost like you’re writing the exam that the CS professor would give you at the end of the book, of questions that you want to learn. And now when you go back and read the book in depth, you actually have a purpose. There’s a thing called information retrieval bias and what it means is that we tend to value information more if we had to go get it ourselves. So if you’re just reading casually and you stumble across something on the page, that can be fun and it can be a good lesson, but you emotionally you will value that less than if you already were looking for that answer and you had already formulated that question. And that’s what, when I power through a book at the high-levels, I will write out what I want at each level of abstraction, finer and finer detail, to the point where I’ll write out, “This chapter I want this information. Can Ruby do threading and how?” and that sort of thing. And then when I hit the answer, I’m like, “Aha! I have it.” And information retrieval bias causes me to value that information more and I will lock it into my memory faster and more deeply.

So there’s this distinction that you’re making between gaining information, like getting facts, and retrieving facts and understanding. Understanding is different from information. And understanding something deeply is completely different from recall. And I think that how you read a book is going to depend on what you need to get out of that. If it is a deep understanding, you’re going to read it in a very different way than if all you really want to know is comparing different NoSQL databases or non-relational databases with each other. DAVID: Absolutely. So there’s a trick for that. I guess I’ll throw this in. this is one of my picks. But a lot of my learning brain hacks center around shotgunning information into my brain. I do this silly party trick where I can go to the whiteboard and I can have the crowd shout out a list of 20 things that they want me to go to the store and buy. And I will write them on the whiteboard as fast as they shout them out. Well, as fast as I can write. And by the time I get to number 20, I can put the marker down, I could turn around and face the audience and I can then recall the entire list. And if you give me an item, I can tell you what number it was. And if you give me a number, I could tell you what the item is. They’re completely locked. I can access it like an array by index. And it’s a party trick. It’s a brain trick. But it’s immensely powerful for learning and understanding because you can’t learn a book by osmosis. You can’t put your textbook under a pillow and sleep on it and wake up knowing calculus. But if you can load all of the facts, way more facts. A human can repeat five to seven things in short term memory. What if you could keep a hundred things in your short term memory and churn them over all at the same time? And the answer to that what if is you very quickly start seeing patterns, because you’ve got a larger dataset in your working memory. And you start making connections between things. And so it really drives home the interrelationship between the data. So that’s a trick that I will use for understanding data, is I will first load all the data into my head very quickly. And now I can be driving in the car and I can actually pull up the list of all the facts in my head because I’ve used this trick to put them in my memory. And so I’m standing in line at the supermarket and I’m actually reciting out this list of facts and interrelating them and linking them together. And so it’s a cheat, really, for studying. It’s fantastic for college students. I’ll give a couple of books in the links at the end for how to do those tricks.

I just want to say, am I the only person who reads books like a normal person?

Yes.

I start at the beginning and then I fall asleep drooling at about the fifteenth page. [Chuckles]

Yeah, that’s me.

I do that for science fiction. [Laughter]

The fall asleep on page 15?

Yeah. No, I don’t usually. If it’s well-written, it holds my attention. I just wanted to say I read from the beginning to the end if it’s entertainment. Or if it’s something where I don’t need to have a deeper understanding of something. Then I’ll just read straight through.

If I read a tech book at all, unless it’s just a reference, and even when it’s a reference, I read books straight through. I don’t always make myself spend lots of time on each page. Sometimes it might be close to skimming. But for me, it’s all about making myself aware of where to find the information that I need when I need it. Sometimes, I read patterns books all the way through. And I don’t spend a lot of time on each pattern. But I make sure that I’m just aware of what it is and what it’s there for. And that means that someday, I’m going to be working on a problem and it’ll pop into my head. Oh yeah, this triggers a memory, and I’ll go back and I’ll look it up in detail. But I tend to use that for a lot of tech books. I just read it all the way through, but I make sure I’m just filing away where to find stuff.

Sounds like you have a very specific goal, which is the point, right?

Yeah. I do like to read a whole book. Before I tackle a programming language, I’ve always liked to read an entire book first, and maybe do a few, a little bit of practice while I’m reading it. But I like to go from beginning to end. Because what I really hate is just not knowing whole areas or now being aware of whole areas as I’m working with a new technology or a new programming language. Because I find that I can waste a lot of time if I’m using a programming language where a lot of its power lies, let’s say in macros, but I’m not actually using macros yet because I never learned about them. I feel like that can waste a lot of time. So I want to be aware of the landscape and so I’ll read from beginning to end and something. And then I’ll reference back as I actually hit stuff that I’m practically doing. I’m also pretty free with the highlighter as I go through a book. Whether it’s an eBook, e-Readers mostly allow highlighting these days, or a physical book, I tend to mark things up a lot. I’ll mark up a sentence that either caught my attention or that seems like it sums up the point of a series of paragraphs. And then as I’m flipping back through it in the future when I’m trying to find that one thing that I remember, usually that one thing that I’ll remember will be something that I highlighted. And it’ll be easy to find.

I’ll find myself flipping through a book all the time, not looking for a section of the book, but looking for a specific pattern of underlines or notes in the margins.

Oh yeah, yeah. Absolutely. The visual memory works way, way better than anything else.

Yeah.

I used to have the page memorized in the Pickaxe that had the exception tree. [Chuckles]

All the different exceptions and how they inherit from each other. And I would always go to that page. Which one do I want to throw here?

That’s actually, stuff like that is a good use for actual physical little callout stickers. I keep some callout stickers in my desk. And I’ll stick them to reference pages like that.

Yeah. I went through the Pickaxe reference with little Post-it tape flags. And I just flagged everything. I should back up a little bit. I am different from you Avdi in that I am very comfortable with having blind spots. And so I actually wrote a blog post about this a few months ago called ‘Teach yourself a new programming language in 21 minutes. Or two to three years, it depends.’ And basically, it’s still this top-down approach. You take five minutes and ask yourself do I really need to learn this programming language? And I’ve never needed to learn makefiles. I’ve needed to manipulate them several times over my career, but it’s never been worth learning how to write a makefile. So I always have to go look it up every single time. And I’m okay with that. And I’ve just made that decision. But at the end of the process of going top-down, I do end up at the same place you are, which is where I know where everything is in the book. I might not have read all of the sections because I may have gotten down to a very low level and at the level above I decided, oh this is the exceptions or the macros chapter and I don’t need to know that right now. I know where it is but I’m not going to try and read it right now.

Just don’t throw errors you’re good, right?

Yeah, exactly. Though if I do start throwing errors, then I know that’s where it is in the book. I can go look it up.

See I feel like we’re talking about two different strategies. I would use the kind of reading I’ve been doing for JavaScript books when I really want to finally load it into my head and have it available at a moment’s notice and stuff like that. For me, JavaScript is what Dave just described as for years and years I would twiddle this little thing and get by and I would look up a method every time I needed one or whatever. And that’s how I did it. But then I finally get to the point where it’s like, “Okay, I’m doing enough of this regularly that it’s actually valuable to have it available at all times.” And so I want to load it into my brain. But Avdi has another technique that I like and do use sometimes of familiarity. Not that I need to know it, but I need to know where to go to get it when I

need it.

Yeah, and I apply that even to stuff that I use every day. That’s not just for something that I use occasionally. I don’t feel any compulsion whatsoever to memorize things. I was looking at some of those techniques for reading in the thread on Parley and there was this whole endless blog post about this elaborate system that somebody uses involving space repetition and building up sets of flash cards. And I was just staring at this in incredulity because I don’t understand why. I have so many pieces of technology for looking up information. I don’t understand why I would spend any time trying to commit things to my memory. Some things I use so often that they commit themselves to memory. It’s like a well-optimized cache on a CPU. Sometimes I use a piece of Ruby so often that it commits itself to my memory. And that’s fine. Okay, I don’t need to look that up anymore. But I’m never going to be like, “Oh, I feel bad for looking up a particular Rails method or something like that. I should really memorize that.” If I haven’t used it enough times to automatically memorize it, to just have my brain cache that automatically, then I don’t feel any compulsion to force myself to do it. I think that’s just wasting brain space. I’m used to looking things up every few minutes as I code. And I think that’s normal. I always remember, for me I realize that Arthur Conan Doyle is not a reputable source of neurological information. It always reminds me of Sherlock Holmes’ statement when he was confronted with Watson’s amazement that he didn’t know whether the earth revolved around the sun or the sun revolved around the earth. He was like, “That’s not relevant to my crime-solving and it would take up limited space in my limited-spaced brain. So I toss that out so that I have more room for other knowledge.”

I’d like to push back on this.

Okay.

When I was in college, one of the first biology exams that I had, or it was biochemistry, we had to know all of the amino acids by heart. We had to be able to draw them. There aren’t that many. I was really angry about this. I was like, “This is something that I can look up. Why do I need to know it by heart?” The thing that I didn’t understand until after I had learned them by heart was that so many of the protein structures that I’d be looking at, their properties depended on the fact that they had a large number of amino acids that the pH inside a particular part of your body that would render this protein, because of those amino acids, slightly would have a positive charge or a negative charge or be repulsive to water or whatever. And so those properties, knowing those things by heart allowed me to understand deeper patterns or see more meta bits of information. I don’t think I would have understood that if I hadn’t memorized those.

I’m curious if there’s a programming analogy for that.

I have a Dreyfus scale analogy.

I mean I’m curious if there is a specific programming example of something where memorization would help to see deeper patterns.

So I personally feel, and this is just my own opinion of myself which, who knows how skewed that is? But I personally feel that after I go through it and I do that deep memorization, I know probably 95% of Ruby’s core methods, maybe. They’re just in my head. I wouldn’t have to look them up in RDoc. But that gives me, when I run into a problem I sometimes see it as a combination of Ruby core methods. Like, “Oh, I could do this followed by that and that. Bam. Got it.” And I feel like I can reason about those things better because those little pieces are in my head. I can say, “Ah, this piece gives me most of what I want. Combine it with this one.” I feel like I have more ideas that way.

I may be wrong.

See, I’m comfortable with the sense that I have, when I confront something like that, “Wait a minute,” my spider sense is tingling that there is a way to do this with core methods. And then I go look in the appropriate documentation and I found out that way. But I’m content with that spider sense that says there is something here that I don’t know but I know it exists. I don’t feel the need to actually commit all that stuff to memory as opposed to just knowing it exists.

So an interesting thing that I’ve observed is that not memorizing large banks of stuff is common among people who are high up on the Dreyfus scale. Einstein was famous for not knowing his own phone number. And when pressed on the subject, he’s like, “Why would I waste brain cells committing to memory something I can easily look up in a book?” It’s even an alphabetically organized book. But on the other hand, Katrina mentioned as well, needing to memorize is common among people that are at level one or two on the scale who want to get up into the middle of the scale. I’m in your camp now where I very rarely will aggressively memorize things. But I used to program in C++ and I used to have probably a 90-95% of the MFC API committed to memory. I literally studied the reference manuals and memorized the function signatures and all of that stuff. And it was profoundly useful for things like, I didn’t know design patterns. I hadn’t heard of design patterns yet. But I was getting this intuitive feel as I was looking at stuff that, “Oh, look.” I actually don’t remember enough MFC to illustrate this. But like in Ruby, you’ll see there’s a class method that searches for instances of the class. And then there is a class method to create an instance of the class. But the method to save or update an instance is an instance method. And you see that pattern if you go through active record and read through Rails and see enough object models. It’s obvious when they’re on the page. But until you soak in it, you might not see it. It can be like water. So it comes back to if you’re entering a totally new field, you need to acquire lots and lots of tiny little techniques before you can combine them together into a style. And that is the time when I’ll dust up the party trick of loading up lots of tiny facts into my brain just so that I can review them and hold them and see the relationships and patterns.

I think it’s obviously clear from this conversation that we have different systems and different things work for different people. I would argue Avdi that even your system is pretty deliberate, that you’re purposefully laying out this map in your mind so that when you find yourself wandering in the woods, you at least know where to look. And that alone is a massive preparatory step, in my opinion.

Yeah. I don’t know that I ever worked it out intentionally, but yeah. That’s pretty much what I’m doing.

I just realized, are we ready to move to another topic?

Sure.

I just realized there’s another thing that most of us here on the podcast do, and one of us does it professionally, for a living at least. And that is if you want to integrate your knowledge and understand the whys and some of the wherefores is teach it. Turn around and teach it to someone else. Actually, two of us do it professionally. Well, three. Chuck, you’re running Teach Me to Code. Avdi, you’re doing Tapas. And Katrina, you work at Jumpstart Labs. And James, I don’t know what you do for a living.

Neither do I.

I’ve never cared enough to ask, honestly. I’m kind of a sociopath. But yeah, we’ve all talked, right?

We’ve all spoken at conferences. And like Avdi said, if you want to learn something, give a talk on it. And it’s not just because it will force you to learn the basics of it, but because it will force you to learn some of the edge cases and the intricacies of it and the reasons behind it and the pain points and how to compensate for them.

So you don’t actually have to teach someone else. If you don’t like people, that’s okay. It can really help to learn something by trying to re-explain it as though you were going to explain it to someone else. How do you paraphrase that? How do you rephrase it? What’s a good metaphor? What’s a better metaphor? What’s a bad metaphor?

Wow.

Why is it bad? And if you just use this, just choose your topic and then use this to try to explain to yourself what the topic is, you’ll discover where your weaknesses are. And you can then go find other resources to fill it up. And then as you try to explain it and you realize that you’re being really unclear and wordy, you can say, “Well gee, I don’t actually really understand this part of it really well. How would I optimize my understanding so that I can rephrase it in a more succinct manner?”

Wow.

That’s really awesome, what you just said. Absolutely awesome. And I do that all the time. I enjoy the people aspect of it. And my wife is wonderful and will patiently put up with me using her as the person doing that. If you have a good friend or somebody that will, it’s great. I try to explain, a lot of times when I’m reading books or whatever, I’ll go try to explain it to my wife or somebody who doesn’t know much about it. Although it’s hard, because my wife knows a lot of tech. but I’ll explain it to them and then try to use metaphors like you said so that they understand the big thing, [inaudible] the big takeaway. But if you don’t have a person, or like Katrina said you don’t want to use a person, I have also found talking to my dog works great. The dog is awesome because they’ll look you right in the eye and they’ll cock their head like they’re listening. It’s an awesome trick. [Chuckles]

There’s a formal name for that from the 80’s called teddy bear debugging where you explain the problem to a stuffed animal. And I actually keep a little stuffed gecko on my desk. And when I don’t have a cat or a wife handy, I will explain a problem to the gecko, my little stuffed animal. And I was just going, “Wow” as Katrina was explaining this because it’s never occurred to me to try to do teddy bear teaching and teach something to the gecko. Yeah, I’m going to be on the--

I believe the pragmatic programmer uses the term rubber ducking for that. DAVID: Rubber ducking. Okay.

Somebody used to keep a rubber duck next to their monitor and they’d just talk to it. All it needs to do is bob up and down. Whatever. Just sit there. It’s a very powerful technique, explaining [inaudible].

Yeah. I’m going to be on an epic crazy watch list. I’m already on several. But I’m going to be on all of them now for talking to myself incessantly. [Laughter]

I’m going to go from talking to myself a lot to just nonstop. So this gecko’s going to get sick of me.

Now I want to sneak into your office and do something to that gecko. [Laughter]

Make it talk back.

Make it talk back. Burn the house down. What? [Laughter]

You’ve never said that before, Mr. Gecko.

Well there was that one time. Never mind.

Well, yeah.

Alright. Well, we’ve been talking for almost two hours. [Chuckles]

This episode has been awesome.

I know. I haven’t wanted it to end so I haven’t said, “Let’s do picks.” But let’s do picks.

Okay.

Good.

Alright. Katrina, do you want to start us off?

Sure. I’m just going to give you a reading list. Some of these have been picks before, but they’re relevant to this topic so I’m just going to pick them again. There’s a book called ‘Mastery’ by Robert Greene. It’s a thick book. It talks about achieving mastery on the long term. And it has beautiful stories, historically accurate stories, about how people achieve mastery in various fields. Highly recommend it. There’s another book called ‘The 5 Elements of Effective Thinking’ written by two math professors. And it’s five very specific strategies for improving the process of your thinking. So it’s this idea that understanding something is different, a deep understanding is different from shallow understanding. If you understand something shallowly, you have to memorize a lot of facts. If you understand it deeply, you don’t have to memorize a lot of facts because you can understand things from first principles. It explores ideas of how to use mistakes to improve your thinking, et cetera. It’s very, very good. It’s a very short book and well worth reading several times. There is a book by Cal Newport, a computer scientist and mathematics professor as well, called ‘So Good They Can't Ignore You’. And this attacks the idea that you have to be passionate about what you do and turns it on its head and says that no, you have to get good at what you do. And by becoming deeply knowledgeable and deeply skilled about something, you will discover what is so interesting about it and then develop passion about it. And it also talks about very specific techniques for deliberately becoming better at things.

Cool.

Then there’s a short video to counteract the whole 10,000 hours thing. There’s this guy called Josh Kaufman who did a TEDx talk called ‘The First 20 Hours - How to Learn Anything’. And where the 10,000 hours thing goes to extreme, it’s how to become world-class and really top of the game in something, the first 20 hours is how do you approach something new? And just get your feet wet to a point where you’re comfortable maybe deciding that you want to learn more. So it’s totally at the other end. And it was a useful 20-minute video. That’s it.

Awesome. Dave, what are your picks?

Wow. I’ve got three blasts from the past, mainly because there were things I was very interested in, in the 1980’s and 90’s. And I developed a skillset in them that worked for me. And I haven’t gone back and revisited to see if there’s anything new. But the first one is the ‘PhotoReading Personal Learning Course’ by Paul Scheele. This is the best speed reading course I’ve ever done. I’ve done all the speed reading courses out there. I’ve done Evelyn Wood’s. I’ve done formal in-classroom stuff with the moving plate covering the book and that sort of stuff. And PhotoReading is the only system that I have worked with where it actually focuses on this layered approach to power reading. So you can literally go through the PhotoReading course and not learn how to speed read at all and still double or triple your effective reading speed. Half or third the time that it takes you to get through a book and absorb the information in it, just because it’s so effective in organizing what you’re learning from it. It’s an information product. I will give this caveat. It’s an information product that was marketed to executives in the 1980’s. So it’s quite expensive. I think there’s a set running round on Amazon right now for $175. I’ve seen versions of it that go clear up to $600. And you can find used versions. Honestly, if you can find the first cassette or the first CD, has a self-hypnosis thing. You have to train your subconscious to relax your eye focus so that you can see with your peripheral vision. It’s not really a hypnosis thing so much as it’s an audio coaching thing. It paces you through how to move through the book and how to turn pages and that sort of thing. And if you can find the first CD and the paperback book, the two of those things are really all you need. And you can probably score both of those for under $20 on Amazon in the used market place. The second one, and again these are from 1982 and stuff like that, but there are two books that are just fantastic. One is called ‘How to Be Twice as Smart’ by Scott Witt. And this is a book on basically cheats and tricks. It’s got a chapter, and this pick and my next pick I can’t remember which is in which book. So I’m going to go ahead and tell you what the second book is. The second book is called ‘Make the Most of Your Mind’ by Tony Buzan. And I can’t remember which is in which. They’re both a grab bag of tricks like how to remember somebody’s name when you meet somebody in a room. There are people that can walk into a room and meet a hundred people and then stand up on the podium and then they can call everyone by name. And we all hate those people because I meet people and then I immediately forget their name. And I’ll ask them again and then immediately forget again. That sort of thing. You keep losing your keys. How to develop a habit so that you stop losing your keys. Both books have a different memory scheme. It’s called the peg word, P-E-G, peg word memory scheme. One of them uses a rhyming scheme where if you want to memorize something that goes with one, you picture a bun because one rhymes with bun. Don’t use the rhyming scheme. There’s a harder on to learn in the other book. I can’t remember which one. There’s a harder one that gives you a phonetic alphabet. One is T or D and two is N, that sort of thing. And you have to memorize it. And it’ll take you, you have to build flash cards and it’ll take you a week to memorize the phonetic structure of each of these decimals. But this is infinitely scalable. You can go all the way up to memorizing digits of pi by constructing consonants and then vowels are free. And now you just build phrases out of these consonants. And you can transcode between consonants and numbers. And you’ve got them. So you can memorize large sets of data by associating them with imagery to lock them into your memory. So whichever one you get, if it’s got the rhyming scheme, don’t do that. Use the phonetic naming scheme. I had to learn that one the hard way. Because I could only memorize things up to ten for the longest time and I didn’t want to do the phonetic one. So there you go. There are some blasts from the past for increasing your, actually all three of them are the increase the ability at which you can move information into your short term memory and hold it there. And then all of them repeat the same thing, which is that if you want to move it into permanent long term memory, you have to refresh and repeat. And the difference between these techniques and studying your college textbooks over and over and over is that if you have loaded all this information up into your mind, you can review it standing in line at the grocery store or driving in your car or anywhere. You don’t need your textbook. You don’t have to pay attention to a book. You can be paying attention to other things and you can be reviewing and reciting and studying, basically, without your books on hand. So those are my picks.

Awesome. James, what are your picks?

Katrina had one she forgot. Go ahead, talk it out Katrina.

There’s a paper that was published in, I think 2007 called ‘The Making of an Expert’ and it’s by Ericsson and his colleagues, the people who were the originators of the 10,000 hours idea. It’s in the Harvard Business Review and it’s a really good read that gets away from the market-y aspects of all of this and all of the [Chuckles] cultural memes that have grown up around it. So it’s a really interesting read.

Okay. I’ll do a couple of picks. Okay, my picks. This is a book I read a long time ago, but our conversation today actually reminded me of parts of it. It’s called ‘Mind hacks’ and it gives tons of tips, a lot like David Brady’s been talking about this episode, memorizing large numbers of things and systems for doing that and ways to remember your keys or stuff like that. There are definitely systems for that in there. It’s a collection of a bunch of tricks like the hacks books are. Like anything, several of them are “Eh,” I don’t think I would ever need anything like that or it doesn’t interest me. But there are some gems in there and things I still use to this day. And some good stuff in there on mental math and things like that. So it’s an interesting book, if you enjoy that kind of thing. And then because I mentioned it on the episode today and also it has to do with training. But I have a new dog. And if you’ve been following me on Twitter, you may have seen some pictures that I’ve been throwing around of my new puppy. But what?

You got a Cavalier King Charles Spaniel!

Yeah. That’s why I wanted to bring it up. This is my first exposure to this breed. I had a Shih Tzu before that and she died this summer. And so we picked up a new dog and it’s a Cavalier King Charles Spaniel. And I knew nothing about this breed. It was the vet that recommended it to me because they’re great with kids and stuff like that. This is a crazy great dog. If you’re a dog lover like I am, great with kids, smart, easy to train, toy dog, lap dog. Different people want different things out of their dogs I guess. But this is like a checklist for me of everything that makes a great dog. Not super barky, basically won’t bite me if I put my hand in its mouth. Just really great dog. They come in all kinds of different colors. And to keep on topic, one of those colors is called ruby. The brownish red color is called ruby. I do not have a ruby one. I have a blenheim one, which is the white and ruby mix, basically. But gorgeous dogs, great animals. I’ve been super blown away. I’ve had it for about a month. It’s probably about 90% potty-trained. We’re working on heel, sit, down, come, drop it, all these commands. It’s just picking them up so fast. Really, really great dog. And my three-year-old, it just adores playing with her. So cool dog. If you’ve never looked at Cavaliers, give them a look.

So James, if you ever breed your dog, let me know. I will drive to Oklahoma. They are not cheap out here. It’s hard to find people that sell mixed breeds and the purebreds start at about $6000 out here.

David’s right. It’s not a cheap breed. One of the reasons is that the breed is famous for a really horrible heart problem, mitral valve disease. And they’re trying to breed it out of the breed. But in order to do that, you have to genetic test the parents and stuff like that. It’s very expensive. And it hits a very high number of the dogs. So if you do just buy one from a random person, your odds of getting mitral valve disease just skyrocket. So in order to get around that, people do tend to buy them from breeders. I will say I got mine cheaper than Dave said there. You’ve got to look around a bit. But you can them, but you do have to get them from the higher-end breeders because of the health problem.

Yeah.

Interesting. Alright. Avdi, what are your picks?

His pick is the most powerful mute button in the world.

Yeah, we lost him. Alrighty.

Oh, he fell out.

Yup. So I’ll go ahead and do a couple of picks. My first pick is my wireless Bluetooth speaker died this last week and I listen to music or podcasts and stuff all day. So one thing that I’ve, I got my wife one of these a while back and I really liked it. It’s a Jam Plus Bluetooth speaker and it’s really terrific. So I listen to podcasts and conference talks and things off of my iPhone or my iPad on this all the time. I just don’t really like the internal speakers if I can help it and wearing headphones isn’t my favorite thing either. Though I do it when I go to the gym or I’m in the car or whatever. So I’m going to recommend that. And then the other thing that I’m going to pick is we talked to Joe Kutner about The Healthy Programmer on The Freelancers' Show. And right before that, after I read through his book, I went and bought the components for the Lifehacker $22 standing desk, which nowadays actually comes out to about $30. And I have to say, I really like being able to switch between sitting and standing. So I’m going to pick that. And I’m also going to pick the monitor stand that I got. I got a stand that holds two monitors. And so it has two arms on it. And it’s funny, because if you walk into my office, you’ll see where I sit in my chair with the two monitors in front of me. And then you’ll see the standing desk has two more monitors on it. So I just switch back and forth between the two. And the way that I have my workstation set up, that actually works pretty well. So I’m really happy with that. If you want to know a little bit more about that workstation, keep an eye out for my talk at RubyConf because I’m going to be talking about that. So those are my picks. Avdi, are you back?

I’m back.

Alright. What are your picks?

My picks. Let’s see. Okay, first of all, this is going to be a pick that I think probably a maximum of one person or maybe zero people will find useful. But gosh darn it, it’s useful to me. So I’m going to talk about it. I use Sony Vegas Pro for my video editing for Ruby Tapas. And I recently came across an extension to it called Vegasaur which is basically just a huge collection of automations and extra tools. And I swear, just one of the automations in there was worth the $100 I spent on the whole package. A lot of it’s focused on getting things done faster. And of course, with my production schedule on Ruby Tapas, every tiny little tweak that I can make to the workflow to make things a little bit faster is a huge deal. So on the off change that there’s anyone out there that uses Sony Vegas Pro, get Vegasaur. It’s amazing. Here’s one with a little bit wider usefulness. Every now and then I have to, somebody sends me a form in email that they want me to sign and send back to them. Or in worse cases, they want me to fax a signed form somewhere. And this doesn’t happen very often, but when it does it’s always a huge pain. Except now it isn’t because I started using HelloSign and HelloFax for those. And they take all the pain out of it. I almost look forward to people sending me forms to sign now. because if you use the HelloSign Gmail extension, you can basically just click on the link that it adds in the email to sign the document and send it back to them, just completely in the browser. It’s fantastic. And the same for HelloFax. And I actually feel bad that I don’t use them enough to go over their free limits. Because I feel bad that I’m not sending them any money. One more. I know we’ve talked about, I know people have picked LastPass in the past on the show. But they just rolled out a huge UI upgrade across both their browser version and their Android version and I assume their other mobile versions as well. I’ve been using LastPass for a few years to organize my passwords and keep them all secure and make sure that I use different passwords for every different service and stuff like that. And the one major complaint that everybody has about them, they do everything that they do very well and they’re very secure but the UI has just been an epic train wreck from day one. And they have finally just rolled out this massive update that really makes it into a clean UI, at least from what I’ve seen so far, both mobile and web. So if you shied away from LastPass in the past because it was such a UI mess, give it another look.

Awesome. Alright, well that’s pretty much the show. I just want to mention our silver sponsor and that’s Elixir Sips. So if you’re interested in learning Elixir, you can go watch those videos. It is a paid service. But go and support somebody that’s out there putting out good content for people who are interested in a particular technology.

Yeah, it’s good stuff.

Yup. And with that, we’ll wrap up and we’ll catch you all next week.