Wednesday, May 6, 2009

Programming and Experimentation

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
-- Chinese Proverb
In a recent post, Great Developers Are Not Afraid to Experiment, Scott Selikoff talks about the fear and insecurity felt by many inexperienced software developers. Scott talks about his experience as a moderator over at JavaRanch, citing the frequency of questions asking "What would happen if I executed the following code?"
Many times the author of such posts can answer the question by copying and pasting his/her code into a Java main() method and running it. Some might chalk these posts up to being lazy, but, clearly, taking the time to write a post on a message board - often signing up as a member for the first time - takes some amount of effort as well. With that, I’m going to be go with the assumption developers avoid experimenting with code because they are scared or unsure of their own knowledge.
Back in college I took a job tutoring students in the introductory computer science courses and I came to the same conclusion that Scott does in his article. I would frequently have students bring code to me and ask me what I thought of it. Some would even go so far as to ask me if I thought their code would compile. I would never answer this question directly (despite Head First Java repeatedly urging me to "Be the Compiler"), but would instead patiently show them how to answer it for themselves. These students weren't lazy, they were scared. In many cases it seemed like they were more scared of being wrong than they were of not knowing the answer. They hadn't learned to experiment yet.

It's important to understand this fear if you're in any kind of position to help people get past it, whether you're a teacher, a writer, a mentor, or just a guy who answers a lot of questions on a programming Q&A web site. If you're a really good programmer, one of your key personality traits is probably an innate sense of curiosity (I'm generalizing, but take a look around at the good programmers you know and see if you disagree). You probably couldn't stop experimenting if you tried. For those of us who have the curiosity trait, it can be puzzling when we encounter someone who lacks it.

Luckily, curiosity is contagious. If you show someone how experimentation works in programming, and you're enthusiastic about learning with them, they might catch the bug from you. I had very few students who were disappointed that I wouldn't just tell them the answers to their programming assignments. Most of them wanted to learn how to do it for themselves once they were convinced that they could.

If you are a teacher or a mentor, the best thing you can do for your student is show them how to find answers on their own. Teach them how to find out what a compiler warning means (don't tell them what it means, even if you know). Teach them how you'd write a test to exercise a tricky piece of code. Teach them how the debugger works.

As the proverb says, "Teach a man to fish..."

2 comments:

Bill the Lizard said...

BruceA,
Thanks for reading!

Johannes Rössel said...

While I generally agree that trying out is faster and easier than asking others (and I tend not to ask such questions anyway), there are some pitfalls.

In the operating systems course in my fourth term we had the following task (translated for your convenience :-)):

Explain the following C program. Use a book on the C programming language. Generally it is not advisable to run programs one doesn't know to find out what they do.

Source code (linked since I won't try formatting this in a tiny box in a web page).

Sure, most things a learning programmer might stumble over aren't malicious but learning to read and understand code without executing it it in my opinion still an invaluable skill.

One of my first jobs here at the uni was to grade student homeworks (first and second term) and overall I think it helps reading code but not executing it. You gain a more thorough understanding for how things work and don't try to treat code simply as magic black box that somehow executes and produces results.

You're back to the point of reading and understanding code anyway when debugging.

That being said, I also definitely agree that teaching people to find a specific answer is better than simply giving them the answer even if it might be trivial for oneself. I tend to follow that when giving tutoring for friends or other people. I gradually lead them with questions and hints until they arrive at the point where they can see the solution. Worked well so far even though it can be much effort at times.