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

I have some computer science students in a compulsory introductory programming course who see a programming language as a set of magic spells, which must be cast in order to achieve some effect (instead of seeing it as a flexible medium for expressing their idea of solution).

They tend to copy-paste code from previous, similar-looking assignments without considering the essence of the problem.

Are there some exercises or analogies to make these students more confident that they can, and should, understand the structure and meaning of each piece of code they write?


locked by Thomas Owens Apr 13 at 16:09

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. This question and its answers are frozen and cannot be changed. More info: help center.

Commenters: Do not leave an answer here in the comments. Write your own answer. Comments are not a venue for discussing various possible answers to the question: either put forth your suggestion as an answer or take it to chat to flesh it out first. –  user8 Nov 30 '11 at 21:54
Whenever academia get's on here - I become concerned for my future... I just imagine being on a Boeing 7-28-7 and the Turbines spinning at 200,000 RPM running on control software written in C by one of your barely passing students... Anyways I digress. –  Ben DeMott Dec 1 '11 at 8:22
Have you considered FAILING them a couple of times, not everyone is cut out for software development! They aren't all special snowflakes! –  Jarrod Roberson Dec 1 '11 at 21:14
Isn't SICP kind of famous for saying that programming is analogous to spell casting? I mean, I doubt your students are quoting SICP or even making a comparison akin to what Abelson and Sussman were trying to portray, but I don't see how it's inherently wrong that someone compare program writing to spellcasting, when one of the most famous computer programming books out there does the exact same thing in the first couple pages. –  Robbie Dec 1 '11 at 22:38
Eric Lippert has a lot to say regarding this subject. And in a much more elegant and concise way than I possibly can: blogs.msdn.com/b/ericlippert/archive/2004/03/01/82168.aspx –  P.Brian.Mackey Dec 1 '11 at 22:38

33 Answers 33

up vote 121 down vote accepted

You could present them a series of exercises, each one building on the previous while adding some extra element or twist to the problem, or investigating the issue from a different perspective, which reveals a weakness of the previous solution, requiring a new, different approach. This forces them to think about, analyse, modify and experiment with each solution, instead of just copy-pasting a ready-made piece of code.

Another possibility - although not strictly a programming task - is to ask them to estimate various things. E.g. how much water flows through the Mississippi delta per second? Such questions don't have a set answer, especially because one needs to make certain assumptions to get to a convincing (range of) value(s). And - although answers to many of these "classic" ones can be googled indeed - you can easily make up new ones which aren't (yet) found anywhere on the net.

Examples to both of these kinds of exercises can be found in e.g. Programming Pearls by Jon Bentley. Also The Pragmatic Programmer has some good challenges.

A third kind of task would be to present them some piece of code with (one or more) bugs in it, which they must find and fix. This again forces them to use their analytical skills and reason about how the program is actually working.


Feedback from a comment by Billy ONeal:

The problem with the "series of exercises" is that students who have a problem with an earlier exercise are completely screwed for remaining exercises.

You are right, although I feel this is more about the general problem of setting course difficulty to the right level / grouping students of similar skill level together. Moreover, one can arrange the students into smaller groups where they are required to discuss and debate about the problems and solutions, and solve the problems together. If someone doesn't get it, the others can help (this setup would improve teamwork skills too). And if someone tries to be lazy and let the others do all the work, it is surely noticed by the teacher (who is supposed to be walking around, supervising and mentoring the students, not playing WoW on his laptop in the corner ;-)

And one can also adjust the exercises to accommodate students with different skill levels. Beginners can go slower, experienced ones faster.


I have taught introductory classes in the past and as I recall looking back now:

Some students think programming is like that for different reasons. I remember once a good kid that cargo-culted a lot what I did:

