Some students think that programming courses are tough and hard. I personally know some teachers who say to their students that programming is not their cup of tea. How much percent this thing is true that learning programming is tough. According to me if people interested in this then nothing is difficult for them. How can I convince my students that programming is not as difficult as they think?

  • 1
    $\begingroup$ A lot of the problem with programming and computers being difficult, is bad languages, operating systems, and windowing systems. We need to stop using low quality systems, and to also choose systems that are well suited to learning (not necessarily well suited to industry). $\endgroup$ – ctrl-alt-delor Dec 22 '18 at 13:04
  • 1
    $\begingroup$ I'm not sure what you mean by low quality systems. I started on a Dec 10 in BASIC on a TTY that had just been upgraded to 300 bits per second. A modern Windows or Linux system is far superior. $\endgroup$ – pojo-guy Mar 13 '19 at 3:22
  • $\begingroup$ "According to me if people interested in this then nothing is difficult for them." I'm not sure this is true (at least not universally true). I'm very interested in music and I would love to be able to carry a tune when singing - but so far it has eluded me. Maybe nothing is impossible... $\endgroup$ – dlu Mar 20 '19 at 21:41

Careful! That's a pretty aggressive statement, and is liable to make folks who really do have trouble feel pretty bad about themselves.

You may want to take a look at this question. Whether you believe the answer to ultimately be yes or no, you will find that even the most adamantly "no" teachers admit to some number of students who have enormous difficulties

Interest is highly important, of course, but how your brain is wired matters a great deal as well. Don't discount real difficulties that people face. That's the kind of thing that causes people to beat themselves up mentally, when they're alone with their own thoughts. Interest is important, but may not be sufficient, and dismissing the problems others face can be unkind.

  • $\begingroup$ The thing I find perplexing is the question of what a person is doing at a university if they don't already know what they want to learn and do? I knew I was interested in computers, programming and especially operating systems since 9th grade. So my college courses were not 'difficult' (they were but I didn't care), they were what I wanted to spend my waking moments doing. I never did end up working at Microsoft, but I had an interesting job. If you want to do something, the issue of difficulty does not arise. If you don't want it that much, find something that you do want. $\endgroup$ – Scott Rowe Apr 1 '19 at 10:21

According to me if people interested in this then nothing is difficult for them.

This is a dangerous viewpoint, and I strongly urge you to reconsider. Many students find programming difficult. If you tell them that it should be easy, then you're going to dissuade them from pursuing it.

"This programming stuff is really hard for me. My teacher told me that it should be easy, so that must mean I'm really bad at it. I guess this isn't for me after all!"

Instead, I think you should acknowledge that yes, programming is hard. It's normal to feel frustrated or to not immediately know how to solve a problem. Then teach them how to approach that: break problems down into smaller steps, debug, research, read through documentation, etc.

How can I convince my students that programming is not as difficult as they think?

Again, the first step is to acknowledge that their feelings are valid and normal. Being frustrated is a normal part of programming.

Then focus on why they're frustrated. I think many students find programming difficult not because of the syntax, but because of the logic involved. Programming is really a process of breaking down a goal into smaller sub-steps and then identifying the syntax that accomplishes a particular sub-step. Even if students memorize syntax, this process is often new to them, and that's where they get stuck.

I agree that getting students over the initial "programming is too hard / too nerdy / too mathy for me" hurdle is very important. For that, you might look into doing the Hour of Code challenge. Have students get something up and running, and they'll realize that it's not as hard as they thought it would be.

But after that, you need to acknowledge the aspects of programming that are difficult, and introduce strategies they can use to solve the problems they're stuck on.

  • 4
    $\begingroup$ Right, I have had students try to memorize their way to programming, which is about the same as trying to memorize your way to being a jazz improvisation virtuoso. If it could be memorized, we would just build a computer system to do it. It is 'hard' because one must grow beyond knowledge, to other human capacities not so easily described, or taught for that matter. $\endgroup$ – Scott Rowe Dec 9 '18 at 16:48

I suggest looking into Growth Mindset resources, both to understand why students feel this way and why others excel despite facing difficulties.

