Tricky Programming Concepts Aren’t

http://evincarofautumn.blogspot.com/2011/09/tricky-programming-concepts-arent.html

by evincarofautumn • 15 years ago

185 92 15 years ago

evincarofautumn.blogspot.com

Apocryphon• 15 years ago

It's good to see someone bluntly take apart common misconceptions.

evincarofautumn17• 15 years ago

My pleasure. It's good you find it blunt: I tried to be concise so people would bother reading.

nasmorn• 15 years ago

tl;dr Programming is not as hard as people make it out to be.

xlm• 15 years ago

Agreed, that was refreshing (and affirming).

As the great teacher, Richard Feynman puts it: "if you can't explain something to a first year student, then you haven't really understood it"

danso2• 15 years ago

Doesn't this underscore the argument against the OP? If Feymnan is correct, this means that many CS teachers don't really understand these concepts that they tell their students to be "tricky."

So, if numerous professionals are having trouble understanding a concept - or, they believe they understand something when they really don't, which is actually worse - then that seems to me to be empirical evidence arguing that said concept is probably difficult.

And of course you can make the argument that it just happens to be the case that these concepts are easy and society has just happened to promote a bunch of morons into professional positions, but I think that is the more difficult hypothesis to prove.

BrianHV3• 15 years ago

I'm on board with his basic pedagogical point: don't tell people you expect them to struggle.

I'm concerned that he's going a little too far in the other direction, though. It's great to come up with a simple or even tautological explanation for concepts. However, those explanations don't address the nuances of why those concepts challenge people in practice. And telling someone it's easy when s/he actually is struggling is just as dangerous.

When I was learning C, I absolutely understood that a pointer pointed to something, and I wasn't bogged down by people telling me it was hard. That didn't stop me from dereferencing null pointers, returning addresses to variables on the stack, getting confused when someone added to a pointer, etc. The aptitude that Joel wrote about and Jon derides isn't the aptitude of applying a metaphor to code. It's the aptitude of coalscing a set of program behaviors into a mental abstraction that is more than "a pointer points."

evincarofautumn17• 15 years ago

My point is that a memory reference is a conceptual reference. There is no difference. Understanding references is not about building abstraction atop your understanding of them; it's about recognising that you can express natural abstractions literally through them.

BrianHV3• 15 years ago

I'm unclear on what it means to "understand references" in a way that doesn't involve the way they behave in code. Unless you're saying that the concept as it appears in code can be explained entirely with the tautological definition, in which case I would be inclined to disagree.

Of course, I'm also not sure that Joel's suggestion that some people have an aptitude for such understanding is "irresponsible." If you were to say he underestimates what people can pick up with practice, that would be a different story.

eykanal• 15 years ago

I agree with this completely. It's one thing for the concept itself to be hard to understand. It's another thing for the concept to be simple, but proper execution to be tough, frustrating, and prone to error.

Hyena• 15 years ago

This is a really important distinction; I see a lot of people claim they don't understand something because implementation is hard. Sometimes implementation is just hard. They should note this more often in schools rather than taking an extreme position of self-esteem/whatever.

SomeCallMeTim2• 15 years ago

I spent hours trying to help a friend in college "get" enough assembly language to not fail a class. I had already done assembly language development professionally and had previously gotten an A+ in the class, so I understood the concepts well, and I explained them from a dozen different directions.

I don't care what the OP says. This guy was simply not capable of understanding the concepts. Maybe at some level he was, and he had some kind of psychological blinders on that prevented him from getting what I was saying, but he really, really didn't get even the most basic concepts. And when it comes down to it, it doesn't matter whether he has some innate ability that he can't tap -- if he can't do it, even with lots of help, then he can't do it.

While I was helping him, others from the lab came over repeatedly to ask me for help, assuming I was the lab assistant. I WAS able to help a half dozen other students understand their program.

It was his third attempt at taking the class. He finally gave up and changed his major, IIRC.

qqspy• 15 years ago

Was it x86? That's a darn shame if so. I'm not sure /I/ could learn that, and I have used several simpler ones.