Believing that it was not an isolated issue, but other students in the same class might have similar behaviour or approaching to the problem and not express it, I was always addressing the class.

  1. Some time was spent to explain some stuff such as determinism, which meant for them that in the same environment with the same data and code, they will have the same results (dispell the "randomness"),

  2. Since problem solving is up to what the student's actions and not anything else, the attention should be in solving the problem and not finding the right spell,

  3. They are in an education environment, so the problems are crafted in order to offer a learning experience, the outcome is to learn how to program (or in some cases like classes for System Administrators, how programs work, which is different) and not to give me a solution. ("World does not need another calculator, it is an exercise"), so their problems could be solved with the materials available (example: notes provided),

  4. I think it is in Code Complete: "Even if you copy and paste, the code is yours". If someone did it, it should not be cargo-style. Every line had to be explained to me (individually) or to another student (same) or to the class.


Never give them similarly sounding assignments.

Or, more crazy, learn them TDD from the beginning. It pushes for writing (not copying, writing) a lot of code (namely tests) that actually helps to formulate the problem that is being solved.


Several things that come to my mind:

  • Give them assignments where they actually have to explain the code someone else (you) wrote. Understanding of the previous code or more specifically lack of it is both the largest cause and danger of cargo cult programming. Ask them to use comments, line by line if necessary, to explain your program in plain English (or whichever human language you use).

  • Only after they've explained the code, ask them to modify it in order to make a certain change. For example, if you gave them a sort function that sorts descending, ask them to make it sort ascending. Or something more demanding. But make sure it's something that requires understanding of the given code.

  • You can, if you like, put some easter eggs in code. A line or two that does nothing useful or even related to the problem at all. Give them a hint that such lines exist and grant extra points to those who remove them.

  • Then and only then you can give them an assignment to write a piece of code from scratch on their own. At this point they should have a much better understanding of what code really is. They might even find it a little easier to do it themselves.

The basic idea is that programming is not just writing code, it's also reading it. Reading code should also be taught.

The easter egg idea seems like it would also be a good way to teach testing/verification. Along the lines of "wat can be removed without breaking any of the contracts?" –  Neil N Dec 1 '11 at 22:26
+1 to reading code. I see a lot of guys fixing bugs by making an intuitive guess and then seeking out to prove it. I find that reading the code provides clues that take to you the right solution. It sounds obvious, but I see it neglected a lot. –  Chris Dec 4 '11 at 21:25

Teach the class using a programming language that is technically good but is so obscure they won't be able to find any existing code to copy.

I don't worry about them copying someone else's work, but their own work or some example snippets, which are not usable in given situation. –  Aivar Nov 30 '11 at 13:15

Did your students start at the correct 'abstraction level' at the beginning of the course? E.g. a homework that introduces them to the main programming structures like loops and conditionals without writing a single line of code?

When I took intro to programming, our first assignment was called 'Rick the Robot'. We had a piece of paper with an aerial map of a city with interesting points, like banks, grocery stores, etc... We had a dude called 'Rick' and had actions like 'take one step', 'look left', 'look right', 'cross the road' and we could use things like 'repeat' and 'if something, then do something'. (This is not 100%, as I could not find this assignment) The idea was that Rick could only use what he was given and he had to get to different places on the map.

This was a fun exercise and something that introduced you to the basics (which are sometimes the hardest to grasp to newcomers). There is no one good answer to this problem (its a game) and there are no solutions to copy and paste from. Something like this might also allow you to play with their creativity a bit more without intimidating them with code.

Finally, the idea is that you start with the abstract and move towards the concrete. They cannot copy paste abstract. They have to understand it to solve a problem.