One way I help students get past that initial hesitation is to implement the Lifelong Kindergarten method from the MIT Media Lab. It's the 4P method: make projects, on a topic that you feel passionate, with your peers, and (at first) make sure the EFFORT and not the result is graded, so it feels like play. When students know they can't fail if they try, that is liberating.

  • $\begingroup$ Hi Charlotte, welcome to Computer Science Educators! Always glad to have more NCSSM faculty here :) $\endgroup$ – Ben I. Mar 20 '19 at 13:50
  • $\begingroup$ When I was in 9th grade I came up with my own projects because the course was not available to me right then. I was working by myself though. I definitely felt passionate about it and it was not being graded. It worked. Same in college: I was really interested in getting my assignments to function. $\endgroup$ – Scott Rowe Apr 1 '19 at 10:53

Everyone finds some things hard. It differs for different people depending on their background and their interests. But it also depends on the quality of their teaching. More important, some people catch on to new things more quickly than other things and more quickly than other people on a given task.

I wouldn't be likely to tell a student that this is so hard that you aren't going to get it. That would set an expectation that would be hard to overcome. But I might want to say that this will take some time and effort to master.

Good teaching of programming (like most things, actually) requires lots of practice and lots of feedback. You don't learn it by listening to a lecture about it. You have to actually do it. It is like a lot of physical activities, in fact. If you want to learn to swim, you need to practice it. A lecture isn't going to make you a swimmer.

On the other hand, they won't find it easy just because you tell them it is easy. That could be frustrating to those without the needed background. You need to show them.

One way to do this effectively is to flip the classroom in which the activities that they do when face-to-face are not listening to lectures, but actually programming, building a project. This can be most effectively done in small groups (pairs) so that they can teach one another to a certain extent and you have fewer interventions you need to make when someone goes off course for a bit. Their "homework" isn't to do some programming assignment, but to read (book, online, handout) what would otherwise be a lecture. You can test the readings with simple, short, quizzes that don't contribute much to the grade. You don't want to stress memorization, but practice, hence make the quizzes count for relatively little compared to the advancement of programming projects.

One interesting thing that students can do for "homework" is to read a program that has the features you want them to know and ask them to write a few paragraphs explaining it. Writing of any kind is always useful for students and this will let you see if they get it or if you need to spend time on certain details. I'll note that much of what goes on in a traditional lecture doesn't really need to be said, as nearly all of your students will already understand it without the lecture. They still need the practice of course, but knowing who needs extra help is important.

Alternatively, students can repair a program with minor errors of the sort that is the current topic of interest.

  • $\begingroup$ "It is like a lot of physical activities". Or learning how to play a musical instrument. Or woodworking. Or writing (even in your native tongue). Some people may be naturals in any of these areas, but most people aren't. They need instruction and practice, practice, practice. $\endgroup$ – njuffa Nov 25 '18 at 21:21
  • $\begingroup$ @njuffa those with the most 'ability' are the most in need of instruction. $\endgroup$ – Scott Rowe Dec 9 '18 at 16:51

Others have already said well why you shouldn't dismiss the difficulties of your students. I'll address this other portion of the question:

How can I convince my students that programming is not as difficult as they think?

By making it easy.

Easy things are those that conform to our mental models, so every person has easy things different from those of others.

However, one point working for everyone is that of separating distinct ideas and let them be understood independently, while at the same time making their connections explicit. Of course this is not easy.

For example, programming may become difficult because usually all these are presented at the same time, in one big introductory mix:

  • Purpose and objectives of computing
  • Syntax
  • The specifics of the example problem
  • The solution of the same problem
  • General ideas of computation models: abstract entities not explicitly discussed (which is a rich and complex topic in its own right)
  • Specific ideas of the concretely adopted computation model: the chosen language (mind the distinction between syntax and language)
  • Extra/magic: libraries, various boilerplate stuff we just need to make it work
  • The need for solutions to be generalizable to differing inputs

All these are intertwined. An abstract discourse doesn't make sense without at least one concrete instance. On the other hand a concrete instance might be too complex without its accompanying simplified abstraction.

The tools used must also make it easier to actually separate what must be separated, to minimize the unnecessary noise.

The less concepts the easier it is to learn, the less your tools demand knowing the easier it will be for the students.

Concrete examples following.

One simple and standalone enough concept is that of function, the result of which is calculated by substituting the variables with the parameter values in an expression. It is a powerful primitive with a solid theory behind it and it is at the heart of the meaning of computation. It also is familiar to the students for their mathematical counterpart: computer science deals with the very concrete point of calculating the result, whereas the mathematical function just denotes it without saying more. It can be imagined on paper. After understanding it can be translated to formal syntax. From there you can build the following steps, being always grounded on something they are already familiar with instead of jumping straight to complex automatons written with curly braces from lesson 0, as they have no previous experience whatsoever with automatons and will not understand them without a concrete model.

