I have a friend who is struggling with learning how to program (he wants to make games; as do I). Several books, tutorials, etc.

His mentality is he has to memorize the code itself, as in the exact syntax for a program. I believe he's wrong, and that it's more about understanding what the code does and how to apply it elsewhere.

Unfortunately, I'm still in the learning phase myself, so I haven't been much help to him. I'm hoping to get some advice from more experienced programmers on the matter.

Yes, this is what I believe as well. For me, I often see code in other projects/tutorials/etc and it clicks that it could be applied elsewhere. I've made a lot of progress this way.
–
SlateboardJan 24 '11 at 20:31

+1 What, really, do you learn by memorizing it? As far as understanding and levels of analytic thinking go, memorization is pretty low on the totem pole.
–
Cody GrayJan 25 '11 at 8:56

Hmm, I think I skipped the first two steps. My learning process was 1. Read a language specification, 2. Write some code, 3. Fix bugs, 4. Repeat step 2 and 3 until it worked.
–
Robert HarveyJan 24 '11 at 20:56

Well, you can sometimes change the order, but ultimately, you'll be going through all three. Note that "read language spec" is just a special case of my step 2. It's a way to understand the code. And in fixing bugs, you'll be reading (your) code. :)
–
jalfJan 24 '11 at 21:25

@Jefromi: Especially your first programming language. Granted, that was a while ago, and languages were simpler then. Today I can't imagine learning C# from scratch by going through the ECMA specification (it weighs in at over 500 pages), but MIT used to teach their programming courses using Scheme, a language that you can learn the entire syntax of in one afternoon.
–
Robert HarveyJan 25 '11 at 0:18

1

I only ever read language specs or detailed language documentation after I'd been playing with the language for a long. Different people learn different ways. For me, if I wasn't actively using it, none of the knowledge would stick.
–
Steven BurnapFeb 24 '14 at 18:14

The best thing I've ever done to learn how to program is screw up and face the consequences. By facing the consequences I mean fixing it then screwing it up again. You'll learn about patterns, mostly bad patterns, and how to change the way you look at the problem as a whole. This will hopefully drive you to research and find better patterns, learn and grow. Practice is key!

The only way to know that you've learned something is to do it from scratch. Try building a project yourself, the way you want it. (A calculator is often a great first project for this sort of thing.) I have helped several people start programming, and when they ask, "What should I do next?" I answer, "What do you want the program to do next?" Once they know what they want the computer to do, they can start making the computer do it. That involves asking questions, looking online, books, etc. Once you get past the initial "hello, world" programs, you've memorized enough.

That being said, there are a few people who can't develop the proper mindset for this. I don't think that it's a "I can never learn to program", I think it's a matter of never having learned to think creatively. Unfortunately, many schools encourage rote memorization of everything rather than learning to think critically, and this can cripply one's ability in any profession, not just in programming. If this is the case, you will have more work than merely teaching a language.

utilizing a library with that language to make more interesting things happen eg. graphics in a game

When I was learning programming I used to do a similar thing as your friend. I was trying to memorize libraries. With the IDEs today you really don't need to do that anymore.

Like you said, your friend would do good to study the code in what it does and why instead of trying to mimic it exactly. Modifying the code to do something different is also a good exercise in learning how to program.

Any child who would try to learn to communicate with the English language by reading the dictionary would be considered insane. Is learning words important? Sure, but a dictionary won't teach you which words are common and understood by the majority of people, how to structure sentences, how to put together coherent thought, etc. These things are learned not only by learning words, but also by learning via reading and writing sentences, paragraphs, and books.

Furthermore, you don't need to know every word in the English language to communicate with it. So long as you recognize that the words that come to mind are not sufficient for getting the point across, (or, in this case, that you need to find a function or chunk of code to accomplish something,) then you're fine. You just have to go hunt down that word, or, in this case, the appropriate function or code snippet. It is much better to only know 50% of words in the English language, but be very proficient in using a dictionary, using a thesaurus, or other method of search, rather than to know 75% of all English words.

Even if you spent your entire life trying, you could never memorize the definitions of 5,000 words if you simply tried to memorize them, but when the 5,000 definitions are a part of a network of interconnected knowledge, learning the definitions of 5,000 words is easy; in fact, we probably know that many by the time we're 13-15 -years-old. Mastery of one topic often requires adeptness in other related topics. You can't fully know how applications work unless you know quite a bit about operating systems, drivers, and hardware. Trying to memorize thousands quirks and details is futile. Through conceptual understanding, however, we can easily deduce thousands of details, almost all unconsciously or otherwise unforeseeable.

That said, you should fully understand code examples when you are reading about them, but complete and permanent retention of every parameter, etc. is a waste of effort. Probably the best way to learn would be to read the topics and code examples in the book, and then code them yourself. After a while, you'll have a large library of code that you yourself wrote, which you can read at anytime, and you'll have a better understanding of it because you actually wrote it down, instead of just reading it.

It is also perhaps possible that your friend is completely lost and struggling to understand what numbers are going where, how they're being calculated, manipulated, and used, how everything is fitting together in the grand scheme of things, etc. Understanding that is important -- that's part of the conceptual understanding -- but if it is just an exercise in tedium, then he's wasting his time.

How much lines of code can your friend memorize? 100, 1000, 10000, or more???
It is easier (and logical) to understand the code instead of torturing your memory. Once you master the art, you can build any program of any complexity.
So read some good programmers code, and then write your own. Practice as much as you can.

I know how your friend feels, as I went through the same thing. That is why I started a little club aimed at helping beginners. We are about to study game programming, so he might want to check it out.

I don't know if its ok to post the web address. But, I do not consider it spam, because this is a not for profit project. Tell him to visit www.iprogrammingclub.com for more information. I am the club's current admin.

Again, let me know if you consider this spam, as it is not my intention to somehow offend the community. Just trying to lend a hand here.

I believe the best way to learn any language is not just to program something but to program something that solves a problem. I learned ASP.net and C# doing just that creating applications that solved a problem at work.

I found that replicating examples in a book is great and all but it's almost too pure. When you create an application for your own needs, it becomes an iterative process of solving many small issues and this helps you absorb the nuances of a language much more effectively than reading a book.

Once you persevere through all the challenges, it's much easier to remember what you learned. I still read programming books to pick up new information but it's no substitute for a genuine challenge. And when a programming task seems enormous (like creating your first game), remember the cliche, the way you eat an elephant is one bite at a time.

Understanding the code should be your primary objective. Parts of any spoken language can be memorized, but that won't help too much if you're trying to carry-on a conversation. It limits computer programs as well. The examples in the book will only take you so far.

At some point you have to combine enough understanding with syntax memorization to have a certain level of fluency. There are some parts that typically get used more than others. Googling the syntax for an if/then statement every time you need it, just seems like someone doesn't understand the concept and/or hasn't programmed a lot lately. Memorizing is no guarantee of understanding either; although many interview techniques give candidates who've memorized things too much credit.

Understand the concept by writing code that utilizes it. If you do it enough, you'll memorize the important syntax so you can have some fluency and not frustrate yourself by having to constantly look up the same things. Don't waste time trying to jam the syntax of a connection string for example. That's why someone created ConnectionString.Com. Look it up and tweak it to your needs.

The most important thing to learn is do what it takes so you're writing more code. Personally, if I had to memorize things first, I'd give up.