Thread: How are you guys so good at programming?

I struggled with an assignment for many hours, which supposedly takes the instructor 10 minutes to do. It wasn't "hard" or anything, i just couldn't get my pointers stored in an array of pointers.

Took someone less than 5 minutes to fix my problems, and debug my program.

Wow!

When you were in HS or college, did you jump straight into coding or did you try to understand the core concepts behind pointers, arrays, etc?

honestly, it took me a while to fully understand pointers. they are the single biggest hangup for new C and C++ programmers. you are not alone.

If you're writing code using things you completely understand, you can code pretty fast and well - but you won't be learning anything.

If you're writing code using new/advanced material [relative to your current knowledge], your coding will be slow and there will be plenty of mistakes - but you'll be learning.

When I crossed over the pointer "learning hump," it wasn't a linear progression. I read it in my book, then typed out the sample programs. Tried the exercises, didn't get them, re-read the book, thought about it. Tried some more exercises. Re-read again, etc. Then I started using them in my own programs. Even then, I didn't fully understand the concepts until I gained enough familiarity [experience] with them over time.

Originally Posted by Matticus

If you're writing code using things you completely understand, you can code pretty fast and well - but you won't be learning anything.

If you're writing code using new/advanced material [relative to your current knowledge], your coding will be slow and there will be plenty of mistakes - but you'll be learning.

When I crossed over the pointer "learning hump," it wasn't a linear progression. I read it in my book, then typed out the sample programs. Tried the exercises, didn't get them, re-read the book, thought about it. Tried some more exercises. Re-read again, etc. Then I started using them in my own programs. Even then, I didn't fully understand the concepts until I gained enough familiarity [experience] with them over time.

I read the book too, and the concepts make sense. But i won't learn much of anything until i actually do the Projects at the end of the chapters.

Originally Posted by tmac619619

I read the book too, and the concepts make sense. But i won't learn much of anything until i actually do the Projects at the end of the chapters.

In my opinion is that writing code is what will make you learn how to program!

Programming can not be teach'ed by any book. Programming can be practiced. Of course you did goog to read the book.Now that a have a taste of the concepts jump into code.
Also why not alternate from one to another depending on the circumstances?I mean you can write code, refer to books when you feel that you need to and then jump back to code.Do not forget, that the main goal is the code, not reading the whole book. Careful that this does not eliminate the goal to read the whole book, because by doing so you get inspired and probably pushed to write good code.

I would translate your program to football.Maybe not a right translate but i hope you will get my point :

You may study about what successful coaches and players suggest into their books - yes there are those who write books for their experience - ,you may read how the best gymnastics suggest you to train, you may also see all the sports shows analyzing every game that was played in our planet ( )( this has no big influence, they just to do it to attract people that do not really know football ), you may watch yourself all the champions league's matches,
BUT,
if you wish to become a good footballer you have to into the field.Translate theory into practical terms.Train, get fit , learn to handle the ball properly, play a match and score or save the goal depending your position.I mean that no matter how many theory you had off pitch, all that counts at the end is the result, the outcome.You either win or lose.Even draws will lead at some point to a winner.

Notice that i am not saying to cut relationships with theory and stick to coding only, neither the opposite. Of course not!

The ancient Greeks said :

Code:

Πἀν μἐτρον ἀριστον!

which is a wise word in my opinion, and can be translated to your problem as giving a balanced attention into theory (books) and practice (code).

I was lucky to have a great teacher in high school. Core concepts behind pointers, arrays, etc. were discussed by the use of real world examples: house numbers, addresses and contents of envelopes. Algorithms were like cooking recipes, etc. We didn't touch assembler and this was before C existed in any meaningful form. Our first language was BASIC which had arrays but no address/pointers. I picked up the documentation on the mini computer and learned assembler/machine language on my own. That was the time one could program the computer through switches and lights on its front panel - around 1971, 1972. When I learned C, the address/pointer issues were straight forward conceptually. Although syntax continued to be frustrating sometimes for years to come.

It may be that teachers dive in too fast into the language and throw assignments at students before giving them a foundation that's rooted in real-world concepts. Perhaps assembler should be taught too - that way arrays and addressing make sense.

Originally Posted by cfanatic

... What I find amazing is that people here can answer programming questions all day. They have to make sense of poorly worded questions, illogical code, and bad programming. I keep wondering if they have a headache from all the thinking(I do), or if their head is about to explode.

I get a headache from not programming all day in my current job. That's why I come here to exercise my brain a bit. In previous jobs I was doing problem solving on legacy code - thousands or hundreds of thousands of lines. Sometimes I've had to write scanner/parsers to automate finding errors. My first "job" was TA (teaching assistant) in university to help students with their computer science homework assignments - whether they'd be written in ALGOL, FORTRAN, COBOL, PL/1, SNOBOL, Lisp. So I guess I'm kinda wired to look through illogical / bad programming and poorly worded questions.