(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)
Friday, February 08, 2008
If you want to pass, cheat. If you want to learn, research
On Monday of this week, I began an experiment. I stopped looking up Ruby and Rails information in my PDF of the second edition of Programming Ruby and in the excellent on-line documentation for Rails. Every time my fingers twitched to do a search, I reached for an actual dead-tree book instead. Not one of those quick references designed for looking things up, but a book where the author actually teaches the material.
I have been looking things up using the stone-age technology of a good index. And then I’ve been reading actual explanations, not just copying code snippets off the ‘net and pasting them into my programs.
…It’s Friday afternoon and neither you nor I want to slog through a heavy essay, so let’s just flip right through the pages of metaphors and anecdotal examples from my own experience. Imagine for a moment that there were a number of really insightful remarks, a few good quotes from other bloggers or authors, and a couple of great code samples. Since we’re in a hurry, let’s jump right to the end:…
So in conclusion, if you just want to get something done quickly without gaining a fuller, deeper understanding, by all means use a cheat sheet. But if you want to actually learn more about what you’re using, the next time you need to look something up, don’t go to the cheat sheet, Don’t Google it. Look it up in an actual book like The Ruby Way
or its equally informative companion The Rails Way
. It may take a moment longer, and you can’t copy and paste. But a good book contains far more than an explanation of what to do. It shows how it works, when to do that, and why it works that way.
A good book is going to answer a question you didn’t know needed to be asked. It’s tough for a busy programmer to find time to read books from cover to cover and learn the material. But every time you need to look something up, you have a golden opportunity to research the material instead of cheating the answer. Use those opportunities to learn: That knowledge is going to make you a better programmer.
On Monday of this week, I began an experiment. I stopped looking up Ruby and Rails information in my PDF of the second edition of Programming Ruby and in the excellent on-line documentation for Rails. Every time my fingers twitched to do a search, I reached for an actual dead-tree book instead. Not one of those quick references designed for looking things up, but a book where the author actually teaches the material.
I have been looking things up using the stone-age technology of a good index. And then I’ve been reading actual explanations, not just copying code snippets off the ‘net and pasting them into my programs.
…It’s Friday afternoon and neither you nor I want to slog through a heavy essay, so let’s just flip right through the pages of metaphors and anecdotal examples from my own experience. Imagine for a moment that there were a number of really insightful remarks, a few good quotes from other bloggers or authors, and a couple of great code samples. Since we’re in a hurry, let’s jump right to the end:…
So in conclusion, if you just want to get something done quickly without gaining a fuller, deeper understanding, by all means use a cheat sheet. But if you want to actually learn more about what you’re using, the next time you need to look something up, don’t go to the cheat sheet, Don’t Google it. Look it up in an actual book like The Ruby Way
or its equally informative companion The Rails Way. It may take a moment longer, and you can’t copy and paste. But a good book contains far more than an explanation of what to do. It shows how it works, when to do that, and why it works that way. A good book is going to answer a question you didn’t know needed to be asked. It’s tough for a busy programmer to find time to read books from cover to cover and learn the material. But every time you need to look something up, you have a golden opportunity to research the material instead of cheating the answer. Use those opportunities to learn: That knowledge is going to make you a better programmer.
Comments on “If you want to pass, cheat. If you want to learn, research”:
<< Home
This post reminded me of this:
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.
Source
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.
Source
I imposed a strict rule on myself years ago: I never write code I don't understand. I still use cheat sheets, but I use them as fast ways to find the material I need to learn. When I find what I want, if I don't immediately understand it, I head off to irb and play with it until I do. Takes more time, but as you point out, the goal is not efficiency, but effectiveness.
Personally I use the following in irb:
[].methods.grep /whatever/
(substituting [] with "" etc as needed)
[].methods.grep /whatever/
(substituting [] with "" etc as needed)
I fully agree with the spirit of the post, however I disagree with the characterization of The Ruby Way as a good book. Too much hand waving and "it's magic" for my taste.
I am not ashamed to say that I have learned from reading The Ruby Way, much much more than from reading the Pick Axe book.
However, I’m eager to hear readers’ views on which pure Ruby book provides the greatest value.
What would you (yes, all of you) recommend?
However, I’m eager to hear readers’ views on which pure Ruby book provides the greatest value.
What would you (yes, all of you) recommend?
You don't need to be ashamed at learning from a book, Reg. :-)
Take this all with a grain of salt. Ruby is the the first adventure for me into "unexplored territory". Normally I have the advantage of learning established (CS) subjects, and taking the advice of the Internet for the best book on a given subject. Ruby is pretty immature right now.
My company recently transitioned to Ruby + Rails, so we have a collection of Ruby books laying around. I've read or flipped through the Pick Axe book, The Ruby Way, and The Ruby Cookbook. I learned something from each, but I wouldn't qualify any of them as good. I probably learned the most from the chapter on the C interface in the pickaxe book.
I think the issue of "hand-wavy" Ruby books is partly the result of the Ruby culture. In Agile Web Development w/ Rails, there is a sidebar that goes something like "Q: How does this all work? A: It's Magic! You don't want to invite people who don't believe in magic to Christmas".
Because the culture values the "feel" of the language more than having a spec, the books are all sort of vague. I guess that's sort of ok for quick web development, but it doesn't really make me feel comfortable about doing "real" work with the language.
Sorry for the rant/tangent. This commenting thing is fun. I should start my own blog. :-)
Take this all with a grain of salt. Ruby is the the first adventure for me into "unexplored territory". Normally I have the advantage of learning established (CS) subjects, and taking the advice of the Internet for the best book on a given subject. Ruby is pretty immature right now.
My company recently transitioned to Ruby + Rails, so we have a collection of Ruby books laying around. I've read or flipped through the Pick Axe book, The Ruby Way, and The Ruby Cookbook. I learned something from each, but I wouldn't qualify any of them as good. I probably learned the most from the chapter on the C interface in the pickaxe book.
I think the issue of "hand-wavy" Ruby books is partly the result of the Ruby culture. In Agile Web Development w/ Rails, there is a sidebar that goes something like "Q: How does this all work? A: It's Magic! You don't want to invite people who don't believe in magic to Christmas".
Because the culture values the "feel" of the language more than having a spec, the books are all sort of vague. I guess that's sort of ok for quick web development, but it doesn't really make me feel comfortable about doing "real" work with the language.
Sorry for the rant/tangent. This commenting thing is fun. I should start my own blog. :-)
Yeah. But I don't think this post, however well-meaning, will curb the abusers. If they're ok with cut-n-paste (,etc.), I doubt they'll be here. -steve
One of the amazing things about it all is that "Cut and Paste" people can provide actual value to their bosses or customers.
Feel free to pass-through the credit to the creators of Rails, or to the discoverers of quantum mechanics. Or even to the Creator of the Universe.
But the phenomenon exists.
Astonishingly, there was a time when organizations had no network and no computers at all.
Feel free to pass-through the credit to the creators of Rails, or to the discoverers of quantum mechanics. Or even to the Creator of the Universe.
But the phenomenon exists.
Astonishingly, there was a time when organizations had no network and no computers at all.
One of the amazing things about it all is that "Cut and Paste" people can provide actual value to their bosses or customers.
I am not amazed: doing a quick lookup in a cheat sheet is always faster than researching something in more depth. if researching something saves you a lot of time on that task, it's an immediate win and yoiu are faster. But sometimes it doesn't pay off until you are doing some other task, where you were guided by what you learned researching this task.
Meaning, it is often an investment in the long term, not the short term. That is a very difficult investment to make, most people cannot or will not consistently invest in themselves, and most businesses have this trouble as well.
Tangent, I know, but it reminds me of the Java Closures debate that is descending into a farce. Deciding whether to leave closures out of Java because programmers may have trouble understanding them is a classic case of sacrificing the long term for the short term.
Hopefully nobody is saying that Java programmers are too stupid to understand them, just that nobody thinks learning them is worth the effort.
Seems like teh same thing to me.
I am not amazed: doing a quick lookup in a cheat sheet is always faster than researching something in more depth. if researching something saves you a lot of time on that task, it's an immediate win and yoiu are faster. But sometimes it doesn't pay off until you are doing some other task, where you were guided by what you learned researching this task.
Meaning, it is often an investment in the long term, not the short term. That is a very difficult investment to make, most people cannot or will not consistently invest in themselves, and most businesses have this trouble as well.
Tangent, I know, but it reminds me of the Java Closures debate that is descending into a farce. Deciding whether to leave closures out of Java because programmers may have trouble understanding them is a classic case of sacrificing the long term for the short term.
Hopefully nobody is saying that Java programmers are too stupid to understand them, just that nobody thinks learning them is worth the effort.
Seems like teh same thing to me.
This is a great post - I even starred it in Google reader because it sums up my approach and also explains, quite nicely, why I blog with simple code examples all the time.
I have to switch languages all the time for my job and oftentimes I am involved with projects that I have involve techniques or technologies I have never used before. So, I not only try to learn as much as I can about what I am "borrowing" but also I try to explain things that to many more experienced people might seem obvious at first glance.
A kind of "pay it forward" approach
I have to switch languages all the time for my job and oftentimes I am involved with projects that I have involve techniques or technologies I have never used before. So, I not only try to learn as much as I can about what I am "borrowing" but also I try to explain things that to many more experienced people might seem obvious at first glance.
A kind of "pay it forward" approach
<< Home
