218. Deep Practice & Becoming a better developer

Welcome back to The Rabbit Hole podcast! This week we’re diving into the subject of deep practice and how to become a better developer. Dave and Michael reflect on how learning to play a musical instrument taught them important lessons about intentional practice and how they’ve applied those lessons to coding. Hear how test-driven development and pair programming can be effective methods for intentional practice, and how you can pick up valuable lessons by actively observing peers and reading code. There are also opportunities for small, everyday exercises that can improve your coding on programs like LeetCode and Exercism. Tune in today as we discuss deep practice, The Matrix, mindful learning, and plenty more!

Key Points From This Episode:

  • Introducing today’s topic on deep practice and becoming a better developer.
  • How deep practice is defined in The Talent Code by Daniel Coyle.
  • The ways that playing a musical instrument can teach you to practice intentionally.
  • Why it’s valuable to break up your learning into smaller, manageable pieces.
  • Examples of how to do intentional deep practice as a developer.
  • How you can use test-driven development to become a better coder.
  • Pair programming and how it can be used for deep practice.
  • Why it takes a certain amount of skill and experience to make a good pairing that you can each benefit from.
  • How you can use observation to learn better habits.
  • Small exercises you can do to improve your coding on programs like LeetCode and Exercism.
  • And much more!


{{addCallout()}}

Transcript for Episode 218. Deep Practice & Becoming a better developer

[INTRODUCTION]

