Many programmers are given the same advice: solve as many problems as possible. It’s true that solving new problems can help you gain experience and enhance your knowledge. I, too, seek out new problems and projects.
But I’ve found it equally important to recycle problems: repeating them multiple times, each time with a different intent. There’s a lot to gain from repetition with a purpose.
Just because I’ve solved a problem once doesn’t always mean I can solve it again.
I was in the library the other day, working on a problem I’d completed earlier in the week, when I got stuck. In a matter of days, I’d forgotten how to solve the problem. Instead of breezing through the exercise, I found myself struggling: working through error after error.
The experience showed me that I need to work more on conditionals and functions. Similar situations have happened before, which is why recycling problems matters: it tests my knowledge and reveals my trouble spots.
Resolving problems also reinforces concepts. It’s great that I can solve a problem that uses classes when I’m studying them and when the material is fresh in my mind. But can I recall how to use classes a week or two later? Taking a second pass at a problem is a way to find out.
Adding self-imposed constraints is a second way I recycle programming problems. For instance, I recently used a for loop to solve a problem involving pangrams. On my second time through, I gave myself a simple constraint: solve the problem again without a for loop. In other words, I had to try another approach.
So I tried using a set, and my resulting program became cleaner and more readable. Then, I took it one step further with another constraint: solve the problem with another variation of a set. In total, I reduced the amount of code for this program by more than 50%. And I learned a lot about sets in the process!
Other times constraints end up complicating my code. In one recycled problem I gave myself the constraint to use a while loop, and the program became long and complex; the for loop I had used on a previous iteration was a better option. Even still, repeating a problem with a constraint helped me understand when it’s advantageous to use one approach over another.
Despite the result, repeating a problem with constraints gets me outside my comfort zone and makes me think in new and creative ways. I usually get stuck and have to do some research. In the process, I pick up details I’d overlooked and learn new ways of doing things.
I’m on my third time through the dozens of problems in Brian Hogan’s book Exercises for Programmers. I’ve had a different intent for each iteration. This time through I’m practicing writing my own tests.
This is how it works: I pick a problem at random from Hogan’s book and solve it. I organize the program into separate files; each file is responsible for a different part of the solution. Then, I write the tests. Ultimately I want to write the tests first, then write the code, but I’m not quite there yet. Meanwhile, though, I’m getting a lot of practice writing and extracting functions and importing files.
There’s a broader point to purposeful repetition: it helps me see patterns and solidify them in my mind, so I can use them as mental models for new problems. That’s the advice George Polya gives in his book How to Solve It. When tackling a new problem, he recommends to “seek contacts with your formerly acquired knowledge.” He goes on:
“Try to think of what helped you in similar situations in the past. Try to recognize something familiar in what you examine, try to perceive something useful in what you recognize.”
He’s right. I recently completed a problem where I had to identify anagrams. Before I typed a line of code, I recalled a similar anagram problem I’d solved a few weeks prior. Although the original problem was much easier than the one at hand, it gave me a place to start.
Recycling problems with a specific intent has been hugely beneficial. It’s solidifying concepts, giving me exposure to new ones, and building a strong foundation of knowledge, and that’s what I’m after as a beginner programmer.
I’m a writer, writing about technology, productivity, and art (amymhaddad.com), and a beginner programmer.