22 September 2011

Tricky Programming Concepts Aren’t

What Teachers do Wrong

Teachers use subversive language. They say things like “this is a bit tricky” before introducing a concept. It’s intended to remind you to pay attention, but mostly it turns students off—it says “this is hard; I don’t expect you to understand it”.

Frankly, that’s bullshit, and it has appeared—and caused problems—in nearly every class I’ve ever taken. It’s especially visible in mathematics and the sciences, but foreign language, social studies, literature, and even drafting are not immune.

The fine arts, notably, do avoid it: it’s not conceptually difficult to improve your process and observational skills—and no art teacher I’ve ever encountered pretends it will be anything other than hard work and dedication. (Paul Graham got this one right: hacking and painting are very similar.)

I may have an irresponsibly intertwingled worldview, but it seems to me that most things are not conceptually difficult. At all. Even the most high-level concept, explained correctly, can be absorbed and applied by any person of average intelligence. The important thing is the explanation.

Learning should not be about overcoming difficult ideas: it should be about realising how simple those ideas actually are.

I think the main reason that fine art instruction is effective is that, when a student says “I can’t draw/paint/compose/&c.”, the teacher’s natural response is to say “you can—you must; just practice”.

And they do, and they get better. Most people are not going to become master painters or composers, of course, for the same reason that most people won’t become masters of anything. But perhaps more of the people who are capable of mastery would strive for it if we used encouraging, practical teaching methods like we know we ought to.

♦ ♦ ♦

What Programming is About

Programming is fundamentally about doing three things with a problem:

  • Discovery
    First, know what problem you need to solve. Finding interesting problems is half the fun of research. If you don’t mind solving uninteresting problems, you probably aren’t a very interesting programmer, or even very interested in programming.
  • Understanding
    Once you know the problem, you need to understand it deeply. You need to understand its subproblems, and their subproblems, all the way down to the units that make up your problem domain. (This is recursion.)
  • Expression
    When you understand the problem, you can express it. This is not just writing the code you designed earlier, as some “software engineering” evangelists will have you believe. Expression itself contains discovery and understanding, which leads to further expression. (This is tail-recursion. It’s also why the “waterfall” method is flawed.)

This is exactly like the process of essay writing: you discover your thesis, engage in research to understand your topic, then begin the process of expressing yourself in a logically connected essay. While figuring out your expression, you discover and understand further details and incorporate them into further expression.

An essay is ideally just a proof of a thesis; similarly, a program is ideally a solution to an intellectual problem. Both have practical effects in the real world, and at the heart of it, they really are the same thing.

♦ ♦ ♦

“Tricky” Programming Concepts

Two things are consistently taught in such a way that beginning programmers fail to properly understand them. Things that are so stunningly simple and pervasive that it’s baffling that anyone could fail to understand them.

I’m talking of course about pointers and recursion.

What baffles me is how people seem to be so inclined to analogy when the vast majority of programming concepts are stupendously literal.

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

(Don’t the C++ folks in the audience give me any crap about C++ references. They’re not magic, they’re non-nullable immutable pointers—just another reference type.)

The address of a thing is not the thing itself, but it is good enough (and often, in fact, better). I can steal anything in your house, break your windows, burn it down, and all I need to know is where your house is. I can use the words “burn your house down”, and even though I have not actually burnt your house down, you know exactly what I’m referring to.

Reference is a fucking pillar of language. I say “fucking” because it’s fucking important. We use finite-sized symbols to refer to concrete objects and abstract concepts alike, and it takes no more cognitive effort to say the word “apple” than it does to say the word “universe”. (Referring to something is a constant-time operation.)

Most people have no trouble understanding the concept of reference, of course—but then they fail to see why it’s important, least of all in programming. But again, you don’t even need analogies here—the explanations are comically, tautologically simple:

  • A linked list is a list of things that are linked.
  • A tree is a hierarchy of things that are linked.
  • A queue is a queue of things.
  • A stack is a stack of things.

If someone doesn’t understand these things, they’re probably trying too hard. 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.