qntm• 15 years ago

Of course, there are plenty of actual tricky programming concepts: closures, tail recursion, coroutines, memory management, concurrency, regular expression matching, caching, algorithmic complexity, naming things...

evincarofautumn17• 15 years ago

And you've just given me an idea for my next article. :)

gatlin3• 15 years ago

Another commenter made a great point that knowing how and when to use these things is likely more difficult, but having a good grasp of the concepts is important. Here is a minute of me stabbing at analogies:

Coroutines: A subroutine is a basement which you go down into and come up from via the same door. A coroutine, by contrast, is an adjacent room with several doors and you can leave temporarily even if you're not completely done in there (of course, you must re-enter whichever door you previously left; not a perfect analogy).

Concurrency: doing multiple things at once. In a kitchen, concurrent actions work best when the cooks either don't share resources or have clever schemes for ensuring there is always an alternative activity to perform if resources are in use. This can be as simple as getting on a list for the knife, or blender, or what-have-you, and you'll be called when it's open.

Caching: I dislike going to the grocery store every time I am hungry so I cache things I will need to make shorter trips on average. How much you cache at once is important to determine.

Regular expression matching: This isn't what I'm trying to find, this is a description of what I'm trying to find.

mark_story• 15 years ago

Great explanations.

evincarofautumn17• 15 years ago

Coroutines are more like reading multiple books, leaving bookmarks behind and returning to them as needed. I think of caching like moving the resources you're working with to be near at hand so it takes less time to get to them.

(When you're painting, for example, you keep pencil, eraser, brush, paints, and palette nearby, because they're in active use and it would take awhile to fetch them every time you needed them.)

Your other examples are great though. I worked in a kitchen for a couple of years and it's definitely all about concurrency.

bostonOU• 15 years ago

Just last night I was explaining regular expressions to my fiancée who has absolutely no programming experience. I just showed her some fundamentals:

1) '[\d]' means any digit

2) '+' means one or more

3) '[\d]+' means one or more digits

Understanding that is not hard or tricky at all. Using that to build a complicated regular expression is hard.

I think that's the author's point. Understanding the concept of a pointer or recursion is not hard. Actually using those concepts to build something takes practice and hard work.

edit: formatting

gcv• 15 years ago

Honestly, most of the concepts you listed are fairly easy. They mostly apply to the mechanics of writing code, so they just require a bit of thought.

Problem solving is difficult. Recognizing how to apply dynamic programming is difficult. NP-completeness proofs are difficult.

matan_a2• 15 years ago

Interesting article and it does go a good job of explaining these basic concepts.

But...

There is a huge difference between understanding something and knowing how to implement that knowledge properly in the real world. The former is a building block for the latter, but just the understanding of what pointers are or recursion is doesn't dictate someone's ability to use them properly or efficiently.

evincarofautumn17• 15 years ago

True, but understanding goes a long way toward practical skill.

matan_a2• 15 years ago

you are definitely right about that

RyanMcGreal• 15 years ago

> This is exactly like the process of essay writing

Indeed. I find that essay writing and programming light up exactly the same parts of my brain.

adbge• 15 years ago

I'd love to see more programming abstractions described in simple, no nonsense terms. I think that, as programmers, we often get so used to our own jargon that we unconsciously create a non-trivial barrier to entry.

For extreme examples, try digging into some of Haskell's features -- I still have no idea what arrows are, but I've been given the impression that they're advanced and hard to understand -- or reading some of the discussions on Lambda the Ultimate. It usually turns out that the concepts are surprisingly simple, but it takes a lot of sifting through academic language to figure it out.

theFco• 15 years ago

In my case I think it is after "a lot of sifting through academic language" that I get a cool idea through my thick skull. Academic language is (or should be) about being precise not obscure. What I am trying to say, is that learning takes time. The simple, no nonsense terms resonate in your mind after you really grasp the concept. Otherwise it's just a high level overview that won't allow you to really use the concept.

SkyMarshal2• 15 years ago

