Cargo cult programming -The term 'cargo cult programmer' may also apply when an unskilled or novice computer programmer (or one not experienced with the problem at hand) copies some program code from one place and pastes it into another place, with little or no understanding of how the code works, or whether it is required in its new position. - Wikipedia
Proverb -Give a man a fish, feed him for a day. Teach a man to fish, feed him for a lifetime.
Not long ago, as lead developer in a contract position, I was put nominally in charge of mentoring a young in-house developer. I don't know that I'm much of a mentor, to be honest - I do my best to explain things in a clear, patient manner when I'm blogging, but have all the typical impatience of an older dev who knows what he's doing and doesn't want to be interupted to explain things during the workday. "What did Mr. Google say?" was used more than it probably should have been.
Be that as it may, I did try, and we both made progress. However, one issue I had with him repeatedly was, every time I would do a code review I would see things like:
Cargo cult programming. Finding an example of code you think will do the job you are after, and just blindly copy/pasting it into your codebase without ever understanding a line of it.
It's how we all get going, really - not going to call the kettle black. But we all know it really isn't desireable, and that we can't really move up in our skills until we escape it. So, since we know it is bad - tell me:
Why do we teach it?
We can't really fault all these new programmers for copy/pasting code if we're the ones supplying the code they are copy/pasting from, can we? As more and more of the world is driven by computers, more and more people will be joining the programmer ranks - most without the benefit (is it?) of a four-year Comp Sci degree, or even any formal training whatsoever. Instead, they learn from asking questions on forums like Stackoverflow - which encourages task-driven answers over deeper explanations. Which, I will argue, help perpetuate the cycle of asking the same "noob" questions over and over, since the poster isn't learning how to diagnose and solve his question himself.
So what can we do about it?
Teach ideas, not answers. Here are a few of my own ideas - ideas for discussion, not always applicable, never absolute. Mostly these are more for writing tuorials, but I think you can apply them to forum answers or other venues, as well.
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.
I'm sure there are many more ideas, or improvements on the above. I look forward to discussing these more with you on HackerNews.
Jeff Madsen is a web applications programmer living in Japan. Follow him on Twitter if that's your thing, or drop him a line about an interesting project. Or don't, if you don't want to.