That’s all.

Recursion is even more important to programming, even less understood by beginners, and yet even more visible in daily life. If you remember one thing, remember this:

References are for referencing, and recursion is for self-referencing.

A mind-squishingly huge number of natural things have fractal structure, from clouds to mountains to plants to coastlines to trees. A branch of a tree looks just like a whole tree, only smaller. Because of this, doing stuff to part of a tree is basically like doing stuff to a whole tree.

You can thus write instructions for doing stuff to entire trees very concisely: to snuggle a whole tree, first snuggle the base of the tree, then snuggle each branch as though it were a whole tree.

This works in less silly examples as well: to sort people by height, pick one, move all the shorter people to his left, and all the taller people to his right, then sort each side. Bam. You’ve just invented quicksort.

♦ ♦ ♦

Don’t Be Fooled

So I think Joel Spolsky got it severely, totally, irresponsibly wrong in his article The Perils of JavaSchools, wherein he basically claims that understanding pointers and recursion is an aptitude, not a skill.

Not only is it the same kind of subversive language that teachers mistakenly use, it betrays a deeply mistaken belief that the concepts of pointers and recursion are somehow inherently difficult.

They are not.

If you think all I’m saying is “programming is not as hard as people make it out to be”, then you’ve missed the point. Programming is hard, like writing and design, because it is intimately related to both. It’s just that the basics of programming are no harder than the basics of any other kind of design.

Pointers and recursion are among the most basic things in the world. The real world, the one in which we live—and that’s why they show up in computing in the first place.

♦ ♦ ♦