Loops and conditions? I'd start them off with variables, assignments and expressions. Have them read two numbers off the command line and add them, then print the result. Often doing something almost painfully obvious gives students the confidence that they can understand what's going on, and encourages them to experiment. –  TMN Nov 30 '11 at 13:44
@c_maker: Your assignment looks like a game for pre-schoolers. Giving your students too easy tasks can only decrease their interest in the subject. –  Goran Jovic Nov 30 '11 at 14:13
@c_maker: I think your answer has merit, I just didn't see how to move from while not at-corner do take-one-step end to actual code without "backfilling" on things like variables and data types. Apologies, my response does seem a little harsh on reflection. –  TMN Nov 30 '11 at 15:01
I think the main value behind Rick the Robot is not in helping to understand loops, if statements, etc. The main value is in helping them understand the general process of how to write a program. It helps them see problems in a specific, step-by-step, algorithmic way. Once they understand the programming process in English with an example like this, then you can fill in the details by teaching them what the code looks like. This is a brilliant idea. +1 –  Phil Nov 30 '11 at 17:21
Reminds me of my introductory course (30 years ago!), which was based on [Karel the Robot](en.wikipedia.org/wiki/Karel_(programming_language). (Note: the link fails because the actual url has parens in it. Click the first option on the page that does come up.) Anyway, Karel used a Pascal-like syntax, but not too much of it. –  JeffK Dec 1 '11 at 21:44

Have you considered supplying them with some code to start with? Whatever simple scaffolding the assignment needs, like an empty main function (I don't know what language you're using). Something that compiles and runs and does nothing. Then they can start adding their code with some degree of confidence that at least part of it works.

This is actually pretty common in the "real world"; lots of IDEs and other tools create empty projects with typical libraries/templates/configuration files already in place.


Similar to JoelFans idea is have them do the initial assignments on paper using a pseudo code (language) that you create. You can add the structures as you see fit and they don't worry about the magic box.


What you're asking them to do is demonstrate analysis and synthesis in the cognitive domain of Bloom's Taxonomy, where they're currently only demonstrating application.

Unfortunately, it's sort of a "lead the horse the water" type of situation. Analysis and synthesis are also very difficult to do when you are still struggling with comprehension. Without the comprehension in place, analysis and synthesis activities are going to act more as weed outs than learning activities.

My personal opinion is that it's okay not to expect anything more than application in intro to programming classes. This is the first time students have been exposed to these concepts, so it's like teaching kids to read before asking them to write an essay. Those higher order skills will follow in their later classes.

Very interesting bit about Bloom's Taxonomy. In my opinion, it's more important to get a student to understand the code than to copy/paste it in an intro class. They need to know how if statements work and be able to write their own from scratch before they move on. Get the cognitive part working, then move on to application. –  Phil Nov 30 '11 at 17:14

You could ask them questions about pieces of code that require written responses? Like "What is this code doing?" "Why did the programmer solve it like this?" "Is there a better way?", etc?

That will actually get them thinking about the problem, which is something they can do without even touching code.


I doubt that this behavior is because of a belief that programs are magic spells - more likely it's laziness and lack of motivation.

So I think your job as a teacher is to motivate your students - no student who's genuinely motivated will cut and paste a solution (that's only for working programmers with deadlines and bottom-lines to meet...)


Look at it in another way. This cargo-cult phenomenon is the novice stage of the Dreyfus Model of skill acquisition. This is how we learn. When I first learned to program, all I was doing was typing in pages of code from the back of Compute! magazine. Repetition is key. Babies learn to talk by copying the sounds they hear their parents make. Everything we learn is through imitation. We just have to be taught how to go from imitation to mastery.

The problem you have is your students aren't repeating anything, they're copying it from the Internet. There is some benefit to that but gains are minimal. The act of actually typing out the code is what got me to a place of understanding. I started to see patterns in what I was typing and gained an understanding of what I was doing.

One option is to structure your lab as a code dojo. Have students take turns pairing with each other on the same problem. Pick a problem that takes about 10 to 15 minutes to solve. Repeat that problem over a few labs and introduce a new twist to the problem as the class' proficiency grows. Perhaps start the lab by having the students watch you program the solution, and have them repeat it. Switching pairs with each iteration.

For your tests have a code kata where each student works through the problems from the semester in front of the rest of the class. Focus not only on correctness but form and creativity. I think this would provide a deeper understanding of how to program than giving take home assignments.

A distraction free environment like Jon Jagger's Cyberdojo can be excellent for this, and setting up your own server is as simple as downloading the virtual machine or source from github. –  Mark Booth Dec 4 '11 at 14:01

You could also treat them the hard way.