If you learn something like haskell from books instead of blogs, the explanations are usually much much more comprehensive and cogent. Both Learn You a Haskell and Real World Haskell are excellent in that respect.

I find more and more that blogs are great for discussing things you already have deep knowledge of, or of finding leads to resources for learning them (book recommendations, etc.), but there's no comparison to books for really learning something well.

Blogs are just too piecemeal, and the articles are usually written in a few days or a week, versus up to a year or more for books. Hence the quality of pedagogy is just much higher with books than blogs.

evincarofautumn17• 15 years ago

I found Learn You a Haskell unexciting; it was more useful for me to hang out with my Haskell-programming acquaintances, read a lot of code, and get my hands dirty using it than it was to just read and play with examples.

Even as someone who writes a technical blog, I'll agree that blogs aren't the best medium for disseminating learning materials. That's what proper online documentation and books are for: specialised topics, in long form. I can write 50 1000-word blog entries and help people on more topics, but fewer people per topic, or I can write one 50,000-word book and reach many people on just the one.

dkersten• 15 years ago

It is usually assumed that if you are discussing something on Lambda the Ultimate, that you already understand the jargon and by using it, you are using a language that everybody (the target audience - in this case, language lawyers and language enthusiasts, I guess) understands and is well defined.

Sure, they could use terms that are easier to understand to the uninitiated, but then you risk having to explain your terms every time because people use different ways to refer to the same thing. Jargon evolves precisely to solve that problem, at the cost of making it harder for somebody new to understand.

Obviously when learning these things, you need a clear and easy to understand description of the terms, but as others have stated, a book usually does this, while blogs and research papers probably assume you already know whats what.

sliverstorm• 15 years ago

Has the author ever tried to teach anyone pointers? Who had never heard of them before? I've introduced several people to pointers, and while they aren't "hard" in the sense that it takes them months of hard labor to understand, there's a reason they have the reputation they do.

I personally love pointers, and have a bad habit of trying to do my own memory management with them.

evincarofautumn17• 15 years ago

Yes, I tutored CS in C++ for a few years, and near-tautological explanations like these seemed to work best to cut through the explanations of the professors. I like to think I've helped create a good programmer or two. In general the profs were trying to be strictly correct, at the cost of explaining things in terms that their students would actually understand.

matwood• 15 years ago

IMHO, the only problem with teach pointers is that professors try to dress them up. Not understanding a pointer typically means not understanding the basics of the underlying hardware. This touches on one of the common problems today is that software has been split away from the hardware that runs it.

I'm certainly not saying that anyone who writes software needs to know the ins and outs of a modern CPU, but basic knowledge of how a computer works (memory, CPU, DMA, mmio, etc...) is what's often missing when talking about low level programming concepts.

rflrob• 15 years ago

This seems to be creating a false dichotomy in the original argument. It's not that there are some people who can't understand concepts like pointers and recursion, but having taught programming to several crops of complete neophytes, I've discovered there are some concepts that some people get right away, and others don't[1]. My response to this isn't to write off the people who don't get it, it's to work harder with them, but that doesn't change the fact that given two people with the same explicit programming background[2], and exposed to the same lectures, a fraction of them will need further work. It's this kind of concept that I call tricky.

[1] I'll fully grant the possibility that I'm teaching them in a sub-optimal way. But very few people have the luxury to learn from the optimal teacher.

[2] It's conceivable that some people have had experiences and training that, while not formally programming, have nevertheless taught them the abstraction and logical reasoning skills that are necessary to understand core programming concepts.

rhizome• 15 years ago

Valorizing the optimal case is not a safe strategy.

MaxGabriel• 15 years ago

He's not creating a false dichotomy to attack--he's responding to Joel Spoelsky's post, and Spoelsky creates a very clear dichotomy of smart and not-smart in his post

