How you guys learn programming?

I mean, do you learn it chapter by chapter or straight away into reading source codes and from there if encounters any syntax not known to you/not understand then you look for the right chapter and start reading it?

Chapter by chapter in this case,
C Tutorial - Learn C - Cprogramming.com

From top to bottom. Ascending order.

Read source codes directly, jump from chapter to chapter

And one more, any good starting point for learning the concepts for programming? I found a link Teach Yourself Programming in Ten Years
(Teach yourself programming in 10 years) in a thread. Something like this.

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.

Quote:

---

From top to bottom. Ascending order.

---

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

Note: grumpy used the word "fun" several times, and I didn't use it once. Therefore, I defer to grumpy's post and recognize I did a much worse job explaining programming than they =)

Quote:

---

Reading journal articles, some several times.

---

Hmm, articles...about what? Security issues? Example : buffer overflow? :D
Can give me some? I like reading these. I found some on this site but already finished reading =(

Quote:

---

Examining good and bad source code written by other people.

---

Hmm, I did that, But the standards are way beyond my level. Enjoyed reading the comments though.

Quote:

---

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

---

Yeah, it is fun when you're cracking your head to figure out how to solve problems. But too bad, most of the 'problems' are self-imaginary(in my case, validating user input). And after writing the program, cracking your head AGAIN to think up of an even better & efficient solution :D

Quote:

---

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

---

Uhh, it is ONLY fun after you have successfully debugged the program. The process , is frustrating though. Things get funny when you discovered you're only lacking a semicolon after hours of thinking.

Quote:

---

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

---

Haven't try this. Standard still too low to debug other people's code. =(

Quote:

---

Reading standards, and grappling to understand them.

---

Yup!

Quote:

---

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

---

It's so hard to find people that are willing to do this =(
Most of em aren't on my standard. In my class, people are just not interested in learning or having a deeper understanding.

Quote:

---

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

---

Yes, that's very true indeed!

That's a list very helpful suggestion! Thanks for sharing, appreciate that a lot :D

Hmm, my way of learning is :
For example, I learnt chapter 1 to 3.
I will write a program based on the knowledge I gained on chapter 1. Another for 2 , 3. After that, combine all 3 chapter and write a program again.

Understand the basic concepts to develop basic understandings.
Search up for articles like what to and what not to (can only find some) like, not to use gets, goto etc. It's damn hard to find these articles.
Learn from chapter to chapter.

The problem I facing now is, I don't have an idea where to start for getting deeper into each chapter. Like pointers, any clues? ><

Quote:

---

5. Programming is much more than writing code. 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.

---

This is nice! Need more 'injections' like this ;)

Quote:

---

Fortunately, this very site offers intriguing challenges that the programmer will benefit from learning.

---

You mean the printing pyramid those kind of stuffs?

Quote:

---

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.

---

Yes indeed.

Quote:

---

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

---

Uhh, I'm becoming a machine. That's bad xD

Quote:

---

Originally Posted by Matticus

But then I had to determine how the computer would "think" - this is where the real challenge of the program was.

---

And then you never won a game of tic tac toe again.

Quote:

---

Originally Posted by xeon321

The problem I facing now is, I don't have an idea where to start for getting deeper into each chapter. Like pointers, any clues?

---

I personally am against the idea that everything in programming is a deep, dark, musty cave that needs to be explored. If you are having trouble understanding what pointers are for or how they work, you can find answers to those questions. But really, in my case, after learning the syntax and usefulness of pointers, they ceased to be an interesting subject.

What people seem to wax on endlessly about is objects and object oriented programming. The depth of that topic rivals Lake Superior.

Quote:

---

And then you never won a game of tic tac toe again.

---

Touché, I mastered the stalemate.

Quote:

---

Originally Posted by xeon321

Hmm, articles...about what? Security issues? Example : buffer overflow? :D
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?

Quote:

---

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!

Quote:

---

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.

Quote:

---

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.

Quote:

---

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 ......

Quote:

---

Post: #2

---

O_o

Nope. Nothing to do here...

Soma

@whiteflags

Quote:

---

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!

---

Hahaha, nevermind. I found a site that Matticus mentioned in my previous thread. That's an awesome list!
Hmm, I see. Sure , will play around with pointers until I mastered them.

Quote:

---

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

---

Yup, it is. It's actually on this site.

Quote:

---

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.

---

Hmm, will read into them when I have finished studying all the chapters :D
Well for desk references, man pages or compiler documentation. No idea what is that, won't be bothered with them for now.

@grumpy

Quote:

---

If you're going to correct a lecturer, learn some tact first

---

Nah, don't worry. I'm sure he's gonna teach it in the future. Appreciate your advice still :)

A nice thing to remember when trying to learn Computer Programming, (or anything technical):

Quote:

---

Originally Posted by ???

If you understand what you're doing, you're not learning anything.

---

So, learn and do something new whenever you get an opportunity...and don't get comfortable with a particular level of knowledge.

Quote:

---

Originally Posted by xeon321

Yeah, it is fun when you're cracking your head to figure out how to solve problems. But too bad, most of the 'problems' are self-imaginary(in my case, validating user input). And after writing the program, cracking your head AGAIN to think up of an even better & efficient solution :D

---

Personally, I generally enjoy that process of cracking the head to figure out how to solve problems. But that's because I love learning new stuff, and doing things I haven't necessarily done before.

The thing that a lot of people forget is that software development - if it is done right, and particularly if it is "advanced" - includes a lot of creative and exploratory problem-solving activity, rather than just (at the risk of mixing metaphors) following a cookbook process to recreate wheels. And it is the creative and exploratory processes that I enjoy, whether it is in design, coding, or debugging.

The key to being a really good developer is to embrace the creative and exploratory processes, not to avoid them.

Unfortunately, a few too many product designers and project managers view software as a cook-book activity (in other words, they expect to tell the developers what to do, and expect them to just translate directions into code). But, if you can get product designers and project managers who engage the software people in the creative process, the job is more satisfying, and the products produced also tend to be a lot better.

Quote:

---

But that's because I love learning new stuff, and doing things I haven't necessarily done before.

---

Yes, I agree with you on that. But in my case, I thought up some ideas which I couldn't translate into codes due to it's out of my knowledge.
Thus, I learn and eventually 'translated' the ideas into the codes. Which is why I'm one step ahead from my course mates.

Quote:

---

they expect to tell the developers what to do, and expect them to just translate directions into code

---

Couldn't really blame them, since it is not one man's job. If each team members coding in their own will , the program gonna be real messy when added together.
Creativity is individual, thus not all shares it. But following a cookbook process is a process where every programmer went through together. It will be easier for them I guess.
Just my thought based on what the lecturer has taught me about being a lead/manager.

Here's my suggestion to add to the multitude of excellent ones previously supplied.

Learn how to use your development environment's debugger. Download some moderately sized open source project, compile it in debug mode and step through the code in the debugger. Look at how variables change. Pay special attention to how variables are passed to and from functions. Find someone on the forum with a problem -- especially segmentation faults or access violations -- and full source code provided. Download the code, compile it in debug mode, and step through it (if the poster is complaining of it crashing, just run it and let it crash). At the point of failure, check out the values in the variables to see if you can't determine what the problem is. You'll also learn much about internal structure of the system.

A large, large part of software development is debugging. Getting intimate with this process will go a long way toward your learning.

Quote:

---

don't get comfortable with a particular level of knowledge

---

Oh trust me, I won't :D

Quote:

---

Download the code, compile it in debug mode, and step through it

---

Mm...Yes, I will add this into my to-do list too. A good suggestion indeed. Thanks :)

