What distinguishes great programmers from good ones? It’s a question I’ve been wrestling with since I began learning to program.

I’ve written previously about the skills and knowledge great programmers have. Now I’m looking at the traits they possess. They seem to do things differently than the rest, and the results show.

This blog post focuses on two traits that have surfaced from my study of great programmers whom I’ve paired with, read about, and researched. There are—without a doubt—two commonalities among them: be consistent and be persistent.

Fortunately, we can develop and incorporate these two important traits into our own work as programmers.

1. Be Consistent

Programming isn’t something great programmers do once in a while. Nor is it something they do nine-to-five during the week.

Rather, they have a regular cadence for improving their knowledge and skills on their own time: before or after work and on the weekends.

One programmer I know spends the first two hours each day—six days per week—on personal learning projects or problems. It’s time spent on topics he wants to learn or skills he wants to refine. He gets his personal programming in before work starts and obligations of daily life begin.

It’s not to say that they’re programming around the clock. They’re like the rest of us and have other commitments and interests. But they’re consistent: great programmers make getting better a habit.

What’s Your Programming Mileage?

The question is: how can you be consistent? It’s something a lot of us struggle to achieve. The solution, I’ve found, is twofold.

First, identify the number of hours you can realistically program each week. This number is your weekly “programming mileage.”

As a former long-distance runner, I had a certain number of miles I ran each week. This was my weekly running mileage. Now I have my programming mileage: this is the number of hours I spend each week programming.

Most people neglect this step. They jump straight into the project they want to complete or the topic they want to learn, without considering where the time will come from. They go full-board, pulling all-nighters or sixteen-hour days.

There’s a problem with this approach: it’s not sustainable for the long-term. Sharpening your skills as a programmer isn’t something you do for an intense week or two. Instead it’s something you’ve got to work at consistently for the long-term.

That’s why it’s important to determine your programming mileage. To do so, consider using a time log for a few days to see where you spend your time. Take a piece of paper and write down everything you do each day and the amount of time you do it, including the five-minute social media or email checks.

Now it’s easier to find pockets of available time and areas where you can cut. Maybe you can:

* Outsource some of the chores you do around the house.

* Cut out some TV time each night.

* Get up an hour earlier before your day job begins.

Once you determine your programming mileage, you can create a training plan. It’s the second part I’ve found for making consistency a reality.

A Programming Training Plan

My first attempt at programming and my first half-marathon have something in common: both lacked training plans and the outcomes were dismal.

But there’s something else. In both cases, after such poor results, I added a training plan and stuck with it. And when you do, the results take care of themselves.

A training plan is one of the most effective ways to be consistent and ultimately achieve goals. That’s because all of the details are determined in advance; you just have to implement it every single day.

My running training plans detailed the number of miles I needed to run each day and how fast I needed to run them. Now I create programming training plans that serve the same purpose: they tell me what I need to do each day.

At the end of the day, I open up Evernote on my computer and type out a schedule for the following day. So on Tuesday evening, I create a schedule for Wednesday.

Here’s an example:

6:30am-8:30am - Program

Review Python Anki flashcard deck for 20 minutes
Complete “Word Cloud Data” problem

I follow this process for my entire work day: denoting the amount of time I'll spend on a task and what I want to complete during that time.

I also create a monthly training plan. In it I include three things I want to build, learn, or complete in the month ahead.

I used to create quarterly plans. But I found that too much could change over the course of three months. A monthly plan is enough time to make significant strides, yet short enough to keep to momentum going strong.

Plus, a monthly plan gives my daily training plans meaning. You’ve got something concrete to shoot for. “I must show up today and learn JavaScript. I need it to meet my monthly goal: complete ‘x’ project.” A monthly goal gives your daily training meaning.

2. Be persistent

The second trait great programmers have is persistence. They’ll work through the layers of the problem and get the solution.

That seems to be the secret. The great programmers I’ve studied have the uncanny ability to break problems down and uncover the layers of a problem or an ambiguous situation. In short, they have a problem-solving system.

It’s a lot easier to be persistent when you’re working on something that’s manageable.

A Problem-Solving System

I hit a wall early on when I began learning to program.

I never learned how to problem-solve in school. When given a problem set in math class I just dove in at full-speed, which is what I did when I started to program. No plan. No system. No time to think. No breaking things down. Unsurprisingly, in both cases, I was spinning my wheels unnecessarily and constantly hitting roadblocks.

Now I have a problem-solving system that helps me break a problem down to uncover the layers.

For example, the first step in my problem-solving process is understanding the problem statement. “Okay, I just need to figure out what the question is asking,” I tell myself when I pull up a new problem and haven’t the slightest idea of where to begin. It’s the first manageable step when solving a problem.

Once I figure that out, I focus on the next manageable step—and only that step.

Understanding the given inputs and expected outputs are manageable.
Identifying edge cases are manageable.
Writing pseudocode is manageable.
Solving a simplified version of the problem is manageable.

You get the idea. The steps may not be easy, but they’re manageable.

Working through a tough problem is how we get better. It also builds confidence. Once we tackle one hard problem we’re ready for more.

It starts, however, by breaking the task into small parts and working through each part one at a time. When you do, preserving through a difficult problem becomes very doable.

It’s an Attitude

On the road to becoming better programmers, there’s something else we ought to consider: attitude. Great programmers have a refreshing attitude toward challenges and ambiguity.

This point was made clear to me when I asked a senior developer a few questions about a problem I was stuck on. I was stumped and frustrated. The developer was puzzled, too, initially.

However, his response shocked me. “Wow, that’s a great problem,” he said. His interest was piqued, as he dove into the details.

It's not to say that great programmers don't get stuck, too. They do. The difference is attitude. The lesson I learned that day was this: great programmers are excited—not fearful—to venture into the unknown. They're realize they're bound to learn something new as they uncover the layers of a problem.

We can learn a lot by studying programmers better than ourselves. I sure have. But ultimately the onus is on us: to show up each day and take action.

Programmer and writer: amymhaddad.com | programmerspyramid.com | I tweet about programming, learning, and productivity @amymhaddad