Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm learning new languages as I go along, I write code for very basic programs in multiple languages, and I go to classes. I've read books, articles, lessons, videos, you name it, however I can't seem to get the hang of certain things.

For example I never understood pointers - what they are good at. (NOT PART OF THE QUESTION - retagging with "Pointers" is not required...)

My question however, is not what pointers do, but instead how can I understand things like that? If, after reading a book or an article about a certain part of programming, and I don't understand, what do I do? Writing code in a certain feature of programming surely helps, however it doesn't actually help with understand that much. The theoretical part is important in understanding.

share|improve this question
I wish I could understand why people have so much trouble understanding pointers. The name gives all the clarification I need. –  ChaosPandion Feb 28 '12 at 17:16
Some Computer Architecture 101 course would help greatly with understanding pointers. ...and everything else. –  ZJR Feb 28 '12 at 17:16
The question is not exactly about pointers, it's a general question, but thanks. –  Bugster Feb 28 '12 at 17:18
I don't think reminding the guy of the one example he confessed to have problems with will help him one single bit towards enlightenment... Done often enough, it will however prevent him from asking for help out of fear of getting hit buy a long string of stingy and pedantic answers and downgrading comments. –  haylem Feb 28 '12 at 17:39
@FrustratedWithFormsDesigner: "How do I learn to learn", I think. Which is a valid and valuable question. –  haylem Feb 28 '12 at 19:05
show 11 more comments

closed as not constructive by Jarrod Roberson, ChrisF Feb 28 '12 at 22:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

11 Answers

up vote 21 down vote accepted

If you have troubles with understanding an abstract concept, just go one level down. If you cannot get the pointers in C - go down to the assembly level. Still having problems? Learn more about the hardware, all the way down to the logic gates.

share|improve this answer
+1: Worked for me. I had trouble with pointers in ALGOL until I started writing PDP-10 assembly language. –  kevin cline Feb 28 '12 at 17:35
Interesting idea. Though I would point out that writing and running a program in assembly is going too far. In my opinion, going beyond the point of basic understanding is unnecessary at this level. But hey, if that is what you want to do, more power to ya! –  George Bailey Feb 28 '12 at 17:40
@George Bailey, yes, it might be a bit over the top for any real assembly and real hardware. That's why there is MIX and other similar toy architectures around. For a hardware part it's the same - there are many simple, toy CPU cores to study. –  SK-logic Feb 28 '12 at 17:59
+1: Interesting idea and definitely likely to work, but (to re-use the OP's example case) going down from C entry-level to ASM entry-level might be a long, hard and winded road for a beginner, likely to take more time than anticipated by the course/project/other. It may also alienate poorly motivated people (which is probably not the OP's case, but from a higher-level perspective, this would block a lot of students who take CS classes and need to understand this but do not give a damn about CS itself). But definitely a good idea for the long term. –  haylem Feb 28 '12 at 18:53
Well, my CS degree covered this in Computer Architecture. We learned about logic gates, combined them in a logic simulator to build adders, ALUs, and eventually a very simple RISC CPU. We also wrote simple programs in MIPS assembly. This was all required for a BS in computer science, and wasn't really considered one of the "weeder" courses, so I don't think it's over the top or going too far. –  Adam Jaskiewicz Feb 28 '12 at 19:59
show 2 more comments

Short Incremental Learning Lifecycle

  1. Try and fail to understand the concept.
  2. Try to implement something illustring the concept.
  3. Try to diagram the concept on whiteboard (if applicable)
  4. Try to talk it through with someone who understands the concept.
  5. Try to explain the bits you understand to this person (helps to see the light, sometimes).
  6. Re-start from 1 until you can finally explain it to someone who is in state 1 and make them get it.

Additional Steps

