Haskell and Deliberate Practice

Have you ever been in a situation where you tried learning something, put in the proper time, and ? Chances are you weren’t learning in the best way. But how can you know what constitutes in your field? It can be frustrating to try to find advice for a specific topic on the internet. Most people do not think about the manner in which they learn. They do learn, but they can’t externalize and teach other people what they did, so there aren’t guides for this sort of thing. got stuck good learning how to learn In our on learning, we focused on some higher level learning techniques. The aim of these was to get ourselves more learning time and motivation. But even if your macro-techniques are good, you ultimately need domain specific practice. The in this series showed one specific technique for learning Haskell. It’s a start, but I still want to share some more general ideas. first article second article This article will go over a couple more key ideas from by Josh Waitzkin. The first concept we’ll talk about is the idea of . The goal of deliberate practice is to zero in on a specific idea and try to improve a certain skill until it become subconscious. The second concept is the role of mistakes in learning any new skill. We’ll use these to propel ourselves forward and prevent ourselves from tripping over the same ideas in the future. The Art of Learning deliberate practice Deliberate Practice Suppose for a moment you’re learning to play a particular piece of music on the piano (or any instrument). The biggest temptation out there is to “learn” the piece by repeatedly playing it from . You’ll get a fair amount right, and you’ll get a fair amount wrong. Eventually, you’ll get most of it right. This is a tempting method of practice for a few different reasons: start to finish It’s the “obvious” choice. It let’s us do the parts we already enjoy and are good at, which feels good. It is, after all, most like what we’ll actually end up doing in a performance. However, it’s a suboptimal method from a learning perspective. If you want to improve your ability to play the piece from start to finish, you should focus on your weakest areas. You have to find the specific passages that you are struggling with. Once you’ve determined those, you can break them down even further. You can find specific measures or even notes that you have difficulty with. You should practice these weaknesses over and over again, fixing one small thing at a time. At a certain point, you’ll need to go all the way through, but this should wait until you’re confident on all your weak spots. The is the most important part. You can’t take a tricky passage you know nothing about and play it perfectly from start to finish. You might start with one section that forces you make a quick hand movement. You might practice a dozen times just focusing on getting the last note and then moving your hand. Nothing else is important for these dozen repetitions. Once you’ve made the hand movement subconscious, you can move onto another idea. The next step might be to make sure you hit the first three notes after the hand movement. focus on small things This sums up the idea of deliberate practice. We focus on one thing at a time, and practice that one thing deliberately. Mindless practice, or practice for the sake of practice will only give us slow progress. It may even impede our progress if we build up bad habits. We can apply it to any skill out there, including coding. We want to build up tiny habits that will gradually make us better. Mistakes So deliberate practice is a system of building up skills that we want. However, there are also plenty of habits we . We do many things that we realize later are errors. And the worst thing is when we realize we’ve made the over and over again! don’t want same error Waitzkin notes in , “If a student of any disciple could avoid ever repeating the same mistake twice, they would skyrocket to the top of their field.” We could also do this if we avoid mistakes entirely, but this isn’t possible. We’ll always make mistakes the first time we try something. Art of Learning So first we have to embrace the . Once we’ve done this, we can have a plan for dealing with them. We won’t be able to avoid ever repeating mistakes, but we can take steps that will reduce the rate at which we do. And if we’re able to do this, we’ll see major improvement. Our solution will ultimately be to keep a record of the mistakes we make. By writing things, down, we’ll dramatically reduce the repetition of errors. certainty that mistakes will happen Practicing Haskell So now we need to step back into the land of coding and ask ourselves how we can apply these ideas to Haskell. What of our coding practices can we focus on? Let’s start with a couple lessons from . specific areas Compile Driven Learning You could write an application, and focus on nothing but building the following habit: before you write a function, stub it out as undefined and make sure the type signature compiles. It doesn’t matter if you do anything else right! After you’ve gotten into that habit, you could also take another step. You could make sure you always write the function’s invocation (where your other code calls the function) before you implement it. I’ve chosen these examples because there are two things that slow us the most when writing functions. The first is a because we don’t know exactly how our code will use the function. The second is the when we realize we need to re-write the function. This can happen because there was an extra type we didn’t account for or something like that. These habits are designed to get you to plan more up front so that your life is simpler when it comes to implementation. lack of clarity repetition of work Here are a couple of other ideas in a similar vein: Before writing a function, write a comment describing that function. Before you use expressions from a library, add it to your .cabal file. Then, write the import statement to make sure you are using the right dependency. Another great practice is to know how you will test a piece of functionality before you implement it. In a couple weeks we’ll explore test driven development, where we’ll write test cases for our functions. But if it’s a very simple feature, like getting a line of input and parsing it in some way, you can get away with simpler ideas. You could commit to running your program on the command line with a couple types of input, for instance. As long as you know your approach before you start coding, it counts. It might be most helpful to write the test plan in some document first. So in almost all the above cases, the “trigger” for building this habit is writing a new function. The trigger is the most important part of building a new habit. It is the action that tips your brain off that you should be doing something you’re not accustomed to doing. In this case, the trigger could be writing the for the type signature. Every time you do this, remind yourself of your current goal. :: Here’s an idea with a different trigger. Every time you pick a structure to contain your data (list, sequence, set, map, etc.), brainstorm at least three alternatives. Once you get beyond the basics, you’ll find each structure has its unique strengths. It would be most helpful if you wrote down your reasoning for your final choice. The trigger in this case could be every time you write the keyword. For a more extreme version, the trigger could be writing down the left bracket to start a list. Each time you do this, ask yourself if you could be using a different structure. data Here’s one final possibility. Every time you make a type synonym, ask yourself if you would be better served making a out of it instead. This often leads to better compile time behaviors. You'll likely see clearer error messages, and you'll catch more of your errors at compile time. The trigger here is also simple: any time you type the keyword . newtype type Here’s the most important thing though. ! You want to pick one thing, practice it until it becomes subconscious, and then move on to other things. This is the hardest part about deliberate practice: . The biggest temptation is to move on and try new things often before the good habits are solidified. Once you shift your focus onto other items, you might lose whatever it was you were working on! Remember to treat learning like compound interest! You need to make small investments that stack up over a long period time. You can’t necessarily hurry the process. Don’t try more than one of these at a time maintaining your patience Tracking Mistakes Let’s also consider the various ways we can avoid making the same mistakes in the future. Again, these are different from the “skills” you build up with deliberate practice. They don’t occur much, and you don’t want to “practice” them. You just want to remember how you fixed some issue so you can solve it again if it does come up. You should keep a list in a google doc of all the worst mistakes you’ve encountered in your programming. The google doc should record three things for each mistake. What was the compiler message or runtime behavior? What was the problem with your code? How did you fix it? So for an example, think about a time you were certain your code was correct. You look at the error, then back to your code, then back to the error. And you’re still sure your code is right. Of course, the compiler is (almost) always right. You want to document these so they don’t trip you up again. Other good candidates are those runtime errors where you cannot for the life of you track down where the error even occurred in your code. You’ll want to write down what this experience was like so the next time it happens, you’ll be able to fix it quickly. By writing about it, you’ll also motivate yourself to avoid it as well. Then there are also dumb mistakes that you should record because it’ll teach you the right way faster. Like when you’re starting out you might use the operator to try to append two strings instead of the operator. By writing down errors like this, you'll learn quirky language features much faster. (+) (++) One final group of things you should track down is awesome solutions. Not just bug fixes, but solutions to your central programming problems. For instance, you found your program was too slow, but you used a better data structure to improve it. Not only does it feel good to write about things that went well, you’ll have a record of what you did. That way, you’ll be able to apply it next time as well. These kinds of items (both the good and the bad) make good fodder for technical interviews. Interviewers are often keen to see what kinds of challenges you’ve overcome to show your growth potential as an engineer. I have one example that demonstrates the good and bad of recording mistakes. I had a nasty bug when I was trying to build my Haskell project using Cabal. I remember it being a linker error that didn’t point to any particular file. I did a good job in making a mental note that the solution was to add something to the “.cabal” file. But I didn’t write down the full context or full solution. So in the future, I’ll see a linker error and know I have to do something in the “.cabal” file, but I won’t be sure exactly what. So I’ll still be more likely to repeat this error than I would if I had written down the full resolution. Summary It’s an oft-repeated mantra that practice makes perfect. But as anyone who’s mastered a skill can tell you, only . Bad or mindless practice will leave you stuck. Or worse, it will ingrain poor habits that will take more time to undo. Deliberate practice is the process of solidifying knowledge by building up tiny habits. You pick one thing to focus on, and ignore everything else. Then you learn that focus until it has become subconscious. Only then do you move on to learning other things. This approach requires a great deal of patience. good practice makes perfect One final thing we have to understand about learning is the need to embrace the possibility that we will make mistakes. Once we have done this, we can make a plan for recording those mistakes. This way, we can learn from them and not repeat them. This will dramatically improve our pace of development. If you want start out on your journey of deliberate practice, you should download our ! In addition to some content on recursion, it contains 10 practice problems. The answer start from so you can build up your solutions step-by-step. It's a great way to learn deliberate practice ideas! Recursion Workbook undefined If you’ve never written a line of Haskell before, don’t be afraid! You should check out our . It will walk you through installing Haskell and give you some helpful tools for starting on your Haskell journey! Getting Started Checklist is how hackers start their afternoons. We’re a part of the family. We are now and happy to opportunities. Hacker Noon @AMI accepting submissions discuss advertising & sponsorship To learn more, , , or simply, read our about page like/message us on Facebook tweet/DM @HackerNoon. If you enjoyed this story, we recommend reading our and . Until next time, don’t take the realities of the world for granted! latest tech stories trending tech stories