Find a way to make a copy-paste harmful to them. I don't have precise example but if you craft a first exercise whose solution, if pasted in a similar looking second exercise, bring the cargo-cult students in a very long and painful "unstable instability" or "silent data corruption" bug. Meanwhile a "non cargo-cult" 2 mn thinking would have brought an obvious solution to even the worst student (hadn't he seen the first exercise solution). Then, maybe there is some possibility they could learn the lesson, and think twice before copy pasting code into the third exercise.


Consider using a very high-level language that requires a minimum of boilerplate code.

To me, it's often the boilerplate code in large frameworks or verbose languages that feel like magic spells and hinders comprehension.

I was personally taught ML at my CS introductory programming course. For many years, Lisp was taught as introduction to programming at MIT. Both are excellent choices. Some of the benefits they have are

  • Interactive interpreter. Very important, as this allows exploration.
  • Very succinct. No boilerplate at all. It allows the students to concentrate on the ideas they are trying to express.
  • Relatively obscure and alien (at least compared to Java, C or other mainstream languages that the students may already have some experience with). Yes, I list that as a pro. It levels the playing field for the students, since likely noone will have prior experience. And it makes it less likely that they will be able to just copy-paste solutions to homework form the web.
  • Challenge them to create the shortest possible solutions to the problem.
  • Reward the more succinct solutions with an incentive.
  • Create exercises that revolve entirely around refactoring code
  • Have the students trade assignments, and mock grade them for efficiency and code cleanliness, and use some of the least efficient ones as examples, on an overhead projector.
Refactoring is extremely important to practice indeed. However, it is good to keep in mind that the shortest solution is not necessarily the cleanest, neither the most efficient (depending also on the definition of these terms). –  Péter Török Nov 30 '11 at 21:09

Teach subroutines. Have them take the code they are grabbing from previous assignments and turn it into a subroutine. Teach them about function documentation to help them understand what the subroutine is actually doing.


You are battling the students' balancing act of their need to care about your subject and their need to get passing grades. Many students feel that:

(Get it Wrong || Experiment) == (Failing Grade && Waste Time)

As soon as a student feels that their time or grade is at risk, even for an interesting subject, they stop learning and jump straight to "I don't care, just give the teacher the right answer". Your students are trying to cut corners (or so they think) by thinking as little as possible about the problem and just hacking away at it by copying and pasting.

Here are my suggestions on how to deal with this:

  1. Use the Bob Ross method: Prove to them that it is both possible and faster to start anew vs. copying and pasting. Create new programs before their eyes during class - really show them that programming can be like painting a picture.
  2. Provide assignments that require creativity. For example, have each student create their own data structures (what are the objects required to create a Zoo, Pet Store, Town, College etc.) on paper to use throughout the course. Assignment #2 can be converting those structures to classes or objects, etc. Basically, entice them into thinking abstractly - reward them for being creative, and then reward them for turning their creativity into a computer program.
  3. Use the least amount of syntax possible. Boilerplate stuff like creating classes and language syntax is so prevalent in the introduction of programming that it often misleads students into thinking that all of programming is just knowing where to put curly braces - they don't realize that what is in the middle of the curly braces is where creativity flows. Pick a simple language, and provide sample files (such as an empty class file) for the students who still want to copy and paste something. You can gradually become more strict about syntax and compilable assignments as the course progresses.
"what is in the middle of the curly braces is where creativity flows" ==> oops he/she won't teach them Python then... –  Olivier Pons Dec 5 '11 at 7:55
Another problem with with just trying to give the teacher the 'right' answer instead of learning, is that people often think that's learning. E.g. lesswrong.com/lw/iq/guessing_the_teachers_password –  Wilka Dec 7 '11 at 9:57
And then I'm going to add a few happy semi-colons here... –  VirtuosiMedia Feb 17 '13 at 10:42

I'm going to assume that by 'cargo cult', you mean that they're inserting stuff that think is necessary, but actually does absolutely nothing towards solving the problem.

If that's the case, you can always add some factor into the grading that's based on conciseness -- leaving unnecessary or redundant code in your program is asking for problems in the future, as it may break, or just make it more difficult to maintain.

