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?

  • 8
    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
  • 50
    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
  • 67
    Have you considered FAILING them a couple of times, not everyone is cut out for software development! They aren't all special snowflakes! – user7519 Dec 1 '11 at 21:14
  • 6
    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
  • 9
    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


I would like to point out teacher problem, with an intuitive seeing.

An actor (cinema) is someone with bankable image (able to sell it), a star for everybody look at it.

An actor (theater) is someone with skill ability to put itself in the author's roles, to shadow its ego behind his knowledge to give some part itself.

To enrich (with science and knowledge) your students you have to live in course like a theater's actor.

You need, beyond a solid technical knowledge, to give something from you : you are not a graduate/technical man knowing all about the informatic subject bound to delivery sentence like a book,

... but a man with experience (a possible begining of intuition) with a panel of courses and exercices sharing experience and live knowledge.

Then you can demand to your students to have the same approach : not buy knowledge/grade, but assimilate a language and hability to master it, do something that you cannot copy/past, but which links spirit at job.

All tips given above are useless or not : are you able to be self confident, do you have guru/theater like mastery. To reach this level, theater's courses may give you the pawl/spark. A good way to "know yourself" not in procedural manner.

The problem : it is up to you : you have to leave your seat, have consciousness of your body and space and other techniques, want to go deeper in language (what is beyong words, methods)

... a 'work' for all your live, with creativity skill. ... or not : all this 'work' for 5% of my job? (so, ask you what is "being alive") ...

In hope it is English readable,



I wrote a blog piece about this, from the perspective of what we programmers who write tuts should be doing differently to help alleviate this issue among junior (I hope!) professional programmers, and in part blaming it on us. I think the way we create material for them is an essential part of this problem. Some suggestions I make:

Break your code into small, incomplete parts : This is really just a mechanical thing, and possibly a bit of a "controversial" suggestion. Don't post large bits of working code in your tutorial. Make them work to put it all together, hopefully while actually reading and understanding each part. This is not easy - there are already so many tutorials with broken code, I can see this being frustrating for a learner. But I really believe if they are at the level where they reading "How to make a login form" then they really need to work through every step on their own (and link to Stackoverflow with questions if they can't make it work)

Explain the problem before answering it: A common technique in tutorial writing is to post a block of code, then go over it line by line. I would argue that we should say what we need to add AND WHY, then add it, then repeat. So, "We will need to build a form, with a post method, an element to hold our username & password, and a button to submit", then write it out. Knowing what you are looking at BEFORE you see it is a far more effective teaching method.

Teach debugging, not coding: In a recent post on this site, I tried (hopefully with some success) a new technique - I posted a bunch of broken code, then taught how to figure out what was wrong with it. Far too many new programmers do not even understand setting var_dump(); this is the number one cause of most new programmer questions, IMHO.

Go deeper, not broader: Anthony Ferrara has started a brilliant series of programming videos at Programming with Anthony. The reason I like them so much is that they pick one specific subject and really explain it "deeply". Instead of trying to make a complete "Social Widget Scroller", he just explains arrays all the way down to the memory level. Instead of trying to cover vast subjects, pick something small and explain it thoroughly and patiently.

Teach how to report the bug: Not for our own convenience. We all know how often we've figured something out while writing out the issue on some forum. The reason is simple - when you have to explain something, you have to think about it. Don't teach them to "look it up on Google" - teach them to sit and think about it, or write out a letter to themselves about the problem.

Full text: http://codebyjeff.com/blog/2013/05/death-to-teaching-cargo-programming


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.


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