Programming Wisdom: What My Professor Taught Me About Mastering Code

In this post, I want to talk about my days at the programming academy. The advice and experiences shared by developers and programming instructors were truly like gold. I remember reading Mr. Pressman's book—it was genuinely enjoyable. His work on software engineering is fascinating, and I might even write a separate post about that topic someday. Looking back on those days now, I realize how valuable and helpful those insights really were.

Maybe today you'll criticize me for saying in my first post that experience means writing code and making mistakes—not reading thousands of books. You might have noticed a contradiction in my words, but it's not quite that simple.

Studying programming is very important, but gaining hands-on experience is even more crucial. The most important thing is to dive into real programs and problems, make mistakes, and learn more through them. Let’s look at it from another perspective to make things clearer.

You know the fundamentals of programming and you're writing code. But when you encounter an error and your program doesn't work, what do you do?

You go through the code from top to bottom, trying to find where things went wrong. In that moment, you're interpreting the code just like a computer would. You're essentially using your mind like a compiler or an interpreter, right?

This is what it means to train your mind. It’s about strengthening your thinking and sharpening your perspective. You’ve turned your mind into a language interpreter—reading lines of code and instinctively knowing what each one will do. You’re cultivating your mental skills without even realizing it.

Let’s be honest—many of us who write code have experienced this. I’ve personally done it many times. As I reflect on my memories, I recall one particular day during a multi-hour journey to my destination. I didn’t have access to a computer, but I was eagerly reading Michael Morrison’s book on HTML. While reading, I mentally hacked the codes and interpreted it like a browser would. That experience was truly fascinating and enjoyable. Mr. Morrison explained the codes line by line, but what made it exciting was imagining what each tag does—and visualizing what happens when you add different attributes to a tag. That part was genuinely thrilling.

Of course, nothing can replace testing code on a real system. Because the way our mind works is often worlds apart from how the system will actually behave.

Maybe you can't solve the problem—so what do you do? You turn to the book, right? That means a deeper study of your reference. It means reading more books in that field to uncover the reason behind the error. So in a way, the error pushed you to study your source more thoroughly, didn’t it? Now here's a question: is that a good thing or a bad thing?

When we were working on the C programming language, our professor held up a book and said something I still remember. He said, "I’ve read this book several times, and each time I studied it, I learned something new!"

He truly captured the essence of it—and it’s absolutely true. You read a book. The first time, you might just want to get familiar with the syntax and commands. The second time, you study it more deeply. And each time you return to it, your understanding grows deeper and deeper. When you're searching for solutions, when you're exploring error handling, when you're immersed in a sea of code—what do you do? What happens?

Didn't those very errors lead you to deeper study? But what’s the use of studying without putting it into practice? Nothing! To grow, you have to write code. Reading texts will also spark new ideas.

How do you approach things? You need to have a creative mind. Programming is infinite—there are countless ideas and problems. Every day, we face thousands of challenges that need solving, and everyone has their own way of approaching them. I remember when we used to attend those dull math classes. Each person had a slightly different method for solving the same problem, and our professor encouraged us to explore multiple ways of solving mathematical problems.

One person would solve problems by explaining every detail step by step, while another would write the solution in a single line. When we attended programming classes, the same pattern emerged. This is what opens the mind—different ways of solving a problem!

On our first day of coding with Pascal, when the professor asked us to write a program that could identify odd and even numbers, we hesitated. We were just starting out, with rigid minds. Our thinking hadn’t opened up yet—we hadn’t truly entered the world of programming.

The professor stood above us, watching quietly. I remember he smiled, glanced down for a moment, then lifted his head and asked: "How do you distinguish between even and odd numbers in mathematics?"

That one question was enough to unlock everything. Sometimes, a single question leads to a brilliant answer. From our earliest days in math class all the way to graduation, we had done this countless times—we could easily identify even and odd numbers. But how was it that today, when trying to express the same concept through Pascal code, we found ourselves stuck and confused?

Do you turn to your professors? A sea of experience?

You see, in any case, you're winning. One way or another, you're on the right path. That's why I say every mistake is an experience. Without making mistakes, you learn nothing. Even forgetting a single semicolon at the end of a statement buried in a sea of code—that too is a learning moment.

Writing code in Pascal during those early days was unforgettable. We would throw lines of code into the editor all at once—aimless and unstructured. As soon as the professor said, “Write this piece of code,” we’d dive in: begin, then the next line, then more code, until end;. A good teacher always guides their students.

The professor shouted, "What are you doing? What kind of coding style is this? Do you even know where you're trying to go? So chaotic, so rushed! This kind of behavior leads to sudden, unexpected errors. When you compile the code and see so many errors packed into just a few lines, you feel tempted to give up on fixing them. You’ve made such a mess that you’d rather start from scratch than dig through the chaos to find and correct each mistake. How much time do you have to dedicate to a program or a project?"

And that was a lesson—a lesson in writing clean, structured code by following software design principles. He told us: Start with begin, and finish with end;. Then, step inside and continue building the program in a well-formed, orderly fashion.

Yes, the professor taught us the fundamentals from the very beginning. He took these newbies by the hand and taught them how to walk. He showed us how to reduce the number of errors. A good teacher is always a blessing. Practice is always valuable. Writing clean, well-structured code is always beneficial. And discipline in programming—it's truly excellent.

We should always follow a coding approach that minimizes errors as much as possible. So, we would begin by writing the basic structural elements of the language first—then move on to the actual code.

These are lessons we learn through experience. So never forget to practice.

Posted Using INLEO