Kind of a sidebar to this thread Also related to my review of Agile Software Development by Alistair Cockburn. Why do most of us have to learn things the hard way? Why is it (the hard way) sometimes the most effective way to learn? Why do projects constantly fail despite our best efforts? Are we too stupid to learn from our own mistakes? Aren't we smart enough to learn from the mistakes of others? Why is Software Development so damn hard? These are just a few of the questions that I think the book will give you a fresh perspective on and hope for solving these mysteries.
In the book, the author tells of how he and two other seasoned developers tried to introduce the use of CRC cards to a group of newbie designers. They ended up confusing the newbies instead because each had slightly different ways of handling the cards. While the variations in their techniques made no difference to them, the newbies didn't know which one was right and which one to follow. They still couldn't see past the mechanics of the technique. Thus, the first stage of learning/practice involves following. The newbies needed a step-by-step procedure that they could follow before they could move on and realize that the variances were really just a matter of personal preference or adaptation. It seems like common sense but if you really think about it, you have probably made the same mistake in the past. Where do you think the expression "biting off more than you can chew" and "taking baby steps" came from? And have you ever wondered why so many wives would rather pay for driving lessons than take the abuse they get from their own husbands? Sometimes the teacher and student just don't meet at the right level for optimum learning. [ March 10, 2002: Message edited by: Junilu Lacar ]
I remember reading a good articles about learning/teaching styles and possible mismatches a while ago. Found it today: Gerald Grow. Teaching Learners to be Self-Directed. He names four stages of learning: Dependent, Interested, Involved, Self-directed. I think, they are kinda orthogonal to Alistair's classification. One can be a self-directed learner, yet need to go through following, detaching, and fluent stages when learning something new. I believe, being self-directed (i.e. experienced) learner helps to move from following to fluent stage faster. On the other hand, "dependant" learner, who is either inexperienced learner or simply disinterested, will unlikely make his/her way to fluent stage quickly. [ March 10, 2002: Message edited by: Mapraputa Is ]
Interesting topic, and one which I have a bit of experience in. I used to teach elementary school, a science lab, and knowing how to teach to different learning styles is a huge challenge, in any field. From the courses I took, seminars I visited, and the numerous workshops attended, there are a plethora of theories on what the different types of learners are. I've seen them range from simply choosing certain colors and that is supposed to tell you what learning style you have, to plotting out a very specific grid. I've seen people who were so set in one style that they would always follow that path. These tended to be the people who liked logical step-by-step procedures. You know, the type that actually wrote the outline before the paper :roll: It works great for them because that is their mindset. However, it can be hard on a teacher that isn't necessarily that procedural. Good thing is these people tend to force their own structure upon things. They don't adapt, they make the environment change to suit their needs. Then there are those who are extremely flexible in new situations, and are able to change their learning style to fit the environment. They take a more open-ended approach to a situation and figure what's the best way for them to get the most out of the given situation. To keep with the comparison, they would write the paper from stream of consciousness, refine it, and then write the outline if required. Sounds great, but can lead to a lot of indecisiveness and having to go back and redo things because you didn't think things out "step-by-step". I'm one of these people, and I think I could probably deal with teaching myself how to be a bit more structured every now and then. ( Of course, you throw in the interest factor, and that adds a whole new factor. I am extremely self-directed when it comes to programming, math, science-related learning, and I use teachers as facilitators/consultants (to use Map's link). However, put me into a History class, and I have to force myself to stay awake ) In software development, these two extremes in thinking/learning are pretty evident, I think. I like to sit down and start writing code with a very high-level design in mind, and refine as I go. Some people can't work at all without having a Use Case Diagram, Sequence Diagram, UML diagram, State Diagram... you get the idea. I like what you are doing with this project, it meshes these two approaches into one. You give the direction and boundaries of what to do first, second, third, etc., but within those boundaries give enough room for people to exercise their own way to approach a learning situation. With OO, that's the best way to do things. Give a general approach, but leave the details open to change. Couldn't do this in the past because the languages being developed in didn't really allow it. Thankfully that's changed
Learning the Hard Way In Appendix B of "Agile Software Development", Alistair presents some excerpts from an article by Pelle Ehn. In it Ehn tells of the difference between propositional knowledge and practical understanding. Propositional knowledge is the kind that comes from facts and things you can put into words and figures like a mountain's height or what a clarinet looks like. Practical knowledge is something you can't put your finger on such as the experience of climbing a mountain or what a clarinet sounds like. There must be something about software development that makes it so hard to do well right off the bat and that something is the need for practical knowledge. We have to experience it for ourselves in order to really understand why some things need to be done a certain way. Without that "muscle memory", we'll never be able to go into the "detaching" stage of learning on eventually to the "transcending" stage. Something I read in a new Yahoo group I discovered this morning: "If this seems crazy, do it until you're so bloody good at it that you can't remember why it seems crazy. Then decide if it's crazy" -- Ron Jeffries ( http://groups.yahoo.com/group/testdrivendevelopment/message/3 ) This, to me, lines up with what Cockburn, Ehn and Naur (author of another article presented in the appendix) wrote and explains why we learn better when we learn from our own mistakes. So, by including mistakes being made in the OO Calculator Tutorial, I hope to also help whoever is following me around to learn the hard way and force them to reflect on what should have been done. Besides, it gives me a chance to learn too Junilu
Rule Following and Tradition ... the paradox of rule-following behavior. As mentioned, many rules that we follow in practice can scarcely be distinguished from the behavior in which we perform them. We do not know that we have followed a rule until we have done it. The most important rules we follow in skillful performance defy formalization, but we still understand them. ...Through mastery of the rules comes the freedom to extend them...
Design by Doing: New "Rules of the Game" To develop the competence required to participate in the language-game requires a lot of learning within that practice. But, in the beginning, all one can understand is what one has already understood in another language-game. If we understand anything at all, it is because of the family resemblance between the two language-games... As long as the language game of design is not a nonsense activity to any participant but a shared activity for better understanding and good design, mutual undestanding may be desired but not really required.
I can really relate to this stuff... how about you folks? Junilu [ March 15, 2002: Message edited by: Junilu Lacar ]