How to Handle the Practice Exercises

(Inspired by Jun tsuru, one of my readers.)

Q: help! I’m getting my butt kicked by the practice problems in Learn to Code by Solving Problems. What do I do?

A: first, you’re doing the right thing trying the practice problems. Reading alone is not enough.

Second, repeat this to yourself three times: it is normal to struggle on practice problems. This struggle means that there is an opportunity for learning.

To make use of this opportunity for learning, though, you need a plan for how to allocate your time when solving problems. Here are some tips.

• Try not to give up too soon. Have you tried debugging your solution? If your approach has flaws that cannot be remedied, have you considered other possible approaches? Have you taken breaks? Eaten some saltines? Tried continuing the next day?
• At the same time, try not to give up your current approach too late! There’s not much point in staring at a problem for hours or days if you’re no longer making progress. Once you’ve exhausted all of your ideas (or patience, or interest), take a look at my sample solution for the problem. … but don’t look at the entire thing. Look at enough to get an idea for something new to try. Then work on your code again. If you’re still stuck, peek again at the sample solution, and so on.
• Have you re-read the problem description? Do you understand the sample inputs and outputs? No, really. Problems have a lot of detail. It’s easy to miss something, or to misinterpret something and solve a version of the problem that’s different than what’s expected.
• Struggling to solve a problem may feel demotivating. Just remember that this is time well spent, and that you’re learning to be a better programmer.
• Struggling on these problems does not mean that you can’t learn this, or that you aren’t smart enough. You can do this! Programming is hard. Ask questions. Take your time. Think about it: you’re being asked to transfer what you learn in the chapter to entirely new problems and contexts. You’re not just tweaking something here and there – you’re solving something wholly new. This is exciting and also challenging!
• Try to apply the patterns from the chapter problems to the problem that you’re currently solving. For example, in Chapter 2, should you be using ifs or elifs? In Chapter 3, should you be using a for loop or a range for loop?
• Sometimes, reading the input can be a challenge in itself! Try to establish whether you need to read the input above a loop or in a loop. Are you reading from standard input or a file, as required by the problem? Reading the input is often a good first step toward solving the full problem.
• Is something in the book or problem confusing? Trust me, it’s not you. Maybe my explanation or code just isn’t clicking for you. That’s OK! By all means, please please ask online, ask people you know – sometimes it just takes another’s explanation for the whole thing to click. (And if you have a super helpful way of explaining something, would you please share? I promise to use it for good.) I have made the mistake before of slogging through a resource that just wasn’t working for me, simply because it was the one that others recommended. This is not a good feeling. “Why can’t I do this?” “How am I supposed to get anywhere if I can’t get through this thing that everyone else seems to be learning from?” And why? We should be learning in the way that we need to learn, not in the way that others expect us to learn.
• This book is not easy. I’m going for deep, lasting, conceptual understanding here, and that may not always be too comfortable. But many readers who continue to push tell me that the discomfort was worth it and that they can now program confidently. The skills that you learn here, that you grind on and perfect here, will serve you for your whole programming career, whether you make apps, or games, or tools for you and your friends.

Successes may sometimes or often be hard to come by. Celebrate them. Email me and I will celebrate with you.

I also recommend reading this post on Redgreencode about how long to spend on a problem.

Written on February 16th, 2022 by Daniel Zingaro