What I mean by this is the changes that a program goes through from the first line of code to the finished product are what you need to understand when learning how to program. I recently watched one of those “online videos” and could not believe that it was presented by pasting sections of completed code into the project. Sure there were times that the instructor would say we needed a new file and I got to watch him change the namespace name and then he would say something like, “And now I will just copy some code from my completed project to show you how this works.”

Nobody goes from a blank file to finished code.

Or even knowing that you need exactly which files in the first place. That’s not a good way to learn how to program and it’s not how you’ll learn how to program at Take Up Code. Even simple methods that might be able to be written in one pass will still not need to be written at all until later in the project. That’s what I mean by the journey is critical.

We work our way up to a full solution. Some steps will be easy. Some steps will need to be taken a bit slower. And some steps will take us in the wrong direction for a while. You need to learn how to make progress, how to think about a problem and decide what you will do next. And you won’t get that when your instructor demonstrates a completed project that has just been divided into pieces.

You need to see how how the project began. You need to get that part running.

“But it doesn’t do anything!” you might say.

That’s right. All projects are like that in the beginning. You need to learn how to get your project to a working condition as soon as possible. I recommend right from the beginning. And keep it in a running condition that slowly advances into the final project. That’s the agile way of developing software and it’s not just a great way to learn, it’s also a great way to approach any project.

What about something simple such as writing Tic-Tac-Toe? Surely, an experienced developer can just write something like that in one giant leap, right? Maybe if that developer writes this same program several times. Even something simple like this, you’ll begin a journey and make many decisions along the way.

We recently did write a text based version of Tic-Tac-Toe and it required about 20 hours to explain everything. Now, sure, I could have written this by myself in about an hour. I still would have taken it step-by-step and kept a running version available the whole time. But that’s not the point.

I have a book that teaches game development with C++ and it also has a section about Tic-Tac-Toe. It’s about 13 pages. How long do you think it would take to read 13 pages? Maybe 10 minutes? How is it possible that the book can describe how to write Tic-Tac-Toe in 10 minutes when I spent 20 hours teaching the same thing?

Because the book skipped the journey.

The book showed the main method in it’s final form with about 30 lines of code. As if a student learning how to program would know how to jump right into the final structure of the program.

Do you know what my first version of Tic-Tac-Toe looked like?

int main ()
{
    return 0;
}

It doesn’t get any simpler than that.

That’s the starting point that I begin with when I’m teaching you how to program. I took this starting point through 40 different stages and explained all your options along the way and why we would go with one design instead of a different design. That’s where the 20 hours was spent.

The final version had almost 400 lines of code. And by the time you get to this point, every one of those lines is your friend. You’ll remember when you first thought about the need for each line of code, what came before it, where you went after that, and why.

That’s how you learn to program. You take a journey.