"I've seen that the 100% Java schools have started churning out quite a few CS graduates who are simply not smart enough to work as programmers on anything more sophisticated than Yet Another Java Accounting Application, although they did manage to squeak through the newly-dumbed-down coursework...I used to be able to tell the smart kids because they could rip through a recursive algorithm in seconds, or implement linked-list manipulation functions using pointers as fast as they could write on the whiteboard. But with a JavaSchool Grad, I can't tell if they're struggling with these problems because they are undereducated or if they're struggling with these problems because they don't actually have that special part of the brain that they're going to need to do great programming work. Paul Graham calls them Blub Programmers."

astrofinch• 15 years ago

I've done a fair amount of one-on-one programming tutoring both for friends and family and for pay. In my mind there's no question that the variation in the speed with which people pick up programming concepts is quite significant.

chrismealy• 15 years ago

OK, instead of saying "this is tricky" people should say, "this will take some practice." I got pointers right away but it took a lot of practice to use them without error.

evincarofautumn17• 15 years ago

I like that. It's not "you can't", it's "you will have to work".

lutorm• 15 years ago

The author completely missed the point about why teachers say "this is tricky". It's not about telling students to pay attention, they do that if they want. And it's certainly not about telling people it's so hard they need not bother.

It is to make it OK for students to not understand right away and not feel bad about asking questions.

evincarofautumn17• 15 years ago

I was trying to be brief, but that is essentially what I meant to say...perhaps I'll edit to clarify that. I think the effect is still the same, though, regardless of the motivation behind the phrase.

waqf• 15 years ago

