Learning Python == Learning to Code (not always, but often)

(Adapted from a post I wrote on Quora...)

One important truth is that learning to program is much more difficult than learning a programming language. Wait, what? You might be asking yourself what the difference is, and if so, you’re not alone.

When one learns their first programming language, one must also learn to program–that is, not just the syntax of this new language, but why (and when) programmers use certain constructs and how and why they combine those constructs to solve problems.

It’s quite easy to explain the art of programming (and yes, it’s an art, but we’ll get to that later). Programming can be boiled down to this:

1. breaking a problem down into a series of steps;
2. converting each step into Python or whatever language you’re working with

See? It’s quite easy to explain. Unfortunately, programming, like many things which are easy to explain, is quite difficult to do in practice.

What could go wrong?

Well, for one thing, the steps have to be executed in the correct order. If you break down the problem into the correct steps but don’t get the order right, your code will not work.

What else could go wrong?

You could leave out a step. This happens more often than you’d think. If I ask you how to solve a problem you have solved many times in your head, you’ll often leave out a step.

What else could go wrong?

You could mistranslate a step into code. You got the steps right, but the code you wrote does not actually perform the step. Your steps (written in English, or pseudocode–half English and half programming language) are correct, but one of more them was improperly translated.

Your task, as a beginning programmer is as follows–DO NOT WRITE ANY CODE until you’re written down the steps. If you start coding before you know the steps, how on earth are you going to get it right? It’s sort of like monkeys typing on typewriters–eventually one of them might end up writing Shakespeare, but most of them won’t. (Not that I am comparing you to a monkey, but rather, the action of writing code without knowing what you are writing–there’s no way you’ll end up with correct code if you do that.)

Here’s an example to get us started. Suppose you want to write a program which prompts the user for a number, and your program will tell the user whether the number is odd or even. Not earthshaking, but we’re beginners here. We have to crawl before we can walk. Programming is a skill, and like any skill, there will be a time when you don’t really possess it.

OK. Let’s get started. You ask me for a number. I say “57.” You say “odd.” How did you know that? What did you do in your head to elicit the response of “odd”?

Let’s write down the steps:

1. Get a number from the user
2. Figure out the remainder when dividing that number by 2
3. If the remainder is 0, the number is even, otherwise, it’s odd

Those are the steps. Don’t write any code yet!

Let’s rewrite the above in pseudocode (a mix of English and a programming language). I typically have students write their pseudocode as comments, so let’s do that

# prompt user for a number 
# if remainder when dividing number by 2 is 0 then 
#     print "even" 
# else 
#     print "odd" 

Now let’s convert the steps to Python:

# prompt user for a number 
number = input('Enter a number and I will tell you odd or even: ') 
# if remainder when dividing number by 2 is 0 then 
if number % 2 == 0: 
    print('even') 
else: 
  print('odd') 

It’s not going to work. Do you see the problem? It’s difficult to spot. Let’s try it:

>>> number = input('Enter a number and I will tell you odd or even: ') 
Enter a number and I will tell you odd or even: 57 
>>> if number % 2 == 0: 
...     print('even') 
... 
Traceback (most recent call last): 
  File "<stdin>", line 1, in <module> 
TypeError: not all arguments converted during string formatting 

That error message is not at all helpful.

The problem is–the input() function, which prompts the user for input and returns what the user typed…wait, did you see it? No? What does input() return? Let’s try it so we can answer our own question:

>>> name = input('Enter your name: ') 
Enter your name: Dave 
>>> name 
'Dave' 
>>> number = input('Enter a number: ') 
Enter a number: 5 
>>> number 
'5' 

Aha! It doesn’t matter what we call the variable, input() always returns a string.

And then we tried to use the % (modulus) operator to find the remainder when dividing a string by 2! You can’t do that. We have to take what the user typed and convert it to an integer:

>>> number = int(number) 
>>> number 
5 

Now we’re cooking!

>>> if number % 2 == 0: 
...     print('even') 
... else: 
...     print('odd') 
... 
odd 

…and we have a working program.

Here’s the thing–never in a million years would you have written down the step “Convert string response from the user into an integer”. Because you do that implicitly in your brain. In fact, when you ask your friend to “pick a number”, you expect a number and assuming your friend isn’t joking around, your friend will respond with a number. Your brain recognizes the utterance as a number and you start to do your division on it (or more likely, you simply think about the last digit and divide that by 2…or you simply note whether the final digit is 0, 2, 4, 6, or 8–same difference.)

So you see it isn’t quite as simple as I’ve made out to be. But I promise you, if you write down the steps first, then convert the steps to Python (or some other language), you’ll be on the right track, and on a much righter track than if you start to write code first. Sometimes I’ll work with a student whose code doesn’t work and I’ll point to a line of code the student wrote:

Me: “What does that do?”

Student: “I don’t know”

Me: “Why did you write that?”

Student: “I don’t know”

At that point, I know the answer to my next question: “Did you convert the problem into a series of pseudocode steps?” So I erase all their code and get them to do that. And you know what? It works. Not right away, but eventually. This is tough stuff. The worst thing you can do is assume coding is easy. You’ll find out soon enough that you’re wrong, and to make matters worse, you’ll be discouraged.

Do you play guitar?

Do you make furniture?

Do you ride a bicycle?

Do you ski?

If I ask enough of these questions you’ll surely say yes to one of them. Do you remember a time when you couldn’t actually perform that skill at all? Do you remember struggling to get better at that skill? Did you ever get discouraged?

I think you get my point.

Remember when I said programming is an art? Sounds like it’s a straightforward decomposition of a problem into steps, and then a translation of those steps into code. Not much room for art in that process, is there? I believe there is.

I believe experienced programmers perform those same steps but rather quickly, and likely in their heads. Don’t get me wrong, even experienced programmers write things down on occasion. But they often don’t need to.

Where’s the art? It’s in the translation. There can be many ways to translate a step into code. And seasoned programmers can often combine multiple steps into one, well before you’ve even understood the problem. They “see” the problem more clearly, and they translate the steps more effectively.

But make no mistake–they are following the same pattern. Breaking a problem down into steps, and converting those steps. If you can do that, you can write code.