I think almost all code that is interesting is, in some sense, derived from both existing code and written code, so maybe we should rephrase the discussion?
Perhaps something like, "We need to encourage participants to learn how to dissect existing code and understand how it is constructed and why, and show them how to go from an understanding of someone else's code to code of their own." Or, if you prefer the other direction, "We need to provided participants with the concepts and tools to dissect a problem and write coherent useful tools and to read and understand other people's code." Regardless of the direction, isn't the overall goal the same? Again, at the rudimentary level, there are severe limits on what a learner can do because of limited vocabulary and experience, so we will also be restricted to what we can realistically expect people to understand when going in either direction. Providing a comprehensible cognitive framework (a 'narrative', in some parlance) on which to hang the many details in a workshop does help with retention.[1] I think that is what we are meaning when we talk about the 'top down' approach. Especially in the age of Google and StackOverflow, I think teaching people to understand what they read is very useful. I think any evaluation needs to be put into context. I would do things differently for a group of working scientists who already write code, have tools, but may not be employing them effectively than I would for a group of people who are not programmers, may have some trepidation about the computer and their abilities, and may have expectations of failing at this programming thing. I would also evaluate proposed lessons for those groups using very different criteria. -- bennet [1] See How Learning Works, Chapter 1, the art history example. I don't find a bibliography on the SWC web site? Perhaps that would be useful for people. On Mon, Nov 14, 2016 at 7:57 AM, C. Titus Brown <ctbr...@ucdavis.edu> wrote: > On Mon, Nov 14, 2016 at 09:34:09AM +0000, Jan T Kim wrote: >> When using the "top down" approach of starting with a prepared piece of >> working code, I'd suggest that learners should be made aware that code >> is normally developed from scratch, rather than by modifying existing code, >> and encouraged / empowered to "reversely engineer" how the example code >> was developed in the first place. > > Hi Jan, > > while I don't have any evidence to the contrary, I also don't have any > evidence > *for* the statement that "code is normally developed from scratch, rather than > by modifying existing code." In my experience many people (including myself) > start from modifying existing code most of the time. Are there any sources of > evidence (surveys, publications) that tell us? > > The closest thing I found is: > > Hannay et al, 2009 > http://software-carpentry.org/files/bib/secse-survey-2009.pdf > > which doesn't directly address the question, but does show that most > scientist do not have any formal training in software development. > > best, > --titus > > p.s. I know everyone will have opinions - I'm more curious if we *know* > anything here :) > _______________________________________________ > Discuss mailing list > Discuss@lists.software-carpentry.org > http://lists.software-carpentry.org/listinfo/discuss _______________________________________________ Discuss mailing list Discuss@lists.software-carpentry.org http://lists.software-carpentry.org/listinfo/discuss
