by Amy M Haddad

How I’m learning to program: it’s an endurance sport

Why my learning trajectory for programming mirrors my training regime as a runner

2EfUSzQpFfSx8CjbTde8H8qh09QIYyFX2-c-
Photo by Quino Al on Unsplash

I’ve read stories about people trying to learn programming at breakneck speed — programming daily for a dozen-plus hours for a few months in order to learn programming fast. I’ve also read about the aftereffects of this approach: feeling burned out and taking a long break from programming.

There’s nothing quick about learning to program, at least in my experience. It not only takes time to learn — and really understand — the vast amount of material involved. But it also takes time to learn to think like a programmer.

That’s why I see learning to program as an endurance sport. As a former long-distance runner, that’s one reason why I enjoy it so much. In fact, my learning trajectory for programming mirrors my training regimen as a runner. It’s about having a plan, setting a steady pace, and persevering.

Build Endurance with a Plan

My first half-marathon was memorable for all of the wrong reasons. The running conditions weren’t great: it was unusually warm May day in Indiana and the route offered little shade. But these were the least of my concerns. With my face flushed, heart pounding, and my legs like steel poles, I felt completely out of shape — because I was. I hadn’t followed a training plan, like most runners do.

I learned my lesson, and used a training plan for every race thereafter. These training plans provided several months of workouts that prepared me for the race ahead. They also got me the results I wanted: I dropped dozens of minutes from my race time and felt great doing it.

Today, I follow a different training plan: one for learning to program. It gives my studies structure, holds me accountable, and helps me get the most out of my programming hours.

It all starts with a quarterly plan, which guides my learning for the next few months. When I ran, I followed different training plans based on the race I was running or the time I was after. Now I create and follow quarterly plans with a specific learning objective. This quarter, for example, it’s learning computer science fundamentals using Python.

Once a plan is in place, I identify resources to help me achieve my goals. Then, I make it happen by creating weekly and daily plans, which help me budget my time and identify my focus for the day ahead. That way, I enter each programming session with purpose and know exactly what I need to do.

By following a running program, I knew how many miles I needed to run and how fast I needed to run them. It’s no different with programming. There was no guessing what I should do this morning when I opened up my laptop. I had those details figured out last night when I created a plan for the day ahead. As a result, I dove right into the problem set I needed to complete.

This planning process is not just a nice feature to have — it’s a necessity for me. My time is limited because I work full time and am learning to program outside of work hours. So I need every minute spent programming to count. My programming plan helps make that happen.

What’s your Pace?

It was a crisp, sunny November morning when I toed the line for a half-marathon. Before the race began, I noticed a group of runners huddled together; one was holding a flag with their race pace on it. “I’ll stick with that group,” I said to myself, and off I went. I should’ve known better.

This group was going far faster than I’d trained for. My time was looking great at the five-mile mark, but my energy was soon sapped. I couldn’t keep the group’s sprint-like pace for the next 8.1 miles. But by the time I slowed down the damage was done. I had started out way too fast and exerted a lot of energy in the process, making the remainder of the race long and laborious.

Starting off in a sprint will give you a dramatic head start, as I learned from that race. But it’s not sustainable for the long-term if you’ve got a lot of ground to cover. Consistency is crucial. It mattered when I was running long distances and it still matters now as I’m learning to program.

At 5:25 each morning my alarm startles me awake. I head for my standing desk, where I spend the next few hours programming. These precious hours are mine to chisel away on my daily programming goal before my day job begins. No all-nighters. No 16-hour days spent programming on the weekend. Instead I pour a few hours of focused effort each day, six days per week, into becoming a better programmer.

It’s not just the number of hours I spend programming, but how I spend them. Again, it’s a question of pace. Society pressures us to move fast in just about everything we do. However, I’ve found that approach doesn’t work — especially when it comes to learning. If I move too quickly, I overlook small but important concepts or get concepts mixed up. Plus some things, like recursion, take time to understand.

So the hours I spend programming are steady. I make sure I really understand the material or problem before moving on. This process involves a lot of repetition, which means I move slower. I admit that it’s hard to hold back, so I constantly need to remind myself that I’m building a foundation of knowledge. If I rush the process now, I’ll regret it down the road.

This pace is also sustainable for me. It’s a pace I’ve kept since I began learning to program and it’s helping me get where I want to go.

Consistency Matters

There’s a lot to like about consistency. For one, it makes learning manageable. Because I program a few hours each day, I’m focused on a just a small chunk at a time.

Today that chunk was understanding a sorting algorithm and getting practice with it. Other times it’s getting a test or two to pass. These are manageable goals. They challenge me, but they’re definitely doable.

Consistency also helps me with recall. When I use various data structures on a regular basis, I remember when and how to use them. They’re fresh on my mind when I start a new problem. Not surprisingly, my confidence increases, too. The more I use regular expressions, for example, the more comfortable I get with them.

I see progress more quickly with consistent effort because small, incremental improvements add up over time. Take recursion as an example. I certainly didn’t “get it” on my first pass, or even on the second or third. In fact, I’d been struggling with this concept for a while. Each study session has helped me progress, albeit slowly, from understanding the basic idea, to completing very simple problems and eventually more challenging problems. The culmination of daily study and practice paid off because it’s finally clicked.

Perhaps most important of all, consistency is sustainable for the long-term. If I put in a few hours of quality programming today, then I know I’ll have the energy to do it again tomorrow, the next day, next week, next month, and for the remainder of the quarter, until a new plan begins and the process starts again.

Consistent doesn’t mean easy. I feel comfortably challenged with my programming pace, though it’s taken some time to figure out the best pace for me. Going at a consistent pace, be it in running or programming, keeps a bit of energy in the tank. That way, when you’re really struggling you’ll have something in reserve to finish strong.

Persevere

When you’re running 20-plus miles, your legs feel like lead. You’re tired and hungry, and ready to stop. And yet you forge on.

It takes time to build the physical endurance to run that much, not to mention the mental stamina to see it through. Programming is the same way. Rare is the day that I solve a problem in just minutes. Problems can take me weeks to solve, and I get more bugs and failed tests than I’d care to admit.

But I show up each day and persevere, realizing that small wins matter. My aim is to get incrementally better: get one more test to pass or get fewer error messages. Similarly, during a long run, I’d tell myself “ok, just one more mile.” And when I’d get to that mile marker I’d tell myself again “ok, just one more mile.” In both cases, despite the challenges or discomfort, I’m inching my way closer to the end goal through sheer willpower.

The feeling of accomplishment after solving a tough problem is like the one I got when I crossed the finish line of a race or finished a long, tedious run. All of that time, effort, and mental turmoil were worth it.

There are some things in life that are quick to learn. Programming is not one of them, in my opinion. Once you get started, you realize how much there really is to learn — and it’s a lot! That makes it exciting, but it also makes consistency that much more important. I haven’t been programming too long. The race just started for me — and it’s a marathon, not a sprint.

I’m a writer (amymhaddad.com), and a beginner programmer.