How to Get Better at Solving Programming Problems

Most of us have been given the same advice: to become a better problem solver, you need to solve more problems. But this advice is too simplistic. Getting good at anything requires more than just reps. Its also how you go about it.

Besides, when programmers hear the advice solve more problems, they often think that more means faster. Its a mistake I made when starting out.

The problem-solving treadmill can be detrimental to learning and improving. Early on Id speed through one problem and head to the next. But the reality of that approach soon set in. By focusing on quantity, I compromised quality and missed key learnings along the way.

Its not to say that repetition doesnt matter; it does. However, repetition alone doesnt get to the heart of the matter. The process does.

I have a vested interest in this topic: I want to get better at solving problems in order to improve as a programmer. So here I offer my plan of attack. It involves reps to be sureand a whole lot more.

1. Solve a Variety of Problems on a Variety of Platforms

I was obsessed with HackerRank when I began learning to code, said an instructor of a Python course I was taking. Although its fine to have a favorite platform, dont limit yourself to a single one. Heres why: you need to be ready for anything.

One goal of mine is to toggle smoothly among different problem types and across different platforms. The problems on Interview Cake are different than those in Reuven Lerners book, Python Workout. Likewise I find the problem statements in Lerners Weekly Python Exercise different from those on HackerRank.

I have my preferences, to be sure. However, I need to be able to solve problems of all types. So Im using a variety of platforms and resources to get practice.

Here are some examples:

• LeetCode
• Interview Cake
• Cracking the Coding Interview by Gayle Laakmann McDowell
• Exercism
• Python Workout by Reuven Lerner
• Weekly Python Exercise by Reuven Lerner

On Sundays, when I make my plan for the week ahead, I select a few problems from the above resources. Im deliberate about it. For example, Ill pick a problem that focuses on binary search from LeetCode. Then, one that focuses on data structures from one of Reuven Lerners sources.

This practice prevents me from getting too comfortable. I cant rely on the same data structure or technique. I need to be able to pick the best tool for the job. Ive got to be able to pivot.

It also challenges me. Thats because I select problems that push me to the edge of my limits, a feature of what psychologist Anders Ericsson calls deliberate practice.

Deliberate practice is all about skill development. Its a fully-focused, conscious effort that takes you out of your comfort zone, centers on a specific goal, and demands near-maximal effort, Ericsson explains in his excellent book, Peak.

In other words, youre not going through the motions doing something that comes easy or natural. The hallmark of . . . deliberate practice, Ericsson writes, is that you try to do something you cannot do.

2. Cross-Train Your Programming Brain

You often hear about athletes who incorporate cross-training into their routine. For example, a runner completes a bike workout or two each week. It makes a lot of sense: by cross-training athletes push their cardiovascular fitness from a different angle.

Cross-training for programmers is a topic Ive written about before. Yet, more needs to be said about the benefits of this approach. Just like an athlete cross-trains to improve their cardiovascular fitness, Im incorporating cross-training to improve my mental fitness.

My cross-training involves solving math problems. I apply the same tactics Id use to solve a programming problem but in mathematics. Same process, different context.

My current math book provides the cross-training benefits mentioned above. But its doing something more: its helping me build my intuition for solving problems.

Thats an important point. I dont want to memorize a math equation or process. I want to intuitively know when to use it. The same is true when solving programming problems.

3. Learn from Your Solutions

All of us get stuck and all of us get errors while problem-solving. We use these failures to help us figure out what to do differently.

Oftentimes thats where the learning stops. Once weve solved the problem were anxious to move along. But dont.

Mathematician Richard Hamming suggests thats when the learning should begin.

I regard the study of successes as being basically more important than the study of failures...there are so many ways of being wrong and so few of being right, studying successes is more efficient, Hamming writes in his book, The Art of Doing Science and Engineering.

This idea of "looking back" and studying your successes is a topic I've written about previously, and it's worth noting again.
You always hear about how we need to "learn from our failures." But Hamming is right: there's so much to learn from our successes.

So one of the biggest changes Ive made to my problem-solving process is putting Hammings words to practice. I vividly recall solving my first problem that involved a linked list, a data structure that was new to me at the time. After I solved the problem, I studied it intently. I copied my solution into a Google Doc file and used comments to explain the code to myself.

I wanted to ensure I clearly understood what I did and why for this critical reason: so I could do it again.

4. Get Feedback

Awareness can be a wonderful teacher.

Dont assume your solutions are great. Find out for yourself by getting feedback. Feedback is a critical factor when it comes to getting better. Its also a component of deliberate practice.

There are two ways Im getting feedback.

First, after I complete a problem, I study the solutions of others. Sometimes resources, like LeetCode and Cracking the Coding Interview, provide the solution. Other times I find the solution of a programmer whos solved the same problem. Sometimes use both.

Either way, the next step is the same: I start at the top of the solution and explain each line in my own words. I speculate why the programmer chose this particular data structure, for example. Then, I write a short summary of the program to solidify the core concepts or new approaches that I just learned about.

Putting something complicated, like a line of code, into your own words is a great test to see if you really understand it. Plus, you get practice at another core skill: reading code.

If theres something thats new to me, I research it. I compare their code to my own. I study. I evaluate. I learn. Its an arduous process, but I get so much from it.

The second way to get feedback is to simply ask another programmer for it. Video calls are helpful to step through code line by line in real time. Although, pull requests are useful, too.

Theres a point to the feedback: apply it! Put your learnings into practice.

5. Be Consistent

Now lets talk about repetition. Problem-solving is a skill. Like any skill, it takes time to build. It simply doesnt happen overnight or over a weekend. Thats why I devote time each day to problem-solving.

Theres a common reaction to this daily practice: Theres too much to learn. I cant spend time each day problem-solving.

My response is two-fold. First, theres always going to be something more to learn, always.

Second, in large part programming is problem-solving. It's fundamental to our craft. Its worthy of your time and attention each day. Heres the caveat: make your daily practice intentional.

Its an Art

Many people regard problem-solving as an art. I happen to agree with that sentiment. The same can be said for the process itself.

The ideas outlined in this article are my approach for getting better at problem-solving. Your approach may look very different. The point is this: be intentional about your practice. Quality matters; make each problem count.

Programmer and writer: amymhaddad.com | I tweet about programming, learning, and productivity | Creator of Programmers Pyramid: programmerspyramid.com

Originally published on amymhaddad.com.