Thanks for the details Uwe. It kind of makes sense but I feel that this should have to be quite fine tuned for it to work properly. i.e. you are mixing up basic command line usage/concepts with a whole program (git) running *inside* the command line. Except if they already have some command line basics before, in which case I can see everything fitting more clearly.
Have you developed your own lessons/story for this in order to keep the flow or you just interleave the SC ones? Iñigo On Mon, 5 Mar 2018 23:25:52 +0000 "Hilgert, Uwe K K - (hilgert)" <hilg...@email.arizona.edu> wrote: > Thank you for your response, Inigo. Actually, in our experience > teaching git/GitHub as a separate, isolated item had come with an > unnecessary cognitive burden that we reduced by integating it with > Shell. The audiences we worked with were researchers (grad students, > postdocs, staff, faculty) and were driven to acquire additional > skills to help them with their research and data analysis objectives. > Not by the intent to go out and "learn Unix," or "learn programming," > or "learn git/GitHub." Their primary objective was and is to solve > problems and to learn whatever tools are needed to address a > challenge. If then the challenge becomes to access a file shared by > the instructor and alter it as part of the Shell session, then > accessing this file on GitHub, messing with it and pushing altered > versions back to their own GitHub accounts turns actually into rather > effortless adoptions of the practises required to use git to achieve > the objectives of accessing, updating and sharing a data file. > > So, from my experiecne having observed this at work during a few runs > of the workshop my anser to your question about "too much cognitive > load" is "No." > > Does this make any sense? > > Uwe > > > ------------------------------------------------------------------------ > Uwe Hilgert, Ph.D. > > Associate Research Professor > Director of Industry Relations, Workforce Development & STEM Training > BIO5 Institute (http://www.bio5.org), The University of Arizona > (http://www.arizona.edu) O 520-626-1367 | F 520-626-4824 > > > -----Original Message----- > From: Inigo Aldazabal Mensa [mailto:inigo_aldaza...@ehu.eus] > Sent: Friday, March 02, 2018 1:51 AM > To: Hilgert, Uwe K K - (hilgert) <hilg...@email.arizona.edu> > Cc: Byron Smith <bsmit...@gmail.com>; Software Carpentry Discussion > <discuss@lists.software-carpentry.org> Subject: Re: [Discuss] Fwd: > Default git/python lesson order > > Hi all, > > Sorry for the late reply, it seems we are having email problems > here... > > About integrating shell and git... isn't this too much cognitive load? > > And about doing Git as the last lesson, I think Byron raises some > really good points there. We'll have to think more about this. > > > Iñigo > > On Thu, 1 Mar 2018 22:49:40 +0000 "Hilgert, Uwe K K - (hilgert)" > <hilg...@email.arizona.edu> wrote: > > > Please don’t forget the option we have adopted at the UA, that is > > to integrate shell and git. > > > > ---------------------------------------------------------------------- > > -- > > Uwe Hilgert, Ph.D. > > > > Associate Research Professor > > Director of Industry Relations, Workforce Development & STEM > > Training BIO5 Institute (http://www.bio5.org), The University of > > Arizona (http://www.arizona.edu) O 520-626-1367 | F 520-626-4824 > > > > From: Discuss [mailto:discuss-boun...@lists.software-carpentry.org] > > On Behalf Of Byron Smith Sent: Wednesday, February 28, 2018 9:17 AM > > To: Software Carpentry Discussion > > <discuss@lists.software-carpentry.org> Subject: [Discuss] Fwd: > > Default git/python lesson order > > > > On Tue, Feb 27, 2018 at 11:26 AM, Maneesha Sane > > <manee...@carpentries.org<mailto:manee...@carpentries.org>> wrote: > > > > I agree, I don't see a big difference in the two schedules Iñigo > > proposed. > > > > My intuition (supported by some anecdotal evidence) is that > > learners will be worn out on Python/R if they're taught in one > > contiguous block. I much prefer splitting the programming language > > across two days not only to give the instructor a break, but also > > so that learners have time to stew on it. Teaching shell and git > > on separate days has a similar effect, since the latter is a good > > review of the former. > > > > On Tue, Feb 27, 2018 at 11:26 AM, Maneesha Sane > > <manee...@carpentries.org<mailto:manee...@carpentries.org>> wrote: > > [...] by the end of Day 2, instructors and learners alike are quite > > tired making it harder to introduce an entirely new concept like > > git that afternoon. [...] So I'd recommend against doing git the > > afternoon of day 2. > > > > On Tue, Feb 27, 2018 at 11:55 AM, April Wright > > <wright.apr...@gmail.com<mailto:wright.apr...@gmail.com>> wrote: > > > > I agree with Maneesha about not introducing git in the second > > afternoon. Git can be challenging, and hard to understand in terms > > of the motivation for use. > > > > I'll argue for git as the last session; I'm a little bit surprised > > that no one else has. I like putting git last because: > > > > * it reinforces and complements the "reproducibility" thread > > that's implicit in all of the lessons; > > * you can refer back to the other lessons (writing code) to > > motivate version control; > > * you can calibrate the cognitive load based on how engaged > > learners are; > > * some of the alternative storylines have opportunities for > > humor, and collaboration is always exciting, both of which do a lot > > to keep learners' attention. We've used this schedule (shell, > > python, python, git) in almost all of the workshops I have been > > involved with. It's kinda interesting that I haven't overlapped > > with the other camps a whole lot. > > > > Not that we need to enforce one on instructors, but it's > > challenging to take an evidence-based approach to recommending a > > schedule. Few instructors have a large enough sample size to > > overcome the variability between workshops and confidently endorse > > one of the two. Can we do any assessment based on exit surveys? > > Which schedule gets the best ratings? > > > > -Byron > > _______________________________________________ Discuss mailing list Discuss@lists.software-carpentry.org http://lists.software-carpentry.org/listinfo/discuss
