Programming tutor? - Page 2

What exactly do you mean by "learning how to program"? Obviously syntax isn't an issue, and I'm assuming your schooling has taught you a number of useful algorithms and how to analyse efficiency and such.

So I'm guessing you are wondering how to write good code.

Personally, I highly doubt the usefulness of being tutored on writing good code.


IMO, the most effective way to learn this skill is to write your own programs, then try to modify / augment them a month or two later. There is nothing more memorable than seeing and struggling with your own past mistakes, and viewing your own code through the eyes of someone who had no idea what you were thinking when you wrote it (not touching your code for a month will generally have this effect).


Another crucial experience is to write one very large program over the course of many months to a year, as opposed to writing many small ones. For one thing, you will inevitably find yourself coming back to pieces of code that you've long-forgotten and needing to improve it, so it takes care of the above. But in addition, there are skills you will learn from writing a large program that you will never learn from writing small ones. Such as, how to organize your code and data so that you can:
- easily find a method or piece of data after you've forgotten where it is
- wrap your mind around all aspects of the increasingly-complex program without going insane
- etc.


For instance, you might try writing a moderately-complex game, and experience the following:

1. You get bogged-down from the growing number of relationships and amount of communication between different game objects.

2. You make your code easier to comprehend by using event senders and listeners for communication between objects, as opposed to having unique methods for every interaction between objects.

3. You start encountering the drawbacks and caveats of event handlers. E.g. maybe you thought, if object B is listening to object A, then object B doesn't need to keep track of object A, but then object B is destroyed and suddenly you get an error because A tried to send an event to B. So now B and A have to know about each other, so that B can tell A when it is being destroyed. But if B simply called a method from A, then A wouldn't have to know about B and the whole interaction would've been much simpler. Or maybe you have A check if B is still active before sending it an event, but now it becomes much harder to pool Bs for reuse, and you might find yourself with a veritable memory leak because the event just doesn't get triggered 99% of the time. In any case, you find a simple call from B to A would have been a much better option in this situation.

4. You gradually learn the kinds of situations where events are useful, and the kinds where they are more trouble than they're worth, and you establish a healthy balance between the two in your game.


Now imagine you learn several dozen things about programming in this way. If you were simply told these things by someone else, and never got to experience them first-hand, how thoroughly would you actually understand those lessons, and how many would you remember two years from now when you end up needing them?