Some great reminders to folks about cargo-cult programming by Eric Lippert. This concept was taught to me in college, I think in a CST115 class. Boy is it the truth. Sometimes programmers try to make excuses for not understanding the how - "I don't need to understand SOAP, I'm not a plumber." Well, I'm not a professional plumber either, but I do own a copy of the Consumer Reports "How to fix anything in your house." Does that make me a plumber? Hardly. Just a guy who knows that water flows through pipes. If not, I'm just an amazed townie who thanks the magical water gods when I get hot and cold running water upstairs.
During the Second World War, the Americans set up airstrips on various tiny islands in the Pacific. After the war was over and the Americans went home, the natives did a perfectly sensible thing -- they dressed themselves up as ground traffic controllers and waved those sticks around. They mistook cause and effect -- they assumed that the guys waving the sticks were the ones making the planes full of supplies appear, and that if only they could get it right, they could pull the same trick. From our perspective, we know that it's the other way around -- the guys with the sticks are there because the planes need them to land. No planes, no guys.
The cargo cultists had the unimportant surface elements right, but did not see enough of the whole picture to succeed. They understood the form but not the content. There are lots of cargo cult programmers -- programmers who understand what the code does, but not how it does it. Therefore, they cannot make meaningful changes to the program. They tend to proceed by making random changes, testing, and changing again until they manage to come up with something that works.
All this talk about cargo-cults and Mort/Elvis/Einstein reminds me of the Programming by Coincidence stories.
Do you ever watch old black-and-white war movies? The weary soldier advances cautiously out of the brush. There's a clearing ahead: are there any land mines, or is it safe to cross? There aren't any indications that it's a minefield---no signs, barbed wire, or craters. The soldier pokes the ground ahead of him with his bayonet and winces, expecting an explosion. There isn't one. So he proceeds painstakingly through the field for a while, prodding and poking as he goes. Eventually, convinced that the field is safe, he straightens up and marches proudly forward, only to be blown to pieces.
The soldier's initial probes for mines revealed nothing, but this was merely lucky. He was led to a false conclusion---with disastrous results. [The Pragmatic Programmers]
Being a Mort or an Einstein isn't about VB.NET vs. C#. It isn't even about VB6 programmers without CS degrees. It's about caring how code works. Not just for caring's sake (although it helps) but because it makes you a better, more well rounded, and ultimately effective programmer. So, here's MY cargo-cult-programming-by-coincidence story:
My sister in law immigrated here from Zimbabwe. She's a teacher, in her thirties, but had never driven. So, we took the Prius over to the parking lot and practiced for days. We finally got to parallel parking, and she just wasn't getting it. It just didn't make sense to her. So I said, "imagine how the front tires turn left and right when you turn the steering wheel."
"The front?" she said. "What difference does it make?" Turns out she didn't realize that the front tires were the ones that turned. She'd imagined ALL FOUR tires turning left and right when the car turns. I insisted that, no, on cars, it's just the front wheels that turn. She didn't believe me until she got OUT of the car, and watched me parallel park. She was utterly amazed that the back tires stayed straight and followed the front ones.
"You didn't know this?" I asked. She said "I never gave it any thought. I assumed they all turned, and never asked the question again."
Certainly this assumption became a problem when trying to 'debug' the process of parallel parking.