Teaching Programming to a Middle Schooler with AtCoder #3: The First Submission (Part 1) ABC086A - Product

Content of this article

Recording how a software engineer teaches programming to a junior high school student. This is the 3rd article. Finally, the child operates their own machine and submits one answer. Part 1.

【Previous Article】
The 2nd time was about explaining AtCoder and doing a demo of solving and submitting one past problem in the set-up environment.

TL;DR (In 3 lines)

1. Let's finally try solving one past problem.
2. A senior developer has explained "It's good to start from here." Let's try that.
3. Proceed step-by-step and go all the way to submission. (Continued in Part 2 as it got long.)

Article used as a reference for the approach

The explanation from a senior developer saying "It's good to start from here" refers to this article. The beginning of the article is an intro, so skip it and look at Section 5, "10 Selected Past Problems!".

https://qiita.com/drken/items/fd4e5e3630d0f5859067#5-過去問精選-10-問

Let's use the first problem, ABC 086 A - Product, as our subject.

https://atcoder.jp/contests/abc086/tasks/abc086_a

Small-step procedure

1. First, read the problem carefully.

The input is a single line with two numerical values separated by a space. If the product of these two numbers is odd, output Odd; if even, output Even.

Now, after reading the problem, you might feel like writing the entire code at once. Everyone feels that way. But could you put that aside for a moment? I'm going to tell you something important.

📌 How to enjoy writing code

It looks cool to write the correct code from start to finish and be done with it. That's how hackers in movies seem to do it. But that's just because it's a movie. If they showed detailed debugging, they'd run out of time (the reality). Seriously, there's no such thing as a program that works perfectly without any fixes after being written entirely from scratch. Not at all. I want you to remember that.

So, how do you write it?

Write one command, run it, and see it work. Next, write another, run it, and see it work. Then, combine them and—oh, it works nicely. In this way, you write while checking the operation bit by bit. By accumulating these "it works" moments, you complete the code for the desired behavior. It's like walking step by step, firmly planting your feet on the ground and confirming, "Okay, I'm good," as you move forward. It's best to write code that way.

Suppose you wrote everything at once. If you run it after finishing everything, it usually won't work as expected. You're lucky if you just get an unexpected result. Most of the time, you'll get a mountain of errors. You'll have to deal with intense criticism of the code you just worked so hard to write, checking exactly where it went wrong. Just thinking about it is depressing.

This approach makes it easy to give up. The reason is simple: humans are naturally wired to get fed up with a cycle of being told "no" and having to fix things.

By writing the operations in small units and accumulating "it worked" moments, you're less likely to get discouraged. Let's go with this method.

2. Write code to get one line of input and try running it.

Me: "Try writing just the code to get the input."
Child: "Huh? Just get it and that's it?"
Me: "Yes."

solve_abc086_a.py

#!/usr/bin/env python
input()

Child: "Like... this?"

An anxious look. (What's the point?) is probably what they're thinking. It's to check if it works.

Me: "Let's run this using debug execution. What do you think will happen?"
Child: "Nothing, it just ends...?"
Me: "Okay, let's confirm that. To run it, select this and press this."
Child: "Oh... it worked... it just ended silently though lol"
Me: "That means it finished normally without any errors. Not getting errors is really important! You're laughing, but I'm serious! lol"

3. Add code to output a random string unrelated to the retrieved input and try running it.

Me: "Next. On the next line of the current code, let's try outputting something, maybe abcd or Hello."
Child: "Get the input, ignore it, and say what I want to say?"
Me: "Yes."
Child: "That's weird lol."
Me: "It's not weird at all (deadpan). The computer won't talk back or anything. Just try it."

solve_abc086_a.py

#!/usr/bin/env python
input()
print(Hello)

Child: "Like... this?"
Me: "Try running it."
Child: "Oh, it's getting mad at me."
Me: "The wavy line appeared. It's saying the syntax is a bit... if you want to know exactly what it means, hover your mouse cursor here for a bit, and it'll tell you."
Child: "Variable...? It's not a variable though? Ah, I see, I have to wrap it in quotes for a string."
Me: "Nice."

solve_abc086_a.py

#!/usr/bin/env python
input()
print('Hello')

Child: "It's not mad anymore. Is this okay...? I mean, 'run it,' right? I'm running it."
Me: "You're getting it."
Child: "It worked! Hello came out."
Me: "You did it."

4. Modify the code to get one line of input and output exactly what was retrieved, then try running it.

Me: "Right now, you're getting the input and throwing it away, right? That's weird, isn't it?"
Child: "Wait! You just said earlier it's not weird at all!"
Me: "And you said it was weird lol. Well, so let's not throw it away, but change it so it receives it and echoes it back."
Child: "I trusted you, and this is how you treat me. So I should put the thing I got into a variable once and then output that?"

solve_abc086_a.py

#!/usr/bin/env python
a = input()
print(a)

Child: "It worked! It's like an echo. When I type something, it comes back~"
Me: "Going smoothly, nice job!"

【Next Article】
In the second half, we'll finally move on to coding according to the problem and submit it.