When learning a new system instead of trying to read through what other people have done one can instead try to build a simple prototype version of what one needs to understand entirely on ones own. Guides that lead you tiny step by tiny step only give you someone elses's solution. It is often better to have a discussion of the problem, understand the big ideas involved, and quickly learn some of the "gotchas" that aren't obvious from first principles. Then try one of your own "toy" solutions out.  Finally you can compare your solution to that of the "expert" and try to understand why your solution differs from theirs (if it does).  This kind of learning gives you a more "holistic" view of the problem and its solution.

see also  "PatternsForDesigningInTeams" by CharlesWeir. 

(reformatted to 3rd person view from KyleBrown s contribution)
----
Strong agreement here as well. I find that I am not at all interested in the ToyProblems that so many courses have that have a '''single right answer'''. It just does not reflect the reality in which we have to develop software. There are always multiple right answers, it's just that each answer has different long term consequences.

I reflect this experience in some OO courses that I teach. Yes, there are the  obligatory ToyProblems, but there is no worked out solution that everyone is supposed to divine. This is disconcerting to some participants, but it better reflects their reality in that I am able to coach them in improving their solution. Whenever I find myself steering people towards what I feel is the '''best''' solution, I know it is time to start using a different problem.

-- PeteMcBreen


see LearningByDoing
----
CategoryEducation CategorySolutions