Create throw away projects that you use to try stuff out and play with. Reading is fine but it is through application that the details actually sink in :)

You don't need to know everything, you only need to know where to find it.

The flip-side of this is that you will not understand your own work after some time as well. To avoid problems there, I document the overall idea, the input/output of every method and function, and the meaning of member and global variables. For the really tricky parts, I often write a page of explanation how I derived the solution.

I have come to see that as the next step in making the source code nice to read, after formatting, using consistent naming style, readable names, and a few lines of higher level comment in the more complicated functions, ie the stuff that everybody does.

(Documenting every function avoids the nasty question of when is something complicated enough to document. Instead of pondering that question for each function, I spend that time just writing a few lines, which is mostly copy/paste with some changes.)

When I started out, there was almost no material to work from. This is a double edged sword, as it encouraged experimentation and hands-on time is required to learn anything. You can't just read about something, you need to do it, multiple times in fact. On the other hand, things were also needlessly difficult to learn as a result of missing material.

Thank the dogs for people like Michael Abrash that started publishing books on an otherwise arcane subject!

Ok, time to impart some old man knowledge.

When i started writing games, there weren't really many books available to me on the subject of making games, and the internet was only available in universities (which i was too young to attend at that point).

I owned an 8 bit computer, and i obtained the technical manuals and programming guides for it. These were my reference material along with reading the fine source of many games, and later on using a dissassembler to learn clever tricks (it's here that i learned for example that a number XOR itself always equals zero and that XOR of a register with itself only takes one byte of memory as opposed to two bytes for loading it directly with zero... you get the point).

Without google, gamedev.net and other resources to hand, I had to memorise a lot more, and have a lot more hard-copy to hand for use. My shelves were piled high with technical manuals which went as far as to document the voltages that existed on the CPU bus... These days it's easier to learn, and so long as you know where to find it it's easy to amass a huge amount of information on a subject, and with determination, apply it.

On that note, when i started out i was younger (13 as opposed to 35) and it's much easier to absorb information when you're young. Sometimes now i look at a subject and it takes me twice as long to get to grips with it as i would have as a teenager. Learn as much as you can while you're young!

>> When you were starting out how do you absorb information on books, tutorials and stuffs?

i've always had instant comprehension. so then it basically comes down to the lucidity and eloquence of the explanation in the textbook or whatever. not everyone is a good teacher. not everyone is good at explaining things. but they say one measure of your knowledge of a subject is how easily you can explain it to others. if you're having trouble understanding someone's explanation of a subject, seek out someone else's explanation of it. it might be clearer.

>> on a clearer note, what do you do that helps you remember everything you read

use it repeatedly. i have great difficulty with rote memorization. i can't remember the syntax of a new command 5 minutes later. you just keep looking it up until you've done it so many times you remember it. even if you're looking up the syntax of the same command every 5 minutes. jotting stuff down on a piece of paper helps. i kill a lot of trees that way.

>> and understand how they really work?

i'm long on theory, but short on memorization. explain it clearly once, and i understand it forever. always been that way. but if i need more than 1 or 2 items at the store i need a shopping list.

>> But sometimes even if I reread the text several times, I just can understand and remember specific stuffs and takes me ages just to figure out what I am supposed to do and supposed to use on the thing that I'm working on.

some things are more complex than others.

i have a few sayings from "life in the engineering lane" that apply here:

1. "rome was not built in a day" - IE big stuff takes a long time.

2. "sometimes you have to break a few eggs to make a real mayonnaise". - IE significant undertakings require significant effort.

3. "as goes the project, so goes the mood of the engineers". - IE its natural to become discouraged or frustrated when things are difficult or not working as they should. we all do it. just soldier on, and you'll get through.

>> And to experienced programmers out there, do you still check the index,glossary and stuff often? (Documentations[F1] or whatever it may be for you) Because I find myself looking at it once, twice or more everytime I work with a project.

when adding a feature or making a change, i'll typically lookup any calls whose syntax i'm unsure of. this may be none or six or more for a screen or two of code. if i sort of guess, the compiler balks, and i have to look it up anyway. when writing Dx code, i have to look up almost every single call, except stuff i use all the time.

When you were starting out how do you absorb information on books, tutorials and stuffs? on a clearer note, what do you do that helps you remember everything you read and understand how they really work?

There are times when I can absorb the information easily and recall them back easily when I need to use them on some projects. But sometimes even if I reread the text several times, I just can understand and remember specific stuffs and takes me ages just to figure out what I am supposed to do and supposed to use on the thing that I'm working on.

And to experienced programmers out there, do you still check the index,glossary and stuff often? (Documentations[F1] or whatever it may be for you) Because I find myself looking at it once, twice or more everytime I work with a project.

Thank you in advance.

Heck, I have an eidetic memory and I still look at online documentation and StackOverflow. With time comes success.

I remember nearly nothing. Well, except the algorithms. I remember the concept of how it was done (if I'm lucky - sometimes I even have to review that). That's why I keep all my old source code. It's a small part of why I teach. Because I post all my source code for the whole world, I have a library of source code to reference. And when I lost my hard drive last year, I was able to go to that online code repository and regain my code. Without my old source code I would be in trouble. I would have to go back and relearn some of that.

By consulting the old source code I can either load a library of it, copy and paste it into a new project, or just read through it to remember how I did it (especially good if you need it in another computer language). I also have about 10 full size book cases full of books even though I've been buying most computer books in electronic format for the past few years (although only about 1 or 2 of those book cases is my computer books). I also google several times a day. And if I'm coding, I'm probably googling a couple times an hour. Even doing art stuff I google. And go to YouTube.

In short, learn the concepts. Some of it does stick. Don't expect everything to stick. If you can remember the general idea and which book it was in, you can go review the book when you need to.

And above all else: practice. Constantly writing code is what will make you better at writing code. That and learning new techniques regularly.

But the biggest "secret" is copying and pasting code from old projects where you did it before. Heck, if you copy the same code often enough, put it in a library. That's what libraries are for. Oh. And comment your code so you can remember what you were thinking at the time when you go back to reference it. Otherwise, you probably won't remember what you were thinking 18 months ago.

That and learning new techniques regularly.

I got to ask, as a new programmer, I started making pong game and now moving on to breakout game. The stuff I learn from the pong I use it on breakout? Is that the meaning of new technique? I was thinking of it like a new way of writing your code? sort of like making the code readable or something like that. and also When do you learn new techniques? Doesnt that make you feel overwhelmed? Its really hard sometimes for me to get when exactly I should learn new techniques if the one I had is already working.

, I usually download other peoples project if its not complicated enough and break it down to simpler terms. Did that on the State Management system in Xbox live source code I think. But that takes a lot of time for me and Im not also sure if that is new technique since I am just copying someone elses idea. I rarely also use or go to documentations. I prefer copying someone elses code and experiment to understand it. I got a lot of experiment project on my drive. I never deleted it. Its also maybe one of the reason I have a very slow progress. Is this learning style not good for a programmer?

It sounds like you're on the right track. Copying code, reading through other people's code, going through tutorials, that's pretty much where you have to start.

The trick is to be able to do something next week that you could not do this week. Just one thing. In the very early stages, it could be something as simple as learning to use a do-while statement and the next week learning a while-do statement. I don't really do 2D; I went pretty much straight into 3D. So, I'm probably not the best person to ask about exactly what things you need to learn to get better at 2D.

In 3D it would be things like learning how vectors work. Learning how matrices work. Learning about the view matrix works. Learning how the world matrices work. Learning collision detection with spheres. Learning about axis aligned bounding boxes. Learning about oriented bounding boxes.

It helps if you have someone to guide you on what to learn and constantly challenge you each week with something new. Schools can be good for that.

You're not really practicing if you are practicing what you mastered a year ago. At best, you are keeping your skills sharp, but you're not growing. And learning new stuff is difficult and daunting. A lot of times, that thing you don't know can be very intimidating because you don't know it and there doesn't appear at first glance to be a way to learn it. But you dig (usually google) until you figure it out and then code it and it works.

It really boils down to whether you can say you know something (even just one thing) that you didn't know last week about game programming. What specifically a technique is is hard to say because it can vary to the extreme and it's different for whatever subject you are trying to learn whether it's 2D game programming, 3D game programming, baseball, race car driving, playing guitar, etc. With playing guitar it could be things like learning a new chord you didn't know last week, learning a new rhythm you didn't know last week, or learning something that would be more accurately termed a "technique" like palm muting. Skill might be a better term than technique.

But the bottom line is, "Are you better and stronger at doing it than you were a week ago, even by only as much as knowing one thing more than you did last week or being able to do one small thing you couldn't ever do before this week?" If the answer is yes, you are growing. And if you grow like that every week consistently, after a year you know will know 52 things you did not know the year before. After 10 years it will be 520. Those things add up especially if they are as broad as "I learned how to use vectors for keeping track of rotations and directions.

You want to take something you can't do at all, spend a few days figuring it out (because it should be something difficult enough that you have to spend at least a good 4 hours learning it - I'm not referring to trivial things), and then a day or so doing it until you feel confident that you understand it completely and could do it again. What specifically it is is not as important as that it's something that makes you better at your goal and that you took on a difficult to moderately difficult challenge and over came it.

And as far as using other people's code as a learning device, I finally came to the conclusion that that's the best way for me to teach. I tried doing step by step tutorials and it takes forever. So, I started just writing working code examples and posting all the code on my website for people to learn from and use. Generally when I want to learn something new, I'll go find some code that does roughly what I want to do and then incorporate something similar into what I'm doing to make it my own. But I'll start by reading through their code line by line until I get the concept of how it's done. I'm not sure you ever stop doing that. It's a good way to learn a new "technique". I've spent entire weekends going through other people's code to learn things like how to implement point lights. So, instead of doing tutorials, I just try to post example code. And when I have time, I try and post a video walking line by line through the code on my YouTube channel.