To Become a Better Programmer, Learn to Become a Better Editor

Say a writer writes a first draft of an essay and thinks to herself, “I’m done! I’m ready for the next essay.”

No writer says this!

Any writer will admit that the writing is in the editing. This is a truism for writing prose. It’s also a truism for writing code.

If you want to become a better writer of code, then think like a writer of prose and become a great “editor.” Looking back at your completed solution is the way to do this.

Looking Back

Looking back is the last step of a four-part problem-solving process described in George Pólya’s book, How to Solve It, which takes a mathematical perspective toward problem-solving. According to Poyla, looking back means to “reconsider and re-examine the result and the path that led to it.”

Say you solve a problem. Before moving to the next problem, look back at your work: learn from it, improve it, and consolidate your knowledge.

There are many ways to look back at your completed solution. In fact, I’ve written a book that covers seven different strategies to apply. Today I want to share two of them.

Take Another Route

First, after you solve a problem, try re-solving it in a different way.

Usually, our first idea isn’t our best one. That’s why writers work through multiple drafts before calling an article or book complete. Artists often work through multiple sketches before even attempting the artwork itself.

Think of your first solution as a first draft. Try a second. Try a third. You’ll make improvements along the way.

To get the ideas flowing, here are two questions to ask yourself:

• Are there sections of code that are confusing or contain a lot of logic?
• Can I improve the time or space complexity of my solution?

Answers to these questions may give you ideas about a different data structure to use or a different approach to try.

Explain It

After you complete a problem, read your code out loud and explain what’s happening each step of the way.

Explaining is different than describing. Instead of saying “I use re.findall()” and move on to the next line of code, explain what re.finall() does and why you’re using it. For example, you may say: “To get unique elements, I use the regular expression function, re.findall(), which will match all of the lowercase letters in a sentence.”

Explaining your code is a knowledge test: if you can’t say a short, simple explanation of a line of code, then there’s more learning to do before moving on.

It’s always worth taking the time to really understand what’s new or unfamiliar to you. Programming concepts appear over and over again. So if you don’t really understand what a set() is now and why you’d use one, you’ll likely be equally confused a week or month later when it comes up again.

When you verbalize your code, you’ll also catch errors and opportunities to make your code better. That’s because when you read your code out loud you engage another sense: your hearing. What you catch with your ears differs from what you catch with your eyes. If your words sound off, then there’s probably room for improvement.

An Investment

Editing your work by looking back takes time and effort. So why do it?!

First, it’ll clarify your thinking. As you revise, iterate, and improve your solution, you’ll understand what you’ve set out to do, why, and how to make it better.

Second, the learning will stick, so you don’t have to keep re-learning the same concepts repeatedly in future problems.

Third, you’ll learn to write quality code. Anyone who’s had to re-write an entire program (or large sections of it) or spent tons of time searching for a bug can attest to the power of writing quality code. Yes, it takes time at the outset. But your future self will be so thankful.

Thinking like a writer is an investment in yourself as a programmer. ​​After all, writers of prose and code are in the same business: communicating clearly.