How Ben Franklin Can Help You Become a Better Programmer

By: Amy M Haddad

Benjamin Franklin was a lot of things, including a scientist, an inventor, writer, and politician. He was also a great learner.

In his autobiography, Franklin describes his process to become a better writer. One technique stood out to me. It involves trying to reproduce an article after he’d forgotten the details of it.

It’s a highly effective learning technique, which I’ve used to improve my own writing.

Now I’m using it to become a better programmer.

Emulate a Great Programmer

To become a better writer, Franklin chose articles from the Spectator, a publication he admired and wanted to emulate.

When studying an article, Franklin made hints of the “sentiment” in every sentence. After a few days passed, he used the hints to replicate the article.

This wasn’t a practice in memorization: the aim wasn’t to produce the article word for word.

Instead he captured the same expression and completeness as the original, according to his autobiography, using “suitable” words that came to mind. The process concluded when he compared his version of the article to the original: identifying his mistakes and correcting them.

I’ve tweaked Franklin’s learning approach to touch on several core programming skills. It’ll help you:

• Get better at reading code,
• Add new programming tools to your toolbox of knowledge, and
• Improve problem-solving skills.

However, the goals remain the same: to learn and apply what you learn by putting it into your own style.

Here’s how I apply Franklin’s learning tactic to programming.

1. Find a quality problem and solve it

Find a good problem and solve it.

Any problem will do. However, I’ve found it useful to choose problems from larger problem-solving platforms, like Exercism or LeetCode, for what’s to come in step two.

2. Identify a great programmer

Franklin admired the Spectator, which he used as a source to help him improve his own writing.

For the same reason, you’ll need to find a “great programmer.”

This is someone who has:

• Written code you admire and would like to emulate, and
• Solved the same problem (see step one).

Above all, it’s someone who writes quality code (whatever “quality” means to you) and in a way that’s aligned with your core programming principles. Maybe this person is an industry leader, colleague, or an instructor that you’ve had.

This is an important step.

Just like an athlete can have a bad coach and pick up poor habits and misinformation, you can choose the wrong programmer for this learning tactic and have the same negative repercussions.

Besides, you’re going to dissect, study, and emulate this programmer’s code in subsequent steps. So take the time to find someone of quality.

The programmers I study have solved tons of problems on larger platforms. That’s why I like LeetCode and Exercism: they give me more options of problems to choose and learn from.

3. Dissect it

Franklin wrote down hints that he later used when he rewrote articles from the Spectator.

Likewise, I open a new file in my editor and write comments that explain each line of the programmer’s code.

I aim to understand what the programmer did and speculate why they did it.

The learning curve is typically steep, and that’s the point: it’s time to get better.

Read it and teach it to yourself

The commenting process is practice reading someone else’s code, which is an important skill that’s often neglected. Programmers are so eager to write code, but reading code—especially someone else’s—is equally important.

It’s also a practice of teaching yourself—a skill you’ll repeatedly use as a programmer. That’s why it’s worthwhile to make a comment for every line, even the ones you find easy.

These comments are a knowledge check. If you can’t type a simple explanation, then you may need to take a second pass at the concept at hand.

However, you’re not only interested in the what, but also the why.

Try to wrap your head around why it makes sense to use reduce() or why it makes sense to use a for loop instead of a while loop. Or why a dictionary is an appropriate data structure.

When you understand the why, you’ll start seeing patterns that you’ll use when problem-solving. Inevitably, you’ll come across another similar situation when it makes sense to use a dictionary. So take the time to understand the context now.

Why write?

There’s power in physically typing out comments.

For one, it’ll hold you accountable.

It’s easy to passively read a line of code and think “oh yeah, that makes sense,” but not really understand it. Typing comments will slow you down mentally and keep the learning active.

Plus, writing is thinking, at least for me.

That’s why freewriting is a crucial step in my writing process. The act of writing generates ideas, be it for writing or for programming.

4. Go down the rabbit hole

Undoubtedly, you’ll find something novel in the programmer’s solution.

Maybe the any() function is new to you. Or maybe you’ve not seen a dictionary used in this context. This is great news: you’ve found an opportunity to enhance your knowledge and sharpen your programming tools.

As programmers, we are constantly considering whether or not to go down a rabbit hole: that is, when to dive into the details.

Now is one of those times.

Right before your eyes you have a new tool that you can add to your toolbox and a context to use it in. Take the time to understand what’s new to you.

5. Make learning active

Let a day or two pass and reimplement the problem using what you learned from studying the programmer's solution. Use the comments you typed out as hints to guide you along the way. Then, compare your code with the programmer’s code.

This step is hard, so don’t get frustrated if you get stuck or don’t re-solve it correctly. That’s fine; you’re learning. Study the code again. Update your comments. Dig into the documentation. Let a few more days pass, and try it again.

Finally, make an Anki card so you’ll keep seeing this problem and its concepts over and over. That way, the new concept becomes increasingly familiar and comfortable over time.

To be clear, this practice isn’t about memorizing or copying someone else’s code—far from it. Rather, it’s about learning:

• Reading code,
• Seeing another way to solve the same problem,
• Experimenting with new parts of a language, and
• Teaching yourself.

It’s also about applying what you’ve learned by putting it into your own style, which is what this step focuses on.

Be a Better Programmer

If you find this learning tactic challenging, you’re not alone. I struggle with it, too. That’s a good thing: it means we’re learning. And the effort is well worth it.

This tactic focuses on the core competencies that you’ll use in your daily role as a programmer.

You’ll get practice reading and understanding someone else’s code. You’ll expand your programming toolbox: learning about and experimenting with new parts of a language. Consequently, you’ll get practice teaching yourself.

You’ll also begin to think about tradeoffs, like why the programmer chose to store data in a dictionary instead of a list.

In short, you’ll be forced to think, and your programming skills will grow.