Since even the most high-level concept, explained correctly, can be absorbed and applied by any person of average intelligence, I will be very interested when the author (or, y'know, anyone) posts such an explanation of motivic cohomology.

aidenn0• 15 years ago

Experience has shown me that there are people who just won't get these concepts. I don't know if they decided it was hard and gave up or what.

Example: Shortly before a final exam for an undergraduate introductory course on logic, there was a student behind me who said "I still don't get this De Morgan thing"

This was something that was covered in the first week, it was impossible to do about 90% of the work in the class without it and has got to be at least as obvious as pointers and recursion. The student was trying in the class and went to office hours, study groups, etc.

I still don't have a good explanation for how someone can't grasp De Morgan's laws in under an hour, much less after 16 weeks of class.

eeperson• 15 years ago

I don't think the difficulty stems from an inherent inability to learn a concept. I think the difficulty occurs largely because of two factors: lack of interest and intimidation.

Have you ever had to read something unfamiliar that you found incredibly boring (think reading a patent application)? You end up reading the same page over and over but you absorb very little of the information. Your mind just moves through the words but doesn't make the effort to understand what was being read. This occurs simply because you don't have enough interest in the material at hand.

Seeing how intimidation can factor in this is a bit more difficult. You can usually see this by watching someone try to solve something that they think they can't solve. A lot of times people in this situation make a lot of half hearted a attempts but rarely follow through. I think this is similar to how people struggle when they are put in a situation where they need to make a really open ended decision and get overwhelmed by the options.

Edit: clarity

kenjackson2• 15 years ago

A pointer points. A reference refers. These are the same thing.

Except they aren't the same thing in many programming languages. In particular C++.

To implement a linked list, just open your eyes and think about what the term means: it is a list, and at each place there must be a thing, and the address of the next thing if there is one.

This is one example of a type that you probably won't use a reference in C++ (at least not a mutable linked list).

The thing the author did was actually swapped out one analogy for another, although unknowingly. To really get away from analogy is to point out that there are values stored in memory locations (determining the value uses metadata associated with memory locations). You can use those values literally, or you can use them as an index into other memory locations -- and then recurse (to tie both concepts together).

evincarofautumn17• 15 years ago

A pointer is a particular kind of reference (a value type that enables indirection), and C++ references are another (not very different) kind. A reference in C++ amounts to an immutable pointer.

Also, I didn't swap analogies: I traded analogy for metaphor. (A reference in a computer program is a conceptual reference in the real world.)

esrauch2• 15 years ago

> A reference in C++ amounts to an immutable pointer.

"Amounts to" is a phrase that lets you say pretty much anything. Eg: A pointer amounts to an int.

If you are going to say that it amounts to an immutable pointer, you should at least add a caveat about how int *const x; would be different from int& x;

kenjackson2• 15 years ago

A pointer is a particular kind of reference (a value type that enables indirection), and C++ references are another (not very different) kind. A reference in C++ amounts to an immutable pointer.

I think you're beginning to walk that line where people start getting confused -- "I thought you said they were the same thing. Now you're saying they amount to some modified version of what you said?"

Also, I didn't swap analogies: I traded analogy for metaphor. (A reference in a computer program is a conceptual reference in the real world.)

I'm no grammar buff, but that seems to be walking a fine line. From my most recent CS SAT test:

reference::computer as conceptual reference::real world

In any case, many would argue that metaphor is equally dangerous. Djikstra has ranted on this very topic, saying it creates dangerous visualizations.

My point is that there is way to teach the concept relying on neither analogy nor metaphor, but a more basic concept of how data is stored. I think you'll find different students will react favorably to different techniques.

cube133• 15 years ago

>A pointer is a particular kind of reference (a value type that enables indirection), and C++ references are another (not very different) kind. A reference in C++ amounts to an immutable pointer.

A pointer is a memory address. That's all it is. It can contain any valid memory address for the system.

A C++ reference is essentially a hard link to another declared object. As far as the compiler is concerned, a reference to an object is the object, and therefore has all the attributes that the original object has.

Pointers are like a house street addresses. They do not directly allow the user to see anything about the house, but they tell the user where the house is.

References are like what people call a certain house. I may call the house I live in "home", but my friend Bob may call it "cube13's house". Both myself and Bob use different terms for it, but we both mean the exact same physical location.

msluyter• 15 years ago

I'd like some actual empirical evidence that saying "this is tricky" or "this is difficult" actually de-motivates ("turns off") students. It might, but I can also plausibly imagine the reverse. What if you say "oh, this will be easy and fun!" and then they have trouble with it? IMHO, that might send the message that they're just dumb. At least when you say "it's tricky" and they struggle they may not think it's their fault and might be willing to keep trying.

I think you could spin a lot of plausible pedagogical theories, but I'd be more interested in seeing some actual evidence.

mechanical_fish2• 15 years ago

I'm sure it depends crucially on the student.

The other thing to remember is that teachers speak to roomfuls of students at a time, not one student at a time. If you've got one student, then sure, you need never explicitly say that a particular concept is tricky. You can determine trickiness by trial-and-error: If the student gets confused at any point, explain again, but otherwise just keep going.

But with a whole roomful of people it's not as if you're going to fool them by avoiding the word "tricky": They're going to know when you cover something that is tricky, because half the audience will be confused, and the other half is then going to have to observe you explaining the tricky thing over and over again to the first half.

sp332• 15 years ago

If you tell someone that a simple concept is difficult, they will have trouble understanding it. I have seen this firsthand many, many times.

evincarofautumn17• 15 years ago

I'm just citing personal experience. I would be very interested to see studies that clearly backed up or refuted my perceptions. The real machinery at work is probably more interesting than I imagine, and definitely more interesting than I make it out to be in the article.

xyzzyz• 15 years ago

It's just like the whole "engineering is not for women", which successfully discourages girls from entering technical fields.

rcfox2• 15 years ago

I thought so too, but after refreshing my memory, I think it might be similar, but not exactly the same.

http://en.wikipedia.org/wiki/Stereotype_threat

pasbesoin• 15 years ago

I think "this is interesting" might be a better introduction.

Also, in my experience, when people (especially teachers and professors) say "this is tricky", it is often in part or in whole because they are only giving you a partial explanation -- part of the picture.

It's "tricky", because they are telling you to accept certain things prima facie when actually (for me, at least) they'd make a hell of a lot more sense and be easier to absorb with a more complete description/explanation.

Some of the time, this is because they don't really understand the topic themselves. Other times, one or another pedagogical inclination or requirement makes them avoid a deeper discussion. ("I don't have time" or "We don't have time" or "That's beyond the scope".)

dorian-graph• 15 years ago

> What if you say "oh, this will be easy and fun!"

That is same problem as saying "Oh, this is hard and tricky." The author didn't seem to suggest to tell students things are easy, which is misleading and harmful, but rather he used the example of art teachers where the students are not told that things are easy but rather they need to practice and put in a lot of effort. Hell, he didn't say the word 'easy' once in his blog entry.

Lecturers and many others seem almost afraid to say "You're going to have to work hard." and then stand by that statement.

I'm currently at university and I've seen exactly what he has said. Lecturers and students saying x is hard and tricky and for most of the other students here that seems to have demotivated them. I think the current schooling system here in Australia and in other countries in the world where I've spent time or have friends from is horribly flawed in many ways and what this blog entry about is just one of those flaws.

rytis• 15 years ago

I wonder if any of that has to be said at all? What if a lecturer did not set this prejudice upfront at all? However helpful emotions are in the learning process, saying "this is tricky" or "this is easy" is not going to help. Instead, play on other emotions. Explain the theory, show real life examples, simple tricks, stuff like that, surprise them. But don't say "this is hard" or "this is easy". Let them decide.

pyry• 15 years ago

This is the common wisdom in language pedagogy as well, however I haven't heard any hard evidence either. Would love to.

pkaler• 15 years ago

You should read Flow by Mihály Csíkszentmihályi. Flow is defined as completely focused motivation. http://en.wikipedia.org/wiki/Flow_(psychology)

The research states that flow is achieved by balancing skill and challenge. http://en.wikipedia.org/wiki/Flow_(psychology)#Mechanism_of_...

With respect to the original author, it sounds like he hasn't been far enough along in his career to be humbled by a hard problem.

georgieporgie• 15 years ago

A queue is a queue of things.

On an only vaguely related note, this reminds me of something from college. I was helping a friend of mine who was taking an intro to programming class. It was in C++, and he had been given a class outline for a queue, and was required to fill in the implementation. I was horrified to find that the teacher's class declaration used method names "NQ" and "DQ".

I honestly question whether the instructor even understood the meaning of the word 'queue' and how 'enqueue' and 'dequeue' are derived. It was obvious that this cutesy shorthand completely obliterated any hope of my friend ever making the mental connection between the code and what it conceptually represented.

(Incidentally, they also taught C++ streams for I/O. Apparently, their goal was to prevent new programmers from succeeding)

radagaisus• 15 years ago

Let me get this off my chest: pointers are NOT hard. If every 16 year old with weed can talk about representation and meaning, every CompSci student can grok pointers.

Managing code with pointers is hard, but grasping the concept is easy.

Closures are far more confusing.

I didn't learn regular expressions for a very long time because people said they were hard. That was stupid. It took me a couple of days to get good at them.

mechanical_fish2• 15 years ago

Thanks for the excellent introduction to my next topic: An important function of programming education is to teach people which things other people often find difficult. Because intuition is not a reliable guide. And the secret to all effective communication -- which certainly includes programming, as well as writing and teaching -- is to write stuff that your audience can understand.

When the teacher says "this is tricky", consider the possibility that they aren't merely trying to motivate the students. It might just be a simple statement of fact: There's a significant population that doesn't get this at first glance, and you have to know that, regardless of whether you get it yourself or not.

regularfry2• 15 years ago

> Thanks for the excellent introduction to my next topic: An important function of programming education is to teach people which things other people often find difficult.

Why? In my mind, managing student psychology is more important than conveying meta-facts. If a student will learn slower if you tell them that other people find something hard, then don't tell them that. As a bonus, the meta-fact might become less true.

Natsu• 15 years ago

> I didn't learn regular expressions for a very long time because people said they were hard.

I learned to use them long before I had any clue what a DFA was or had even heard of an accepting state. It was pretty intuitive to me that you just have to specify these patterns and it would match whatever you told it to.

When I later read more about the theory and how they were constructed in a compiler book, I wouldn't have been able to decipher a word of it if I hadn't already known how they were supposed to work.

I wonder why more books don't show you what they do before showing you how they're made.

georgemcbay• 15 years ago

"Closures are far more confusing."

IMO (obviously this is subjective) this is not true but it depends upon whether you mean confusing to use or confusing to understand the full implications of a thing under the hood.

Closures are pretty easy to start using for just about any halfway decent programmer if you lay off the theoretical underpinnings and just show them: here do this, and this will happen. Actually understanding how they function is another matter, but to just start using them is fairly simple assuming the language you are using supports them natively.

Pointers on the other hand are a fairly simple concept and unlike closures there is really no depth to the concept, but because most people's brains don't deal well with indirection beyond one level, pointers are very "tricky" when it comes to training your brain on how to use them correctly even after you understand the concept.

Closures are easy to use, hard to grok; pointers are easy to grok, hard to use, so which is more confusing depends a lot on what you mean by confusing.

msutherl• 15 years ago

lol, I love the guy who commented: "Awesome post. Now do monads please?"

stonemetal• 15 years ago

Monads are a lot like pointers in that the Dictionary definition is rather simple. It is the implications and proper use that takes dedication and practice.

scott_s• 15 years ago

I'm sure I have said similar things before when teaching students. I have no problem with these concepts because I've dealt with them for years.

What I mean when I say such things is that I have a mental model of the student's current understanding. That mental model is based off of what I have taught them, and the understanding they have demonstrated through questions and assignments. When I try to think about this concept with just those tools, I think it may be difficult to understand.

I always try to build a bridge from their current mental model (or, more accurately, my mental model of their mental model) to the mental model required to understand this new concept. If I have difficulty building that bridge, then I think it is a "tricky concept" for them.

mattdeboard2• 15 years ago

Thank you. I think this is a responsible, reasonable approach. "This is going to be tough" is a reliable signal from instructor to instructed that we need to pay close attention, because this next part won't be easy.

hackinthebochs• 15 years ago

People try so hard to find excuses why some people can't understand some concepts, such as pointers. It's all an attempt to avoid just admitting that some people aren't capable.

I've spent much time tutoring people on various subjects, programming, physics, math. And the fact is there are just some people who can't grasp certain concepts. From my observations I think the culprit is a poor ability to integrate information into a single mental model. I've seen this many times. Someone can understand concept A, B, C in isolation, but when you try to guide them into combining the three to solve a problem they break down.

I think this really goes to the heart of intelligence. More intelligent people can integrate more information at a single time. This is probably related to working memory (there isn't a single place in your head where working memory functions, but its spread out). Tough concepts like pointers exemplify this. You need to understand the memory model, accessing a memory location, using that info to index back into the memory array, and how the syntax of the language supports these actions.

Analogies can help as it reduces the amount of info you have to hold in your head, but its not a replacement for understanding what it actually is. I think its time to admit that there is an intelligence barrier to some concepts that some people don't cross.

gtrak• 15 years ago

Actually they are.

mattdeboard2• 15 years ago

Completely disagree with you. There is nothing more demotivating and infuriating than a professor breezing through challenging material with no acknowledgement that it is difficult.

If I'm learning a semester's worth of new things, and in there 10-20% is going to be discontinuously difficult, I want the prof to acknowledge that fact. I hate feeling like an idiot, and an acknowledgement that a particular topic requires a manner or mode of thinking orthogonal to what I'm used to helps a lot.

evincarofautumn17• 15 years ago

You're disagreeing with something I didn't say. A professor should not "breeze through" anything. I just said they shouldn't set up students with preconceptions of difficulty.

aangjie• 15 years ago

Phew.. I haven't tried to teach programming to anyone yet, but i think it would be a good idea to ask the student to point to some object. Then point to a different object. Then explaining to them that they are asking the computer to do the same thing as moving their hand and index finger. *- Ofcourse, it may not be practical in a big class, and it might help to put the objects in a sequence. Any feed back on having tried this??

Tricky Programming Concepts Aren’t

Related Stories