How instead to make computer science difficult: I think of those "funny" introductory paragraphs on some books that discuss at length how to put together a strategy for an automaton to be followed to reach a longed for result, often with examples having nothing to do with computations and which no one would approach in such a contrived manner. I have a book with this example of "how to go to sleep the computer scientist way", the solution is "1. change clothes, 2. wash teeth, 3. enter bed, 4. turn lights off", wow! Now the student is ready for algorithms with curly braces (lol): irrelevant order made relevant, unknown automaton primitives, no management of state mutation (that will magically appear in the code), no input to configure the operations, no output result of interest. In short: nothing related to what they're going to learn. That doesn't help students the least: its ambiguity is dangerous, the student is left without knowing what he's doing because he has no model for his automaton to be instructed. He will just try to say random things totally unrelated to computation and will start his journey to despair for not understanding what automatic computation is and will pass on the voice that computer science is difficult. A clear model is of the utmost importance.

And finally there's a real inherently difficult point: students can learn many tools but then they need their own creativity to make use of them, and this is not easily taught as far as I know. You can show examples and talk about how to analyze and synthesize solutions, progressively enrich their tool set, preferably from distant disciplines, but then it's their job to invent and test their solutions.

  • $\begingroup$ It sounds like your mental model of learning is pretty similar to mine, particularly vis-a-vis complexity and abstraction. I love this answer. $\endgroup$ – Ben I. Mar 12 '19 at 17:48
  • $\begingroup$ Oh thanks Ben :) glad to hear that my ideas are shared. $\endgroup$ – user9137 Mar 12 '19 at 19:47
  • $\begingroup$ I hope we see much more of you! $\endgroup$ – Ben I. Mar 12 '19 at 21:10
  • $\begingroup$ So what do you think of the SICP book? Good explanation / introduction or not? If you don't like it, what direction is better? I would lean towards more concrete, simple, directly applicable. $\endgroup$ – Scott Rowe Apr 1 '19 at 10:59

Your question immediately reminded me of Andrew Luxton-Reilly's paper, "Learning to Program is Easy" from a couple years ago at ITiCSE

Here's the abstract:

The orthodox view that "programming is difficult to learn" leads to uncritical teaching practices and poor student outcomes. It may also impact negatively on diversity and equity within the Computer Science discipline. But learning to program is easy --- so easy that children can do it. We make our introductory courses difficult by establishing unrealistic expectations for novice programming students. By revisiting the expected norms for introductory programming we may be able to substantially improve outcomes for novice programmers, address negative impressions of disciplinary practices and create a more equitable environment.

If you don't have ACM Digital Library access, he also has the full text up on ResearchGate.

  • 1
    $\begingroup$ Upvoted for contributing something new, though I disagree. "Children can do it" is hardly a solid metric of ease. Children also learn to read, but it's hardly "easy". It takes literally years to learn well. Any topic of sufficient depth comes with enormous potential cognitive burdens. While lowering the standards can cause more people to pass, it's hard for me to imagine that this will advance the field at large; we would be slowing down the 50% of the students who already thrive in order to accommodate the 25% of students who are not doing well. We need differentiated responses. $\endgroup$ – Ben I. Mar 24 '19 at 22:26
  • 1
    $\begingroup$ I wouldn't read too much into that one line because the author has important points in the full text. For what it's worth, I am not fully endorsing either the "programming is difficult" or "programming is easy" standpoint. However, I do think the stigma of being a "hard major" doesn't really do us any favors besides feeding egos for those of us who made it through any way. $\endgroup$ – Kevin Buffardi Mar 25 '19 at 0:28
  • $\begingroup$ Perhaps children should start learning about computers when they are learning to speak and read? The best skiers and skaters start as soon as they can stand up. Same for horse riding, gymnastics and so on. We could give young children technology products when they are two... Wait. $\endgroup$ – Scott Rowe Mar 25 '19 at 1:21
  • 1
    $\begingroup$ @KevinBuffardi I skimmed over the full paper. What it's missing entirely is the idea that people are just different. I guess what I'm suggesting is that the topic is neither intrinsically hard nor intrinsically easy; it depends on your personal background and how you are personally wired. It's very easy for some, brutally difficult for some others, and somewhere in the middle for most. (That statement should track with our intuitive lived experience pretty well.) (cont...) $\endgroup$ – Ben I. Mar 25 '19 at 14:02
  • 1
    $\begingroup$ Both are valid insights, but that's the point. I think we have the habit of treating programming as if it is distinctly "hard" Learning in general is hard. Suggesting that programming is distinctly harder than physics, foreign languages, playing an instrument, etc scares away capable people. Just calling it "easy" doesn't do it justice either. Marosh Fatima's heart is in the right place. Many students have the notion that CS is "too hard" or they don't belong and won't give it a proper chance. Replacing that attitude with a growth mindset like @CharlotteDungan suggested should help. $\endgroup$ – Kevin Buffardi Mar 25 '19 at 20:31