They'd be judged similarly in an writing exercise in an English class -- no one wants stuff that goes off in a random tangent or is just generally rambling without getting to the point.

When I took an assembly class, the teacher would tell us for each exercise if he wanted us to write the code for speed, size, or memory usage, and he'd mark off if you didn't come close to optimizing what he asked for.


If they're copy & pasting code from previous similar assignments, and it's actually something to solve the new problem ... well, that's just code re-use, and unless they made bad assumptions about the suitability for the code for re-use, I think it's perfectly reasonable for them to do. (eg, reading from a file, propting for input ... all modular parts that can be re-used. If you didn't want them doing it, you need to make the exercises dissimilar.


Ideally in the first lecture, start them out with something completely abstract: have them (as a group, with you as the leader) write up the instructions on how to go grocery shopping from a list, and break down the high-level instructions progressively until they reach enlightenment.

It helps to tell them that these instructions are going to be followed literally by a robot, who doesn't know how to infer things. It has to be a very hands-on activity where you are in charge of guiding them, though.


Change your idea of projects!

In the programming world, rarely do we actually create new projects for every solution that comes around. Most of the time we modify old ones.

Change your idea of a project from one solution for each assignment to one solution for the entire semester. Each assignment builds on the previous assignment.


Project: Build an elevator system

  • Assignment 1: Print out the current floor
  • Assignment 2: Create the data structures for an elevator class and print out the floor based on the elevator
  • Assignment 3: Create code that "moves the elevator", printing out the floor. Accept keyboard input (>enter floor: )
  • Assignment 4: Handle multiple elevators

The point is that you build on the previous assignment instead of recycling old assignments for a new task.

Well the copy-paste is not the problem, problem is that they don't understand what they are copying. –  Aivar Nov 30 '11 at 19:03
One problem with incremental assignments is that if the student messes up an early one, they are stuck with non-working code for the rest of them. Many instructors will helpfully supply working code to use as the basis for subsequent assignments, but then they're back to the original problem: modifying someone else's code that they don't understand. –  Barry Brown Dec 1 '11 at 20:52

Make them do the assignment in front of you in the classroom with no Internet access provided (have the school cut it off, allow no phone use as well during class). At least do this for tests. There is no reason at all that they should be using the Internet for basic programming expercises. The book should be a sufficient resource for intro exercises. Allow Internet usage once you are in an advanced class and they already have learned how to think.


Unfortunately, thats the way a lot of people's brains work. So go into this understanding that there are people who you cant 'cure' of this. There are a lot of people who are unable to work at the level of mental precision necessary for programming. Some people are simply not designed for it. I'm not saying give up on the students - I'm saying dont assume you are failing if not everyone picks it up.

Without knowing more about the context of the class, I'd say focus more with these problem students on the very basic structures - simple if/thens, loops, etc. Simple routines to print out odd numbers, every tenth number, etc. Nothing more than 10 lines of code each. If they are 'magic thinking' they obviously havent mastered those basics yet. Have them do a lot of different simple routines until they grasp whats going on. Someone else mentioned writing the code out on paper - I think that'd also be a great way to do these simple routines.

You also might consider having them learn flow charting. For some people, being able to see the flow of an algorithm, and then how that connects to code, may be helpful to them connecting the code to the flow.


Alistair Cockburn talks about the concept of Shu-Ha-Ri and how it applies to programming, http://alistair.cockburn.us/Shu+Ha+Ri. I think it may be important to bear in mind where your students are in this continuum. First that will help ease some of your frustration. Copy/imitate is a very natural response and accepted mode when you are first starting to learn something. Second, it may help you get some ideas of how to move forward. For example, you may want to consider choosing a problem that can be solved in multiple ways (loops vs. recursion, console vs. web/gui) then explicitly have them first solve it one way, then another way -- bonus they can learn about legitimate code reuse, componentization, creating reusable libraries, etc.

Another successful way that I've seen used is to have a series of projects that build on one another, making a default, working version available at each step after assignments have been handed in to prevent people from falling behind. Each step of the process should introduce something new. I'll grant you that this may be easier to do in a design class than a programming class, but it should still be doable. One nice thing about this is that you explicitly give them a good (hopefully) implementation to compare against theirs at each step. Expose this comparison as an assignment, i.e., do a mini-code review of their own code against their effort. You might want to make this one of several extra credit options.

While I'm typically not big on "comments," you might want to make documentation of the code one of the grade items. Have them produce a "Theory of Operation" document for each project that describes their approach, how each component fits in, and how they together solve the problem. Normally, I'd want the code to do much of this on its own, but it would drive them to put their thinking caps on and put it to paper.

Lastly, you might want to get creative and have your students review each other's code and give it an evaluation. Put peer pressure to work for you. Allow this to become part of the grade or extra credit for the highest rated code (and docs).


Any sort of cargo-cult mentality (including cargo cults themselves) comes from a lack of fundamental understanding of the technology involved.

Cargo-cult programming shouldn't be thought of as a problematic habit, but rather a symptom of the underlying confusion that the programmer is facing.

More importantly, the assumption that the student's lack of understanding of is simply the outgrowth of his lack of confidence is fundamentally misguided and does not address the underlying problem.

Instead, the student's copy-paste programming style should be a red flag telling you that this student is overwhelmed by the complexity of what he's expected to do.

He's instinctively using past work as a scaffold upon which to build his current project, attempting to compose a solution using previously solved problems as building blocks. We all do this to a certain extent, but most of us do this by using the knowledge gained from past work as our building blocks. This student is instead using the work itself, which means he doesn't truly understand the blocks he's working with. He's decomposed the work as far as his understanding permits, and treating large blocks of code as atomic units because he does not understand how they work. He only knows what they do.


Just a quick suggestion. Whenever I have a programming problem that needs to be solved or debug I like to look at my code and 'play computer' where In my head I keep track of the variables and their values and what I expect them to be when each line is run. So if I copied some code from somewhere, unless it is complete on it's own and I just need to reference it, I like to go line by line to understand exactly what is going on. Essentially playing computer. VBA Debugger essentially makes this task easier but making your students do it on paper might give them fundamentals like. What does this line actually do?


I did some research into the problems of novice programmers in the 80s. Based on my experience with novice programmers today, not much has changed. Novices don't have a useful mental model of what computers actually do. They resort to magic incantations because the machine itself is magical.

Programming requires breaking naturally simple tasks into unnaturally small steps. Since novices don't deal with such fine granularity in daily life, it's hard for them to figure out what the small steps should be, especially when it's not clear what small steps the machine makes available. But even if they do manage to figure that out, they are then confronted with the stilted syntax and limited semantics of a programming language (an unnatural language masquerading as a quasi-natural one) that controls the mystery machine by remote control.

Since they can't make the connection between a logical solution to the problem and the functionality of the machine, they focus on satisfying the demands of the language. The first goal is to write something - anything - that compiles. The second is to tweak that program - whatever it actually does - to keep it from crashing. Then, if they have the time, the energy, and the interest, they try to get the program to produce results that resemble what the problem requires. Along the way, they may accidentally produce well-written code.

In all likelihood, novices who do learn to program succeed because they have inferred a useful mental model of the computer, not because they've been intentionally given one and internalized it.


Something I have found to be very helpful for the people in my class is writing a small project on their, on a subject they can choose themselves.

When I started programming, it was hard for me as well, and I did copy a lot in class. Then at home, I started making little games, as I want to become a games programmer, and I found them to be much easier to make. Even though they were much harder then the stuff we saw in class. Just because it interested me.

A few other people in my class went from 40-50% on their exams to 90-100%, because they did the exact same thing.


A s a s e l f - t a u g h t programmer I believe animation to be the most challenging in terms of knowing what the code is doing. When a program contains algorithms and mathematical transformations performing abstract manipulations, the only way to understand what the math is doing at any given point (unless you're a genius) requires understanding the execution of code itself.

Correct me if my naive idea is incorrect. What you want to do is not prevent your students from using "design patterns", but to find a way to ensure they understand what they are CnP's? Then challenge your students to manipulate an animation. In order to tweak the output in an animation its necessary understand what is happening at each step. For your stated concern, I imagine a well conceived animation project will manifest in obvious ways when a student "gets it"--when they have realized a transformation you didn't expect or tweaked certain related, interdependant variables.

Without knowing the pedagogical limits and goals you are working under, I can't say animation is the complete answer. A whole curriculum of animations outside of animation profession is, I should hazard to guess, out of the question. A few projects may none the less result in something artful and wonderful, which isn't bad.

On another note, I read a newspaper article (yes, paper!) about a high school-level Coding Olympics--wot-wot--competition for pre-college programmers. The description of their challenges was the clearest articulation of pure coding I can recall having read. The competitors are judged against each other and by good practice standards. For these competitions students must both plan their solution and hand code the elemental "design pattern" which the problem requires to finish within time limits. Thus, the solution to your concern regarding CnP programming is to test if the students can write the same "code chunks" they are CnP'n!

I'm sure it was in the NY Times. A quick search didn't find it. A similar example is ACM's International Collegiate Programming Contest. This contest emphasizes speedy programming: "Lightning-quick programming in team competition is a decidedly quirky skill, not exactly one many job seekers would place at the top of a résumé." Thus I would recommend abstraction from real-world problems is the answer.


HP Code Wars


1) Teach them the history of computers, programming. 2) Teach how different programming languages work. 3) Teach what a good programming and programming practices are. 4) Teach them how to analyze a problem, find a solution and then start coding.


