A big part of learning to program well is learning to design your program so that the parts that need to know about each other do, and the parts that don't need to know about each other don't.
Imagine starting a company. When you have three or four employees, everybody naturally knows everybody else, and things work fine. But that doesn't scale even to 100 employees, let along 1,000. At some point you have to start organizing your employees into departments that are each responsible for certain aspects of the business. Employees outside the Accounting department shouldn't go messing with the books, and employees outside the shipping department shouldn't be shipping products. Imposing structure on the business makes things work better -- it makes the business work in an organized, predictable way. That structure might irritate the old-timers who are used to doing a little bit of everything, but it's necessary for the company's growth.
The same thing is true for programs. When you're writing Hello, world! or FizzBuzz or Tic Tac Toe, all your code fits in a single file and you don't need to think much about structure. But that doesn't scale. When you start writing programs that are more complex, you have to start imposing structure on the code. You have to think about how to group tasks, what information is required for each module to do it's job, and how different modules will communicate.
Using global variables for everything is like running a company where all the employees know each other and know everything about the business -- it'll work, for a while, but it makes it hard to grow. The sooner you learn to organize your program and the flow of information through it, the sooner you'll have learned what programming is really all about, and the sooner you'll be able to write useful programs.