To use with caution.

  • Search for additional reading and study material:
    • online (popular search engines and Wikipedia are great friends),
    • at the library (don't underestimate books, and the people who go there to read them),
    • on your system (bundled documentation and doc tools are often alienating at first, but your best goto-buddy after a while: learn to find what you are looking for in them. e.g. man -k, apropos, etc...)
  • Try read some code using the concept ...
  • ... and step through the code with a debugger.

These are sneakier as you need to re-evaluate yourself to ensure you got it right. Direct mentoring by a knowledgeable person is usually better, followed of course by your own validation of the acquired knowledge by re-implementing what you just learned (and by then trying to push it one step further and learn a higher-level concept built on top of that one, e.g. linked lists for your pointers).

Credits: Nupul (for diagraming)

share|improve this answer
+1! May I add - before talking, try the Whiteboard to 'sketch it out' (or just keep whiteboard in handy when talking to someone :) –  PhD Feb 28 '12 at 21:33
+1 for "step through the code with a debugger". I have learned about many concepts with simple debugging tools... –  funkymushroom Feb 28 '12 at 21:49
@Nupul: good suggestion, added. –  haylem Feb 28 '12 at 23:40
@funkymushroom: Indeed, though I'd say that usually you don't really learn the concept this way. It does however help to "lift the fog" when it's right in front of you and you just couldn't see the pieces come together, because you're too focused on something or your mind is fried. I find it more helpful to understand general algorithmics problems than for general concepts. –  haylem Feb 28 '12 at 23:55
add comment

In my experience, it's all about input and feedback. You want to get input in as many forms as you can, and feedback on your mistakes as quickly as you can.

In my experience, my CS degree was very dry, very formal, and utterly worthless at teaching any programming whatsoever. I attended two-three lectures a week and if you don't get it then that's pretty much it- the lecturer has another class to teach and can't stick around to help you. And, odds are, that one guy understands it in a certain way, and he will teach it in a certain way and that's it, so if you don't think like him, you will never ever get it. What's worse is that since he likely understands a billion other related concepts, he will likely frame it in terms of those other concepts, which may well be way over your head or simply not even in the course material.

I went to Stack Overflow and asked in the C++ chat channel and got five different explanations in five minutes. They were all tailored specifically to me and the exact problem that I had, so it's no surprise that one of them struck home for me and I got it. The rate at which you can learn from getting live feedback from multiple experts is vastly in excess of what you can get from a dried-paper source.

So ideally, take a break, and then you would find a small to mid size group of like-minded people who have nothing better to do and chat with them live. By the way, Stack Overflow is an excellent place to get this kind of high-quality high-speed personal feedback.

share|improve this answer
add comment

In no order, books, friends, and reading well documented code are good sources. Practice is the only way to learn: try to write small unit tests. For example, for pointers write code that deal with strings: reverse a string, reverse each word in a string, test for palindrome, replace a letter with a number...

Ask questions on stackexchange... ;>

share|improve this answer
add comment

Practice makes perfect! (well better anyway). Just keep trying and try to use as many different sources and senses as you can:

Sources: Books, Internet, UserGroups, friends, Video Learning, using sites that let you test little 'bit' of code like jsfiddle (mostly html),
Rubular (Ruby expressions),
SQlzoo for trying out sql,
jslint for javascript,
code pad for many languages.

To remember abstract things consider mneomics - Doctors use them!

Consider yourself a life-long learner and stay humble and you can go far.

share|improve this answer
+1 for “practice”. But mnemonics, ugh. They are a very insufficient crutch that can never replace, and should never supplant, understanding. In fact, they mark the absence of understanding. “Doctors use them” because they are forced to learn too many disconnected facts in too little time. We are slowly coming around to the fact that our education for medical doctors sucks, and the USA for instance is well on its way to completely remodel the education. Mnemonics are not a solution, they’re part of the problem. If you find yourself using them, you failed to understand. –  Konrad Rudolph Feb 28 '12 at 20:58
add comment

You have to change your focus for a while, not 5 min. or 5 hours...I mean something like 1 day without looking at that code....just chill about it...go read something different...

If you have to understand it now...ask for help from friends or here =)

share|improve this answer
add comment

What everyone else in IT does.

I use a search engine to look up the related concepts I don't understand until I can revisit the topic I initially wanted to understand.

Chances are you also don't fully understand the stack, heap, automatic variables, the C++ compilation process, assembly, managed memory vs unmanaged memory.

More clarity on these and other pointer related concepts would probably clear everything up.

share|improve this answer
add comment

There's no sure-fire quick way to understand a subject matter. Your success depends on how much context you bring with you in your studies. You'll be very lucky to find someone who will explain things with your point of view in mind. Like Turing machines, anyone can learn what others know, and it's just a matter of persistence and acceptance that frustration is natural.

I remember the immense difficulty I had with pointers. It wasn't until a very patient dude explained it to me like I was a complete idiot that I understood it. That's sometimes what it takes.

share|improve this answer
add comment

This is a common problem in learning and teaching. And as others have said, there is no sure way to work around this. It’s a fundamental truth that we all learn differently since our brains are wired differently in subtle but crucial ways.

Learning generates new neuronal connections. Without going too much into neuroscience (which I know next to nothing about), generating new connections requires different kinds of exposure to a concept for different people. Try many different angles, read / hear / watch different explanations. Practice!

If that doesn’t work, put the problem aside: you might simply be missing another part of the puzzle that, once acquired, makes the original problem seem obvious.

Do you know these aha! moments? This is when your brain just made a new connection. This is how learning happens.

Incidentally, any good teacher knows this. Guidelines for technical writing often state that every concept should be explained at least twice, using different words (and perhaps with some text between them). If you pay attention you will be able to spot that all the good science writers follow this rule.

Alas, all too many teachers ignore it, and explain things only once. And even if they succeed in finding an elegant explanation with a great metaphor this simply isn’t enough.

share|improve this answer
add comment
  1. Read any relevant documentation and Google your doubts.

  2. Try writing code examples, see what they do.

  3. Try executing code in debug, and watch it step by step.

  4. If you still don't understand a certain behaviour, ask someone, either in person or in a website like this. If you tried all of the above, you should have all the elements to compose a good question. Don't be shy :)

I think it is pretty much what everyone else does.

share|improve this answer
add comment

Keep researching and learning. I have had the same problem with various other aspects of programming. But talking to others and reading articles eventually leads to an "AHA" moment. Generally, it is some other Blog post or SO answer that presents the information that I am able to follow.

Basically, keep looking and be patient for the understanding to come.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.