I taught introductory programming at the college level. It was a bread-and-butter course, all the faculty did it, and I think we did it quite well. We followed a common text and had common exams, but we each had our own classroom method that worked. It's been a long time since then, but occasionally I get to tutor some kid in programming, and the whole picture is about the same.

The way I do it is to start at the bottom, as concrete as possible. What students know is a structure. They already have a lot of concepts. I am building further concepts on top of those, and I am pruning off concepts they may form which are counter-productive. At the same time, I make them learn by doing.

I had built a little computer with an Intel 8008 chip, some EPROM, and a few circuits. I had programmed it to play a little duet when the I/O chip was connected to a couple speakers. I would explain how the little program worked, with an inner loop to count down a counter. That would act as a delay. Then it would toggle the output bit and do it again. It would do that for a while, and then switch to another delay, giving another pitch, and so on. The memory chip had a little timer, and if I tucked a capacitor lead under one of the timer inputs, the program would run veeeeery slowly. The class could hear the speakers going click, click, click... I wanted the class to understand that the computer was doing very simple things one step at a time. Then I would un-hook the capacitor lead, and the "music" would burst forth. (applause)

Then I had built a simulator for a very simple decimal computer, having 1000 memory locations, each holding a signed 4-digit decimal number. It had very simple opcodes like "add to accumulator", "jump if negative", and so on. I would have them write little programs in this "machine language", like adding two numbers, or adding up a list of numbers. Then they could watch it work by single-stepping, or holding down the Enter key to watch it run "fast".

The point of this was to put in place the concept that computers can only do a very small number of different basic operations, and they do them one-at-a-time. This is to counter the impression they have that computers are complicated, and that they do everything all at the same time, and read your mind in the bargain.

From there we went on to programming in a "real" language (BASIC :), starting with very simple but interesting programs, working up through conditionals, loops, arrays, files, merging, and so on. The object was to put in place a sufficient skill set so they could take on a project of their own choosing, because that's the only thing that makes programming interesting - the use to which you can put it. I would throw out some ideas for projects, and then they would take it from there. I would ask for written ideas, and then progress reports, to keep them from postponing it to the last minute and then panicking. I think the projects were the best part, because they were learning under their own power.

That initial grounding in a very concrete understanding of what computers do made it much easier to teach concepts later on that would otherwise be real speed-bumps, like arrays or (in a later course) pointers. We tend to glorify the concept of "abstraction" as this wonderful thing, but it needs to be built on a concrete foundation, not on air.


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