Thread: How you guys learn programming?

Short answer: hard work.

There are several things I've done, including ...

Reading books, some several times. Sometimes I jump around chapters, sometimes read from front to back.

Reading journal articles, some several times.

Examining good and bad source code written by other people.

Examining good and bad code in open source projects.

Writing code to solve problems (that's where the fun is )

Reusing code I've previously written to address new problems (more fun!).

Modifying code I've previously written to address new problems (more fun!).

Debugging code I've previously written (which can, actually, be a lot of fun).

Reusing, modifying, and debugging code written by other people.

Reading standards, and grappling to understand them.

Contributing to development of some standards.

Teaching and mentoring people who are trying to learn how to develop software.

Formally and informally assessing small and large bodies of code written by other people.

Answering questions in forums, and getting my answers right.

Answering questions in forums, and making mistakes.

Entering debates with other people who, like me, are trying to learn how to develop better software.

Writing compilers.

Writing formal reports about software development.



With all that, the main thing I have learned about programming, and software development in general, is that there is always more to learn.

Everyone has their own way of learning. If you can figure out the way that best suits you ... then you are already ahead of the game.

Assuming you're starting with absolutely no experience:

1. Get a good book. Read it, try to understand it, and do every single example that's given. It's tempting to skim over it with the eye and say, "Okay, this makes sense." But actually punching it into the keyboard and compiling it will give you a better understanding of the code, and make you more used to writing actual code.

2. Tweak what you learn. Take the example code, analyze it, and try to fully understand it. If you have a question about it, don't ask right away, but actually try it and see what happens.

3. Programming is a passion. If you drill through the text, only compiling the sample code, you likely won't learn as much as if you decide to take what you've learned so far and try to code something that is all your own. Yes, much of it (in the early stages of learning) has no practical value for day-to-day things - but you'll learn a lot more this way, and familiarize yourself with programming much more.

4. Help others. Programming is like putting up a wall in some respects - you'll align your sheet rock straight and screw it in proper, but there will always be gaps. By helping others, you'll uncover the gaps in your knowledge and fill it in (code spackling, it should be called).

5. Programming is much more than writing code. As you might imagine, writing code is very important for a programmer. But it's not everything. There is also problem solving and troubleshooting (debugging, in this context). I once wrote a tic-tac-toe program. The mechanics were easy - printing a grid with 'X's and 'O's. But then I had to determine how the computer would "think" - this is where the real challenge of the program was.

The best way to learn is by doing. The most difficult obstacle I've faced is finding programs within my ability to code that have practical value. Fortunately, this very site offers intriguing challenges that the programmer will benefit from learning.

Like everything else in life, practice makes perfect. If you're passionate enough to really want to learn something about programming, then just do it. Do it whenever and wherever you can.

From top to bottom. Ascending order.

You're already thinking like a 'C' program, so you're on the right track =)

Originally Posted by xeon321

Hmm, articles...about what? Security issues? Example : buffer overflow?
Can give me some?

When I say "journal articles", I mean articles in professional and academic publications. Some examples (relevant to those interested in C or C++) would be C/C++ User Group, Dr. Dobbs Journal, C++ Report. More generally, there is a multitude of publications associated with organisations like the ACM (Association for Computing Machinery), IEEE (Institude of Electrical and Electronic Engineers), Elsevier publishers, and others.

Unfortunately, I can't just send you the articles ... most of the journals are subscription based, and I'd be breaching copyright laws if I did. And I can't be sure that the topics I read about would be relevant to you. There is an investment - of both time and money - in accessing publications.

Google scholar is a useful resource for at least finding published articles that are online, although - if you want the published articles rather than drafts, abstracts - you will need to subscribe to (or get your employer to subscribe to) relevant journals.

Hmm, maybe, maybe not. Not sure since I just into programming. I do found answers regarding what is, how pointers work. But I have not found any regarding to "If you use pointers like this, there will be bla3 issues in a more complex program". Like the usage of fflush(stdin), when I am taught using this by my lecturer. He has not said a word that fflush(stdin) is actually wrong. Wish to avoid this kind of problems at the early stage so it won't become a root.

As well as other syntax/references in the C library. I think not all of them are listed out right?

Originally Posted by xeon321

Hmm, maybe, maybe not. Not sure since I just into programming. I do found answers regarding what is, how pointers work. But I have not found any regarding to "If you use pointers like this, there will be bla3 issues in a more complex program".

I'm actually not quite sure what this is supposed to mean. If you stick to using pointers for these things:

• acquiring memory
• pass by pointer semantics in functions
• making data structures like arrays, or self referential structures like lists and trees

You will get the usefulness out of pointers and stay away from cleverness of questionable importance. You will still make mistakes with pointers of course, but trial by fire can be the best way to learn what not to do. And with practice, it sinks in and you just make more advanced mistakes. But by then you learned how to debug!

Like the usage of fflush(stdin), when I am taught using this by my lecturer. He has not said a word that fflush(stdin) is actually wrong. Wish to avoid this kind of problems at the early stage so it won't become a root.

Well it's a good thing that you have a quality reference right?

Another thing is that you might as well actually correct him.

As well as other syntax/references in the C library. I think not all of them are listed out right?

Actually, that stuff is laid out rather technically in the standard. From what I have seen, the standard library and syntax sections are the easiest parts of the standard to actually read. Anyway, people still rely on other things too, such as desk references or man pages, and even compiler documentation.

Originally Posted by whiteflags

Another thing is that you might as well actually correct him.

If you're going to correct a lecturer, learn some tact first. Lecturers have their quirks too. Some don't respond well to being corrected by students, so it is a brave act for a student to correct them, even if the correction is justified. Some are quite happy to be corrected, as long as you make your case. Saying "someone on the internet told me" is not usually a good case. A quote from a reputable textbook is a fair case. A quote from the C standard is definitive ......