OK, maybe I'm just a contrarian, but the approach that I take is to validate the experience that programming is sometimes hard. I tell my students that pretty much every developer hits patches where programming feels hard. The compensation is that it is also fun, and rewarding, and a "worthy" challenge.

I point out that they are learning a new language (albeit a relatively simple one if you measure by the size of the dictionary or the number of grammatical constructs), a new way of thinking, an often cryptic system for reporting errors, and dealing with an often fanatical "grammar nazi" (the compiler).

Then I make my early assignments fun and expressive and small - I want there to be motivation and room to experiment and I try to encourage a culture in the class where it is ok to "fail" and where throwing code out and starting over is an option (hence keeping early assignments small).

In the intro class I try to have grades be weighted towards solidity of understanding than on the number of concepts covered - so that a slower moving student still has a chance at a passing grade. I also encourage pair programming (when I figure out how to teach it and manage it well I'll require it) and collaboration in general.

  • $\begingroup$ "OK, maybe I'm just a contrarian, but the approach that I take is to validate the experience that programming is sometimes hard" - I consider programming a game that never gets old. I never feel it's hard inherently, the only thing that makes it hard is the deadlines when you do it for money. $\endgroup$ – Aksakal almost surely binary Apr 23 '19 at 1:59

In addition to the other answers: I'm usually telling my students, that a programming language is easy to learn - the basic vocabulary is just about 10-20 words and in their language courses they learned more words in a shorter period of time. Even the grammar is much simpler then in natural languages.

Usually they are a bit shocked when I tell them in week 3-4 that they now know everything they need to build their own Word / Windows / racing game / ... So there must be something else!

I try to give them small assignments and enough time to play around with every new concept. Once they feel that they can accomplish even little things, the motivation to learn more is better.

  • 1
    $\begingroup$ Once you know how to arc weld you can build the Eiffel Tower. In principle, anyway... $\endgroup$ – Scott Rowe Dec 9 '18 at 16:50
  • $\begingroup$ @ScottRowe Isn't it riveted? $\endgroup$ – dlu Mar 20 '19 at 21:45
  • $\begingroup$ @dlu these days, we would just 3D print the darn thing. Soon, carbon nanoparticles will self-assemble to build it. We can all have our own copy! $\endgroup$ – Scott Rowe Apr 1 '19 at 10:49

Programming is like playing a piano: it's easy after you spend enormous amount of time practicing it. Those who love programming do not notice how much time they spent learning it, because it's so fun to them that time flies. Every time you went to search a new trick didn't feel like work at all. It felt like playing a game. However, it was time that your brain spent learning. Little by little these people accumulated thousands of hours of practice. It was not easy at all for their bodies.

If you do not like programming then every minute spent doing it was felt by your entire body and mind. That's why their entire body resisted every minute of it. So, the chances are they quit after a few days or hours before the results started showing. Look at people learning piano, the first year they can't produce much of a sound at all. Most people quit early. However, if somehow you go through it, after many thousands of hours it becomes easy. Look at master piano players, their fingers are dancing on the keybooard producing beautiful music. The reason piano and programming is difficult to some is that they don't like it. There is no way to make them like it either. You can't make someone like something. They either do or do not.

If you don't like piano analogy, I'll say that differential geometry is not difficult. Try convincing programmers that it's easy.

  • $\begingroup$ The problem that intrigues me is "how do you discover and nurture the people who could be great at piano/differential geometry/CS but who are held back by <fill in the blank>?" $\endgroup$ – dlu Apr 23 '19 at 0:52
  • $\begingroup$ @dlu, I'm with Linus Torvalds on this: the kids need to be exposed to CS, then they decide if they want to pursue it. I think it's mainly K-12's objective to expose kids to all different fields and see what sticks. You need good teachers though. We had a crappy chemistry teacher and all that exposure to the subject was wasted. Otherwise, it's an interesting subject and I could see myself liking it under different circumstances. $\endgroup$ – Aksakal almost surely binary Apr 23 '19 at 1:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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