You're about to solve a programming exercise. You want to maximize your learning while also enjoying yourself. How should you go about this?
Over the years, I've received many emails from folks asking me how I recommend approaching Python Morsels exercises. Here's the advice I usually give.
This advice is relevant for coding exercises in any programming language and on any platform. In fact, most of this advice is relevant for solving programming tasks more generally.
Start by outlining your approach in a docstring or a comment. Be detailed, but use rough descriptions and pseudocode. You'll likely find yourself rereading the problem statement multiple times as you outline your approach.
For a challenging problem where you're likely to get stuck, time-box your outlining time. For example, set a timer for 15 minutes and then start outlining. When the timer goes off, walk away.
Walking away will let your brain work on the problem in the background. This will decrease the stress of getting stuck on a problem and allow your brain to be more creative because you're now unencumbered by the need to solve the problem quickly.
Ideally, after outlining the problem you might take a shower, make yourself a meal, or go for a walk. If you can, try to perform an activity that doesn't require intent focus, so your brain can wander.
When you walk away from an exercise before it's complete, you're likely to keep pondering it. You might realize your approach has a flaw or you might think of a completely different approach. The next time you sit down to solve your programming exercise, you'll likely find that you're a bit more eager to jump in than you would have if you'd kept coding right after outlining.
Ready to sit down and write some code? Great!
Before you begin coding, set another timer for between 25 minutes and 50 minutes (the exact interval is up to you). You'll attempt to solve the exercise during that block of time and then stop and walk away again for at least a few minutes.
Our brains have at least two modes: one where we're focused deeply on a problem and one where our mind is wandering. Barbara Oakley calls these focused mode and diffuse mode, though you could think of them as flow and mind-wandering if you prefer.
Focused mode involves focusing our full attention on one task. This mode is great for complex tasks that require deep concentration, such as turning the description of a process into working Python code.
Diffuse mode involves letting your mind wander. This mode is less productive, but much more creative. This mode allows your brain to step back, process, and critique your approach (that's why we walk away after outlining our approach). This is also great for seeking new approaches when you've found yourself stuck.
Setting a timer will trick your brain into focusing. If you tell yourself you only need to focus for 30 minutes and you know your timer will release you from focus, you'll try to make the best possible use of that time. Releasing yourself from focus after your timer dings will also force your brain to re-evaluate your approach before you get back to work.
Multi-tasking is a lie; the human brain is incapable of true multi-tasking.
Our brains are like a GIL-locked Python process that's bound to a single CPU. Though our brains are even less effective at context switching between threads than Python is! This is why it's so important to focus your attention when solving a new problem. Otherwise, you may end up spending far more time than you need to.
Interruptions are antithetical to focus. For the duration of your 25 to 50 minutes of timed focus, mute all notifications (yes, on your phone and on your computer). Beyond notification muting, do whatever you can to make your environment less distraction-prone. Close the door to the room, put headphones on with pink noise playing, tape a "do not disturb until 10:30am" sign to your desk, or do whatever small thing you can think of to reduce the likelihood of interruption.
Of course, at some point you may be interrupted. When you are interrupted, first say outloud "give me a moment", so the person doing the interrupting (hopefully it's a person and not a fire alarm) will understand that they'll have your attention very soon. Then spend 5 to 15 seconds to write a comment that notes the next steps you were about to take.
Pro tip: While time-boxing and removing distractions are great for solving programming exercises, they're also great for entering a flow state for the purpose of studying at school or getting difficult tasks done at work.
If you know any writers, I'm sure you've heard the phrase "write now, edit later". Through writing sprints, word counters, and events like NaNoWriMo, the writing world prioritizes writing without editing. The same principle can apply just as well to programming.
Your mantra while in a focused state of coding should be "write now, refactor later". While you do eventually want a readable solution, focus on getting to a working solution first.
Pretty sure a messy series of
else statements would work, even though it's not elegant?
Write that sloppy code first!
You can refactor later.
Elegant code is great, but working code is better. Write now, refactor later.
While solving programming exercises you'll sometimes find yourself stuck. Getting stuck often feels discouraging in the moment, but if you're never getting stuck, you aren't learning.
Once you're stuck, what should you do? If you have another part of the problem you could focus on while you're stuck, switch your focus for a bit. But if you've hit a wall and there's nothing else to switch to, take a 3 minute stretch break. During your break, observe the sensations in your body and observing your surroundings, but try not to focus on anything in particular. Sometimes releasing your focus will allow for a bit more creativity and you may find a "eureka" moment.
What if you find yourself stuck, you take a break, and then you find that you're still stuck? At this point, give up.
Just kidding. Don't completely give up. Do what you do at work to get unstuck: seek help!
We don't learn by putting information into our heads; we learn by trying to retrieve information from our heads. When you're struggling, that means your brain is hard at work trying to remember bits of information and synthesize that information into a working solution. So effective learning time sometimes feels frustrating in the moment.
Hopefully that frustration culminates in a moment of insight and a working solution. But sometimes it won't. What then? Well, what would you do if you hit a roadblock while writing some code at work? You'd look something up online or you'd ask a coworker for help!
You shouldn't cheat yourself out of a moment of insight, so you should let yourself simmer for at least a few minutes while your brain seeks a solution. Change your focus or take a quick break if you need to, but don't immediately give up. However, you may eventually need to seek outside help. Occasionally there's a missing piece or two that either isn't in your head or your brain just can't seem to retrieve it. After you've done a bit of floundering, seek help!
Search the web, ask a question of Chat GPT, look at a hint (if your exercise system has them), or ask a colleague for advice. If this feels like cheating, remember why you're doing any of this. You likely want to learn something new, possibly while having fun. Being stuck isn't fun and it's not very helpful for learning.
So don't immediately give up, but don't get hung up. You don't want to cheat yourself out of an "ah-ha" moment but you also don't want to waste your time.
Some coding exercise platforms allow you to see many solutions to the same problem and some even include a solution walk-through with detailed explanations and comparisons of each solution. Be sure to use these features to reflect on your work.
While reviewing different solutions to a programming exercise, you might learn something new. I say "you might learn something new", but that's a bit of a misnomer. We don't learn through information exposure; we learn through information recall.
If you wish you'd solved the exercise a different way, or even if you wish you'd reached your solution more easily, set aside time in the future to solve that exercise again. Give yourself some time to forget the solution to the exercise, preferably at least a day. Then try it again.
If after a second attempt you find that you're still not quite satisfied with your performance, give yourself even more time to forget and then try a third time. Repeat as needed. You might think it silly to solve the same exact exercise again. But this is the way learning happens!
Deep learning rarely comes from attempting something just once. So be sure to revisit interesting exercises again and again!
How do you climb a mountain? One step at a time.
Keep in mind your reason for solving programming exercises. Sure, you'd like to have fun, but I bet you'd like to learn something too.
If you didn't solve an exercise elegantly, need to use more hints than you'd like, or you revealed the solutions without solving the exercise yourself, that's okay! Try to focus on the process of learning, not the product of your learning time. The results will come, but gradually.
Just as you can't see the growth of your hair or nails day-by-day, you won't feel your progress each day. But if you reflect on your growth over time, your progress will be very noticeable.
Need to fill-in gaps in your Python skills?
Sign up for my Python newsletter where I share one of my favorite Python tips every week.
Need to fill-in gaps in your Python skills? I send weekly emails designed to do just that.