Quote:

---

Originally Posted by xeon321

Couldn't really blame them, since it is not one man's job. If each team members coding in their own will , the program gonna be real messy when added together.

---

I think you're misunderstanding my point. I'm not arguing for anarchy. The team needs to work in a systematic manner, follow appropriate design and coding guidelines, etc etc. But those need to shape creativity, not eliminate it.

Quote:

---

Originally Posted by xeon321

Creativity is individual, thus not all shares it.

---

Every individual is creative in different ways. A team of creative people, however, will not be creative unless all of the individuals within it work toward a common goals. It will also be less creative if creativity of some team members is suppressed.

The phenomenon I argue against is people in certain roles (project manager, system architect, product designer, etc) insisting that the only creative work is done by them, and all the software guys have to do is build what they are told to.

Quote:

---

Originally Posted by xeon321

But following a cookbook process is a process where every programmer went through together. It will be easier for them I guess.
Just my thought based on what the lecturer has taught me about being a lead/manager.

---

As I said above, I am not arguing for anarchy. There are always certain processes, policies, and standards that need to be adhered to.

However, there is more to being a leader or manager of a software team than dropping a set of coding standards, a gant chart, and a set of directions on the table, and expecting the programmers to "just code it up". That sort of approach, which is VERY common in the industry, tends to result in unproductive and grumpy programmers.

Sometimes there is not flexibility of choice. For example, in safety critical system development, it is often necessary to follow restrictive processes and produce certain documentary evidence that the system design and implementation provides appropriate mitigation of hazards. But, put arbitrary constraints on a team without a good reason, the creativity will be stifled.

One of the constraints often put on a team is that the software guys are denied necessary creative opportunity by other team members who deem the creativity to be their territory.

Ah, sorry for my misunderstanding. I get you now. Yes, I won't be pleased too if my lecturer ordered me to code according to his directions only.

Hmm, in your opinion, why would the project managers/leaders restrict the software developers?

Quote:

---

Originally Posted by xeon321

Hmm, in your opinion, why would the project managers/leaders restrict the software developers?

---

Human nature.

People put in positions of authority often like to exercise that authority. Sometimes they do that by constraining others. Pure power game.

A lot of project managers or team leaders have not been in the trenches of software development. They have learned basics of some language or process in a course somewhere and assume that means they know all of it .... so they don't accept deviations from their way of business.

Sometimes it is fear of the unknown. Letting a team go ahead with the creative elements of the job makes it difficult to measure progress. That makes it hard to report progress to stakeholders who hold the purse strings (accountants, CEO's, clients, etc). This causes managers and leaders, whether they have experience with software or not, to suppress creativity of their teams because that is the path of least resistance.

I remember one project manager for a very complex technical system who took pride in the fact he had no knowledge of "ones and zeros" (his description of the details that he described as too low level to be relevant to anyone). That project failed in a spectacularly expensive manner after the project manager was promoted.

Customers of a software development team are often only interested in the externally visible behaviour of the software (GUI, the actions of devices the software controls, etc). They have no interest in the details of HOW the software achieves those visible things.

There are many other reasons. Also bear in mind that - contrary to what a lot of managers claim - management is not the same thing as leadership. Management is about managing resources and measuring progress toward outcomes. Leadership is about motivating people.

To show their power, agree.

For better, less risky way to get things done, yup, a manager whom don't have confidence in the software dev team's job. But o'well, like you said management is about managing resources and measuring progress toward outcomes.

Yes, customers are only interested in the final product. They paid, they expect they get something nice and easy in return, who doesn't ? :D