Since we’ve touched upon the topic of logs, let’s talk about them in a bit more detail. Yes, this will be an advanced topic (marked with an asterisk), but why not start it right now?

In both our first conversation about why the “Hello, World!” example is needed, and in the recent discussion in the “Log, Forest, log!” section, we voiced an important idea:

It’s crucial to first learn to see what the program is doing during its operation.

Why is this important?

Not only because it allows us to better understand how our program works.

Let’s say we’ve already written a working program; it compiled successfully, we launched it, and it’s running (!). It would seem—success! We could delete all the logging operations we placed in the program to understand what’s happening inside it.

But it’s not that simple! The fact is, our success might be temporary. Yes, the program works correctly now, but it works correctly with the input data it’s receiving right now. What if a situation arises that leads to the program crashing because we didn’t account for some scenario?

Let’s take a government services website as an example. Suppose you are one of the developers and created a user registration form. You designed it with standard personal information fields: first name, last name, date of birth, and email address. Everything works! Users come, fill out the form, there are no complaints. And suddenly, a complaint arrives from a user that when trying to fill out the form, the website page “breaks,” an error message appears, and the user can’t proceed. You test it yourself, enter different data—everything works! What’s the matter?

If you had logs, by looking into them, you could see that the program crashes when the “Last Name” field is left empty. The validation logic expected every person to have both a first and last name, but the user—perhaps following naming conventions from countries like Iceland or Indonesia—only provided a single name. Your system wasn’t prepared for this scenario. Unexpected, right?

While the input data matched your expectations, the program worked successfully. But with a certain combination of input data, everything went awry. And if it weren’t for the logs, it would be difficult for us to understand what specifically caused the failure in our program.

Notes

  • Let me remind you that cases like our single-name user example are called corner / edge cases.

  • In a real situation, proper form design would account for various naming conventions across different cultures.

  • Many cultures have naming traditions that don’t follow the “First Name + Last Name” pattern common in Western countries.