[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m your host, Michael Nunez. Our co-host today.

[0:00:09.3] DA: Dave Anderson. 

[0:00:11.0] MN: Today, we’ll be talking about deep practice and becoming a better developer.

[0:00:16.7] DA: Wait, you're saying I have to work in order to become a better developer? You can’t just buy a course or download it into my brain like in the Matrix?

[0:00:28.9] MN: Like in the Matrix. “I know kung fu” If it was only that way, I think I would take the time to learn, there’s some programming languages I feel like are more difficult to learn and understand than others or that I would not want to be caught learning them. The angular one comes to mind, this seems like old news, right?

[0:00:49.7] DA: You're not going to do practice angular one.

[0:00:52.6] MN: I feel like I would be in pain if I had to do angular one. I don’t know why. I’ve actually never seen angular one code to know that I will dislike it or not but I wish I can do some kung fu Matrix downloading of that programming language itself.

[0:01:08.8] DA: Yeah, I mean, I think that speaks to motivation, which is like a really important part of practicing something or being intentional about learning. You picture yourself at the end of it all, at the top of the mountain and you're like, “No, I don’t want to be on an angular mountain, please get me away from the angular mountain.”

[0:01:28.9] MN: Just crush an angular one code, that with the super hero cape behind me.

[0:01:34.3] DA: I’d rather, we would rather be on server rendered template mountain than you know –

[0:01:40.4] MN: AWS, land to function mountain, that would be great. That’s a great mountain.

[0:01:44.2] DA: That’s a great mountain, yeah.

[0:01:45.6] MN: I’ll be in the clouds.

[0:01:46.7] DA: You're on top of it.

[0:01:47.6] MN: Above the cloud. All right, you pointed out something, it’s like motivation is one thing, I guess, one aspect of deep learning. What is – before we continue on, rather deep learning, what is deep practice, Dave? 

[0:02:04.2] DA: Yeah, I just finished reading a book, the talent code and it’s not specifically about becoming better developer but they did talk a lot about this idea of deep practice and how it relates to different things and it got me thinking, I don’t remember practicing to be a better developer but I’m pretty sure that I did at some point. Anyway, deep practice. It’s this idea that you’re going to practice intentionally so you’re going to examine the errors that you're making, diagnosing them and iterating on the approaches. You're going to try again and fail again but fail better.

[0:02:46.5] MN: Fail better, yes. I remember vaguely, it was many moons ago but I do remember vaguely learning how to program, the first programming language and I think that sums it up, you just failed better than the last time. You continued to do so.

[0:03:03.0] DA: Right. Well, I mean, you're just always hitting those weird error messages and you have to learn what those errors mean in order to get it. It’s like, “Okay, I’m just missing a bracket somewhere” which I think the system could be better. I know that there’s like work and even programming languages like Python to give you better signals to tell you, “Oh this is the line that’s missing” or what the exact issue is but yeah, you’re going to fail but then, you’ll figure it out and keep going and if you put in 10,000 hours, maybe you’ll be an expert, that’s some kind of study backing that up. If you put in the time then you will become better but it does have to be good practice, you can’t have the same hour of experience over and over again, you have to be like, very invested in it and intentional.

[0:04:00.4] MN: Right, a quick Google of how many hours in a work year led me to 20, 80 hours a year. You’d have to do five years approximately, five years of working experience. I imagine hopefully this calculator allots for vacation, right? Because that would be miserable if you do that. Monday through Friday, nine to five, coding all day for five years will be really difficult, then, about five years, I think that sounds right though. I think you got the sense of your bearings on programming and the study sounds and feels correct, I always think about practice, very strangely enough, I always think of practice in this example when you brought it up, Dave, of deep practice to music.

I used to play music way before I started learning how to program but I remember practicing playing the trumpet, the sweat and the amount of hours that were spent to learn certain aspects of music and this reminds me of that like the idea of deep practice.

[0:05:12.0] DA: Yeah, I remember bad practice for me. For me, I remember being in school and playing an instrument and just really wasting my time, you’re not practicing or not practicing the right way and it wasn’t until I had a friend that was playing music with that I feel like they showed me the light and it was like, “Oh okay, this is a way that you can practice intentionally” and oh my god, it was like, such a superpower just thinking about how to do it.

[0:05:47.3] MN: Right, any trumpet player out there probably knows about the Arban’s book. That was like the book if you read it from beginning to end, you will become a master.

[0:05:57.7] DA: Not the Arby’s book.

[0:05:58.5] MN: Not the Arby’s, the Arban’s. I think it was Arban. It just had all sorts of exercises to help you become a better trumpet, musician with many different little exercises, not actual music, it’s just like, these little exercises that are important for a contemporary trumpet player. Literally, if you’re in any – if you just play music, you would appreciate that book, any horned instrument, I imagined.

It was a lot of you take a piece of a thing that you're trying to work on, you slow it down, you slowly do the thing and you fail, you fail better, you get a little bit better at it, you speed up the tempo and that you do that and then kind of resembles the same way that one may learn how to become a better developer.

[0:06:50.4] DA: Yeah. I feel like, when you’re practicing like that, you can kind of feel it in your brain, you feel your brain kind of connecting itself more or its’ an exertion. You’re paying a lot of attention and you’re very focused and alert and when you're not practicing like that, it’s like disengaged or just kind of bumbling through it and yeah, I feel like there’s a big difference.

[0:07:21.5] MN: Yeah, I mean, one thing that I’ve noticed from music practising and programming practising is for some strange reason, if I don’t learn a programming concept fast enough, pull on call fast enough, I get frustrated and don’t do that people. Don’t get frustrated, programming is very hard and you don’t want to get yourself caught up in the frustration because you’re not understanding a concept. If you're being frustrated about something, you probably need a break. Definitely do that for sure.

[0:07:52.9] DA: Sounds good, yeah.

[0:07:54.4] MN: I tend to do that and I realize that I’m like, “Oh man, why am I not understanding React hooks? What the hell?” Then I’m like, “You know what? Maybe I need to go get a glass of water, be right back, watch the video over again, do it.”

[0:08:10.8] DA: Yeah, I mean, that’s like part of it too, maybe you're doing too much in one go, maybe there’s a smaller way you can chunk it up. You could look at maybe you’re trying to test how to do a React hook while you're learning how React hook works and that can be like two different things that you separately breakup and practice individually or you could try to look at it a different way and step away from the video that you're on loop and read code examples or see how other people have done it in your code base and trying to find what good looks like.

[0:08:55.9] MN: Right, I think the idea of chopping it up into smaller sections and then acknowledging, “Hey, I learned this small thing” and then the next small thing as you slowly progressed in your learning of a new language or a new framework is probably helpful.

[0:09:15.7] DA: Yeah, then when you take your break just imagine yourself on top of hooks and it’s like, look at Bobby.

[0:09:23.1] MN: Look at me.

[0:09:23.5] DA: Look at Bobby, he’s getting his hooks out and – 

[0:09:26.7] MN: I’m standing on the hooks, I got a backpack full of them, ready to climb the next mile with all these hooks and I guess, that’s the React mountain, right? If you slowly – if that is the peak React developer, you learn the smaller bits of React, that’s just one small mountain to the next one, to the next one, to the next one. I need to start imagining myself in mountains, I would never be at a top of an actual mountain but React Hook mountains, I think I should be.

[0:09:55.2] DA: I feel like, didn’t we go on top of Bear Mountain?

[0:09:58.3] MN: Yeah, I actually did. My god, I fell on my ass so many times on the way down, yes.

[0:10:04.1] DA: Always raining so bad, yeah, that was inadvisable without the right footwear I guess.

[0:10:10.1] MN: Yes. Make sure you’re wearing the right gear, you're learning the right things as you climb up those mountains and whether it’s learning or actual bear mountains.

[0:10:22.0] DA: Yeah, what are some other ways that we can intentionally practice with being a developer?

[0:10:31.2] MN: I mean, the first thing that came into mind was TDD, right? I think the – if an individual is new to test driven development, it can be really frustrating, right? It can be like, “Where do I start? How do I begin and I want to be able to write clean code?” and understand that I have something that’s going to support my application.

The idea of getting a test failure red and getting it to green, I feel like that is motivation that you get like, “Hey, I wrote this thing and it failed and I’m writing a thing to make a pass and then I’m going to write another test that further implements this piece of application that will be covered by software” is probably the motivator too. 

[0:11:17.2] DA: Yeah and also when you get a down like the bootstrapping of learning 2D is a separate thing but once you have a baseline of 2D, that can help you practice any number of things because you’re chunking it up into small steps of developing. You are ratcheting up going through making each of the tests pass and seeing what errors are there, what’s failing, how it’s failing and you know, iterating on that. 

[0:11:50.3] MN: Right and even the different types of testing is going to give the developer different scales to learn, right? You can – you may have an understanding on our spec and being able to write test for your Rails application but then you got Capybara, right? That is my current mountain that I’m climbing right now. It’s like, “Oh, I don’t write as much Capybara test but I want to write them good” right? 

[0:12:17.1] DA: Right. 

[0:12:17.6] MN: I want to make sure they’re good, that they are understandable for the next developer and that it makes sense, right? I don’t want to have to wait ten seconds for a dumb element to be found. How do I make it programmatical so that it knows when this appears? Then you continue on with the code and you know, I broke it down to small chunks. I’m planning, I’m climbing multiple mountains Dave. 

Right now, it’s Capybara and the React hooks and all these stuff but you know, I find myself a little cheat sheet and I am regulating down to small pieces, you know reading them one at a time, understanding what they do and then writing them in my little developer diary that I have that says, “Hey, I wrote this thing.” I think also tracking what you are and what you’ve learned is also pretty cool too. 

[0:13:02.0] DA: Right, I mean as I kind of like reflecting and doing it in your high a little bit, I definitely have done that as well where we’re like you just kind of read code and you look at the context of how all these things fit together especially when you’re starting a new codebase, you can learn a lot by reading code and critiquing it and being, “Okay, is this good? Is this bad? What do people like and how does it all fit together?” and I think another way to practice it as well if you have a very large codebase, you could try to change it like just to refactor it for the heck of it. 

I think sometimes people are like, “Oh, I need to have some kind of permission to change things or modify things” but it’s freeing when you realize that you actually have all these code and you could just change it and you don’t have to push it to a branch or commit anything or do whatever. It’s here and it is completely malleable and we can just revert it with Git or what have you and just by kind of opening yourself up to try weird things, it can be a great form of practice. 

[0:14:19.8] MN: Yeah, especially if you are refactoring code that you didn’t write, so you try to figure out different ways to ensure that the business requirements don’t change as well as try to make it clean for the next person. I think it’s a great idea and as you mentioned, at the end of the day you can always get reset or get revert, boom, call it a day or stash it if you want to keep it for later. I don’t have to look at your code later, you can do that as well. 

[0:14:49.7] DA: Yeah, keep it on the fridge. Yeah and I find it helpful too when you are doing this kind of exploration and digging around the code, you could draw a picture, see how the different pieces of the code put together from either like an architecture perspective, like all the different services or all the different modules or the classes or the methods or the domain objects. Just looking at it from different perspectives and I think that can help too with thinking about different kinds of ways you might try to pull apart the code and mess around with it a little bit. 

[0:15:29.0] MN: The next way to practice deeply I feel with being a developer is pair programming. I think XP was on to something as a methodology when it came to learning and practice deeply because you are pairing with someone else, you are going to be more focused on the task at hand with your peer as you are trying to solve a problem. 

[0:15:55.4] DA: Yeah, that’s an interesting point and if you have a good pair, which I mean pairing is its own skill that needs practice as well just like TBB, so like a separate topic about how to practice being a good driver, navigator and things like that but if someone is navigating well, then they can send you a lot of good coaching signals like they can give you the space that you need to make a mistake or understand it on your own but then read the room and give you a nudge in the right direction to unblock you more quickly or remind you about what you’re trying to practice or what your objective is or what kind of best practices you are trying to do like should you write a test now? Maybe you should start with the test and then it will be a little bit easier to think about. 

[0:16:54.9] MN: Right and even when the roles are reversed, you still get the opportunity to see how that person does the role in their own way and you get to learn and pick up habits from your pair. I think what you mentioned before day back when you were learning music, it wasn’t until someone showed you the light, right? In which you felt like you started to learn and practice better. I feel like that is the same way when you pair with someone else. 

You get to see all the good habits that this person might have and be able to use that, put that into your own toolbox and be able to learn [inaudible 0:17:29.3]

[0:17:29.3] DA: Yeah totally, and there are a lot of little things about people’s workflow that you can pick up and observe and be like, “Oh wait, how did you do that? Let me try to replicate that next time” so observing, kind of imitating and on that topic of learning your editor, you can setup your environment when you are not pairing to nudge you in the right direction. There are plugins you can have for reminding you these keyboard shortcuts when you don’t use them.

That is a kind of a nice little nudge for practicing and kind of achieving automicity or just complete muscle memory, where you don’t have to think about it and getting to the level of an Olympic athlete of writing code where you just internalized all of the mundane things and you’re just doing backflips. 

[0:18:30.7] MN: All day. I think I’ve gotten the most deep practising of my editor when I pair with individuals because then they also have their own keyboard shortcuts, they can teach you different keyboard shortcuts too. I think it is a great opportunity to get those pieces of knowledge from an editor when you’re pairing but learning your editor makes your life easier and practicing on how to use your editor to the best of your ability is important so that you can do those backflips. 

[0:19:04.5] DA: Right. 

[0:19:05.4] MN: You know, one may think that if you’re looking at code every day that you don’t want to look at code at other times of the day but I do find myself looking at little coding exercises like LeetCode and Exercism. I always think that they’re just really fun bite-size code problems that I can solve and that is a way for me to practice deeply on the skill that I want to get better at, which is just programming in general. 

Sometimes I could choose a different language I’m not too familiar with to see how I would do it in that programming language but LeetCode, there’s a couple of other ones out there I’m sure other people use but that is definitely a way to help out to do some exercise, to do some pushups and some deadlifts of coding. 

[0:19:55.8] DA: Yeah, I’ve used Exercism and that’s pretty good. There is a lot of different programming languages like I kind of have my set schedule for learning a new language where it’s like, “Okay, I’m going to look at the syntax on learn X and Y and then I’m going to do some exercises” and read the docs as I go through that and you know, learn how to test and all of that. 

[0:20:21.0] MN: Yeah and I think it helps at the end of the day because you could then take that skill or that little nugget of information and then apply it to your actual workplace and whatever code that you’re working on but deep learning, I think I will be a little bit more mindful when I’m at a problem and understand that it is an opportunity to learn and so I will do my best that when that opportunity comes, I will deeply learn and deeply practice the thing because we can’t download information like the matrix. 

Not yet, I mean eventually we might be able to. I don’t know when though. If you have to give a year Dave, when would that time come? Do you think so? You got a year in mind? 

[0:21:07.5] DA: I don’t know. I think the singularity is approaching but I don’t know, maybe it’s all hype. 

[0:21:15.7] MN: For now, we’ll have to deeply practice the things we want to learn, ensure that you’re doing it in a comfortable and the correct way possible so that you could continue the things that you want to do. 

[END OF INTERVIEW]

[0:21:27.5] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.

[END]

Links and Resources:

The Talent Code: Greatness Isn't Born. It's Grown. Here's How.

LeetCode

Exercism

The Rabbit Hole on Twitter