My sincerest thanks to all of the kind folks at Hacker News (and now /r/programming!) for reading, upvoting, commenting, and +1ing. Your many praises and criticisms are deeply appreciated, for giving me the motivation and humility to write even better content in the future.


  1. brilliantly said; i couldn't agree more!

  2. Obfuscation is the name of game of big companies, and accomplished developers working there. These guys there singing the same song they were told to by their bosses. I as a big honcho in the company tell you to do something and do not give the full framework you need. For, I think my time is valuable and I do not want to spoon-feed you....! You have very well said.

  3. Awesome post. Now do monads please?

  4. They say things like “this is a bit tricky” before introducing a concept. It’s intended to remind you to pay attention, but mostly it turns students off—it says “this is hard; I don’t expect you to understand it”.

    Hmm... This is the truth. I too agree!

  5. This thinking could be applied to just about anything.
    Which is the most important thing overall.

    Nice post!

  6. The problem with linked lists - as an example - is that you hear about them in a context where you need to implement and use them, which is good BUT:
    To implement and use a linked list you need be at least decent at programming which generally means programming in a low level language like C, which is damn good but you already need to have an huge amount of knowledge and experience, like the whole syntax, the pointers thing, memory management, using a compiler, etc.

    And all of that stuff just to make something with the SIMPLE concept of a linked list. Yes the concept is simple, hell most of us can "implement" it with a pencil and a sheet of paper, so and average person can understand the concept just fine, implement it and use it as a tool is just another level which involves very hard work and huge amounts of time and this is where the "average person" jumps out of the picture.

    Two things where i think we disagree:

    Programming courses are much more "result oriented" than liberal arts, yes you learn and think and improve yourself over time but you have to deliver the goods, and that means a working program.
    You can fool someone with your writing and your paintings, but not a computer.

    There is a difference between writing a bad article and the next one will be better and then the next will be even better and a compiler shouting "ERROR! YOU SUCK" every 5 minutes.

  7. I agree with all the big ideas in your post. Persistence and effort are the keys to learning and even excelling at anything (although some people succeed without persistence, this should not be seen as normal). The basics of programming, like recursion and pointers, can probably be mastered without any particular innate talent, and certainly shouldn't be seen as sacred ineffable mysteries.

    With this overall agreement in mind, however, I think that in pursuit of rhetoric, you get a lot of details wrong.

    For example, users of natural language do NOT understand reference in natural language. I mean, well enough to use it, sure, but not well enough to reason about it. Consider for example the ontological argument for God's existence, which is fundamentally founded on the misconception that a reference implies that the referent exists.

    A stack is not actually just a stack of things, it has special properties. A tree is not like an actual tree, because an actual tree has physical extent and mass and limits (and even considering family trees, some people do marry their cousins). A linked list is not a list in the sense people normally mean, and it's also not linked in just any old way. Simply looking at the names of these things does not actually tell you much about their computing science meanings.

    Further, I think it's worth considering that understanding these allegedly-tricky computing science concepts may be an aptitude as well as a skill. You can't sit through an undergraduate education in computing science and fail to notice that some students pick up some material effortlessly, and others do not. And a given student may pick up some ideas dramatically more easily than not. Isn't that aptitude?

    But to return to the larger ideas, I do strongly agree that students are not served by believing that understanding is an aptitude, and that we should teach students that persistence will let them surmount nearly any challenge.

  8. Many of the same points in this post are also referenced here:

  9. On the one hand I've found that yes, everything in programming is simple and easy to understand once you've fully explored the concept.

    On the other hand, everything is so interrelated and we rely so much on layers of abstraction that explanations of low-level details often have to be postponed for later until students get a handle on the basics.

    I'll tag things as "magic code" a lot when I teach programming. It doesn't mean it's hard, it just means it's something you just have to type for some reason and we'll worry about it later (I got the phrase from thinking back on my childhood when I would type in C64 games from magazine listings and have no idea what the commands did, I just wanted the game to work).

    For example, for new programming students who are taking C++ for the first time, I don't go into detail about what "#include / using namespace std; / int main()" mean - I just tell them they have to type it, type their real commands in-between the curly braces, and that we'll revisit what those other commands mean a little later on.

    I remember having a lot of trouble implementing my first linked lists and pointer-heavy programs (using the "sprinkling stars" technique!). I understood the concepts pretty well, but it took a while to get my algorithms right on the lists and to get the syntax right on the pointers.

    So to me that's probably (hopefully!) what a lot of teachers mean when they say something is a bit tricky: that it's a batch of new concepts that's going to take a while to get used to.

  10. Best teacher I had, I don't remember him ever saying something was tricky. I do remember he used lots of expression to the effect of "this is interesting".

  11. I would thank you for this post and also thank Hacker News people for bringing it up on the front page. It is an article of profound impact for me. I am a programmer and I am good at maths. I paint as well at times. However, I have not been a good teacher according to my friends. I had first realized a similar concept when I read "Zen and the art of motorcycle maintenance". Gradually by improving my explanations, I am getting better at it. I only wish I had read these concepts earlier.

  12. I think you're overstating it, and coming at it with already acquired knowledge.

    Pointers are tricky in that you have to unlearn the correct response to "a finger pointing at the moon". You need to care about the finger, not the moon.

    All your explanations of data structures are missing fundamental properties that these things are supposed to have. You don't link things in a linked list arbitrarily. A tree doesn't support arbitrary hierarchies.

    The analogies also don't map exactly. What's a "stack"? With a stack of papers, I can take the top half and make another stack next to it without any flipping or rearranging. I just grab the top half and move it to the side a bit. The equivalent thing in computers requires you to pop the top into something which is the *opposite* of a stack to get the same behaviour.

    When you describe quicksort, a naive implementation would run over each sublist and calculate the average so you know where to pivot everyone around. The trick with quicksort is to not do that.

    While I agree that people should at least look at the words for hints at the mental model, there are important distinctions between the common understanding of these terms and what they mean for computer scientists.

  13. Yep, what BrettW said. Some people click into foundational concepts intuitively; some people don't click at first but then the light bulb goes on (e.g. after trying things out or seeing different motivating examples); and some never click at all. Go read up on learning styles. You're picking out examples where you've internalised your understanding, then claiming that the examples are self-explanatory.

  14. I used to be annoyed with people who wouldn't learn stuff. I mean it's just a matter of putting in some effort.

    Finally I realized that some people are just too stupid. They are actually not able. And won't be. It's not a matter of effort.

  15. Donald Knuth himself said that only one person in 50 has the brain wiring to do computer science.

  16. Good stuff. I've found too often, that concepts I thought were hard, and which people drilled in to me were hard, are actually easy. I remember learning loops and functions and polymorphism and pointers recursion and all that good stuff, and there was a time when it seemed impossible. I remember, once, not understanding the concept of a variable. Or a function returning a value.

    Of course, I eventually learned all this stuff. Because it's not that hard. It's all relative. It seemed hard at the time, but then you learn it, and it's not. People can tell you stuff is hard, and make it seem daunting, and build barriers in your mind, but all you've got to do is invest some time in it. Many people have learned to apply these concepts before, the only thing stopping you is you.

  17. Thank you for this article.

    I'm a developer and a math teacher, and I spent two years as teaching assistant in two IT engineering subjects back in College. I've seen what you describe time and again, and almost completely share your point of view.

    Almost. My one complaint is with recursion. While the concept is, I agree, straightforward; programming recursive behavior is not immediately intuitive for everyone. Seeing problems as a series of recursive operations is not always automatic. I think it does need some more introduction.

    However, this was a great read. Thanks again.

  18. "Even the most high-level concept, explained correctly, can be absorbed and applied by any person of average intelligence. The important thing is the explanation."

    A sufficient explanation can carry any average person from not knowing to knowing. Knowing that fact does not mean one can do it. The complexity of their journey depends on the distance from the student to the goal and the trail taken. Many teachers and writers fail to get their students and readers all the way to that state of knowing because the lesson does not take each one's peculiar gaps of knowledge into account.

    You should try writing a document that could mutate a person of average intelligence into one who understands and can do what you do. Let us know how it goes.

  19. I think it would be better to say that not *all* computer science concepts are as tricky as they are made out to be, and often even the simplicity of a natural concept is deceptive as soon as you dig a little deeper.

    Trees are pretty straightforward, tries are not (to an average person), and red-black trees are even less so.

    Lambdas are fairly straightforward concepts, closures are only marginally so and only very superficially.

    Functions are simple conceptually, monads aren't.


  20. Good article. I agree. I don't remember thinking pointers and recursion were difficult concepts when I learned them ( from books and reading and doing... no teacher to tell me I was supposed to find these concepts difficult... ). The art of programming is using these and other tools to do ... programming. I'm more impressed by your "Discovery, understanding, expression... repeat repeat repeat". I still do this today.... I work in scientific programming and often this same process is happening in the mathematics simultaneously.. the programming (coding) part is INCREDIBLY secondary to the discovery, understanding and expression of the problems itself.

  21. Great point about the importance of encouraging students (esp. those who struggle early on) to develop their programming skills! It's amazing how quickly some students are willing to self-identify as non-programmers, and sad to hear about teachers who tolerate or reinforce those views.

    Another general difficulty in learning programming (in addition to finding compelling metaphors) seems to be the confounding effect of theoretical and logic errors with practical and syntax errors. There are techniques for mitigating these problems, but references and recursion are typically more demanding than earlier programming constructs. They require more attention to detail, and tools are generally less helpful in preventing and resolving errors associated with these techniques.

    Your point about programming being hard like writing is also spot-on. It's one thing to understand an example that utilizes references or recursion, and something else to understand the trade-offs that each bring to any model or solution (especially in terms of feature evolution and maintenance).

  22. Actually, once you get used to them, monads are pretty simple. They are, essentially, a type constructor that enforces an interface. The interface has two methods: bind (which passes the result of a computation to another function that has the same type), and return (which applies the type to the value).

    Monads (as a programming construct) were originally used as a way to force a computation sequence in a lazy language. What makes them feel difficult is that A) most programmers think of types as being int, double, char, etc., where as monads wrap around these types (creating a "monadic context.") B) The monad most people are introduced to is Haskell's IO monad, which has a lot of strange properties, but which you need in order to do anything useful with Haskell. C) Because they act in practice like a roach motel -- your int wanders in there and can't get out again -- which makes a lot of programmers grit their teeth and curse.

    And lastly, D) because the sensible way to learn monads isn't to start with monads. It's actually easier to learn the main Haskell typeclasses by going, in order, Functor-Monoid-Applicative-Monad-Arrow. Because the IO monad is so pervasive, almost nobody does this, but this progression helps you see how the concepts fit together better. Brent Yorgey's Typeclassopedia is a good resource here, and so is "Learn you a Haskell for Great Good."

    Monads are hard for imperative programmers for the same reason that for loops are hard for non-programmers: because they are unfamiliar. This just reinforces everything Jon said about concepts being relatively easy if you're willing to put in the work.

  23. You are absolutely and stupendously wrong. Just because you have the ability to understand a concept does not make that concept simple. Just as anyone who has an ear for music cannot understand those who lack said ability does not make that ability simple nor easy. We all have our innate abilities. Lack of empathy is simply a trait of the sociopath, not the educated.

  24. It was invented by humans, you're human, so you have all the tools to understand it. That's all there is to it.

  25. Kind of tangential to your point, but it's actually wrong that concrete and abstract words entail the same cognitive overhead. There is a lot of psycholinguistic evidence that humans produce and process speech for concrete terms faster than that for abstract ones—experiments show slower reaction times for tasks involving abstract as opposed to concrete words.

    If I remember correctly, this was first shown by Paivio in support of his dual-coding theory [1].

    Disclaimer: I am a computational linguist.


  26. ...It's all in the explanation; Good teachers use a mixture of language, diagrams, examples and analogy. Bad or in-competent teachers only use some,one or none of the above.

    However quite a few teachers struggle or fail when it comes to the 'interesting' concepts because they don't fully understand the concept or have not internalised it. They only know the theory.

    When it comes to code face, practise makes perfect and in doing the practise you internalise and hopefully understand the concepts. A good teacher will have done this. So when you need a teacher, star asking some pertinant questions, if you have doubts - leave.

  27. I agree with the encouragement - I distincly remember an algebra lecture where every proof was "simple, because , and so X is X".


    However, I see a mistake in your reasoning that cumulates in

    "If someone doesn’t understand these things, they’re probably trying too hard."

    You are enlightened, but you have forgotten that the path to enlightment is hard. I see that with many brilliant minds - even in good teachers. And yes, "it's not that hard" might be the better encouragement - even if it is hard.

    But we do see people genuinely struggle with concepts such as recurson and pointers, even after years using them successfully they have to slow down, they have to recall the definitions, try to apply them meticulously to the question at hand, and see what comes out.

    When you say "a stack is a stack of things" this is as expressive as "blue color is blue". Nice, that's simple, but why are you talkign about this? How is that supposed to change my understanding of pre-renaissance art?

  28. I stopped reading at "this is a bit tricky"

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

  30. > If you don’t mind solving uninteresting problems, you probably aren’t a very interesting programmer, or even very interested in programming.

    That's a bit harsh mate. I enjoy bringing non-programming people's ideas to life in the computer. It only occasionally involves solving *interesting* problems. I fail to see how that makes me a dullard.

  31. Very very true.

    Teachers say "it's tricky" because they haven't really understood what they teach themselves, and so they have a hard time explaining it.

  32. First I wanted to say that I belive there IS something like "talent" out there. I mean, some people get math, some don't, period. Even if they spend a lifetime learning, they won't master it. Although they may gradually become better, it never will be "natural" for them. It's not their fault. It's just how their brain works.

    For those of us who were born lucky, I agree that persistence is a key to understanding. And once you "understand" something, you just do. It becomes "obvious".

    As it was with me and lists. I've had trouble for months, just grasping the concept. And then, suddenly, it all fell into place. Although, my troubles might have been a teacher's fault. As you said, he considered lists "tricky", and on top of that, he omited the basic concepts (the real-life connection). He started explaining from the level of abstraction that his students didn't reach yet.

    That's why I don't agree with some comments here. Saying "List is a list of things" may be a huge simplification but it's necessary for a beginner. It helps to "imagine" things. And once you have an image in your head, you can begin adding details. Sometimes, even simplifications that can to some extentbe be called "lies" are a necessity. It can be compared to the way they teach children about atom: first they say atoms are little balls that all things in the world are made of; next they compare them to miniature solar systems; and lastly you learn that it was all a lie and there is no orbit that the electrons circle around, but only "clouds of probablilities" (or wahatever it is called in English).

  33. Back when I was 9 and started studying programming, I did not know English, so I couldn't tell that the keywords of the programming language I was learning (BASIC) were borrowed from English. I believe this actually helped, because the keywords didn't hold any meaning to me beyond their BASIC semantics, and I was able to understand the language in its own terms.

  34. "Even the most high-level concept, explained correctly, can be absorbed and applied by any person of average intelligence. The important thing is the explanation."

    Nothing is hard to chew, as long as someone else has chewed it long enough before you start. Just don't expect to develop the same chewing muscles as the person ahead of you - you never will.

  35. While I can appreciate this attitude for learning programming, I am surprised you include mathematics in your list of "essentially easy" ideas. There are a number of very deep results, whose proofs (quite honestly) neither you nor I could probably invent.

  36. Thank you for speaking plainly about so-called "tricky" programming concepts. In my forty year career (no that's not a typo!) as a self-taught programmer, I've found tricky and advanced programming concepts understandable once I've seen them implemented in code. And actually, sometimes you just have to take in the information as is and not think about it.

  37. Awesome article and interesting comments. I'm a junior at the local university working on a CS major and this article is dead on the spot.

  38. You know, I always thought that there was a conspiracy out there among profs to prevent me from understanding quantum mechanics, recursion, pointers, recursive data structures, lock ordering, ...

    Now you have confirmed it for this IQ 100 average intelligence person.

    I wonder why they engage in such a conspiracy? Can't they understand what it is like not to understand this important stuff?

  39. You used the word problem in your article.

    I say there are no such things as problems, only solutions.

    It's an attitude thing and relevant to your point of view. So re-read your article and replace the word problem with solution and see the difference.

    Of course sometimes a problem is just a problem.

  40. If there are no such things as problems, then what are your solutions solving?

  41. Pointers per se are not hard. It's just the C way of doing it that is completely obfuscated. The order of the *, & or whatever becomes even worse when you are pointing to a pointer to a function or something.

    I've never seen anyone having problem with references in for example C# or Java and those are basically the same thing.

    Array-indexing, which basically is pointer+index, is also a much more user-friendly way of doing "pointers" than many magic attempts i've seen by some people.

  42. I think when you're teaching programming it has less to do with how tricky the concepts are (or otherwise) and more to do with how much information the average, feeble human mind can assimilate at any one time. Fortunately, however, programming uses attrition: by the time the students have to get jobs, the feeble minds are no longer of any interest. I think programming courses would probably go better if the teachers were to kick out the dumb-asses at the beginning, rather than resorting to some form of political correctness and trying to teach everyone. Programming isn't about understanding all the concepts, necessarily: ultimately, you can either program or you can't, and whichever it is, it's always been true, from way before you ever sat down to learn to do it.

  43. So "tricky" is bad but "fucking important" is good?

  44. That was exactly my response to being introduced to pointers. "This is hard." They certainly explained it as if it was hard - it wasn't obviously about addresses - but upon analysis just looked like using a thing's address instead of the thing itself. I wondered off and on if I hadn't understood them, because an address isn't hard at all, but they never said anything that didn't mean 'address,' (non-obviously) so I assumed they were just being idiots.

    And of course when I programmed assuming they were just addresses, the thing compiled and ran. Kind of hard to screw up that observation.

    The core issue of which this is an example is that every concept is made out of simpler concepts. If a concept really is hard to understand, all you have to do is back down a level and try again. No concept - at all - is made out of difficult fundamentals. The only meaningful difference between high IQ and average IQ - or even pretty dumb IQ - is how long it takes to absorb those fundamentals. Nobody with a nominally functioning brain is incapable of absorbing them.

  45. I don't fully agree with author. Despite already having programed in basic and pascal for some year, I remember having quite a serious block about C expressions. About the fact that in C everything has some value, even to the extent that "void" keyword is necessary. And some values can be assigned to, some not. Teacher did not say "it's tricky", it was fully me.

    Likewise, my grandfather, who was very intelligent electrical engineer and has solved many interesting technical problems in his career, could not grasp the problem "What happens to loaded spring if it is put into acid and slowly dissolves without breaking? Where the energy vanishes?" It was somehow impossible to explain to him that it is released as heat - while the atoms from the spring are released into the acid they release their potential mechanical energy.

  46. I think the simplest explanation of pointers is to compare them to signposts. That seems like the closest real-world analogy without significant contradictory attributes.

  47. Programming is about passion , you can learn program by doing programming which most people don't do that's why they can code but not effectively.

  48. -1 premise is sophomoric. The poster's premise appears to just want to bray about how much more erudite he/she is than most teachers, and while that may be true this post does exactly the opposite.
    Here's a tip, when an instructor or professor represents one concept is "more difficult" or "tricky" in the context of the material it is an inference that it is an area or concept that many either incorrectly apply or otherwise run in to difficulty with. It is not a judgement on the student's capacity as poster insists. A good instructor will go on to provide real-world examples of how this trouble can manifest. If this representation causes the student to become confused or think the concepts are somehow beyond them then it is the failure of the student, not the teacher.
    Education in a two way street. Pull up your poopy pants and deal with the material, not your semantic hang-ups and expectation that education is solely the job of the medium.
    A much better way to go is to leave the pretentiousness out of the post and just demystify the common misconceptions he observes that people have with the concepts he goes on to cover.
    I recognize that it is difficult not to develop a massive ego in a career of paid programming (not to be confused with being a professional).

  49. "Tricky" in math seems to be a term of art that's a little different than you're explaining it here. It doesn't really mean "this is difficult" in any comprehensive sense. It means something more like "this is *not* the sort of thing anyone would expect to see the first time looking at this picture". That is, it requires a trick -- an unexpected (but not difficult to understand) way of looking at the problem, after which it's pretty much obvious.

    To use a non-technical example: unfastening a brassiere one-handed isn't difficult, but it's tricky. There's an approach that's not obvious to most people, but once you've heard of it it's obvious why it works.

  50. I think the confusion I've always had with pointers is that I could never get straight which one was the pointer and which one was the data, so when reading code I would get confused. It wasn't the concept it was the implementation. If someone had a clearer notation then it might have sunk in earlier.

  51. webgirls In terms of combating candidiasis, sufferers usually have their operate cut out to them. This is because candidiasis can simply become chronic and continuing. Knowing that, in this post, we will provide a wide range of the best confirmed candida therapy and avoidance recommendations about.

  52. The thing is them on publications and also on Television set, women and men who seem like their biceps and triceps and thighs and legs will explode as his or her muscle tissue are extremely large! There is not any require for you to take your system for that level if you don't want to, as being the basic strategies in the following paragraphs will help you to create muscle tissue in the wholesome manner.

  53. Recently, I have started to read a lot of unique articles on different sites, and I am enjoying that a lot. Although, I must tell you that I still like the articles here a lot. They are also unique in their own way. 메이저놀이터

  54. this post completely about the comparison of hottest and previous technologies, it’s remarkable article. 토토사이트

  55. Thank you for the information provided! Maintain the good performance of your site. You can also check my 토토

  56. 토토사이트 were active listeners and viewed meetings deadlines as an imperative.

  57. It s my great luck to find this place. I ll visit today and tomorrow. Thank you. 토토

  58. This is a merest refined post. Thankyou pro posting this remarkable article.
    토토사이트 추천