We start novice academic programmers, the population we are working to reach with these workshops, with a fundamental polyglot mindset because often coders can get caught up in the weeds of one language and can't see past working in that one narrow context. This harms their capabilities to use UNIX style systems to chain small simple programs together to do really big cool things. This is further compounded when many really cool academic software libraries rely on peer reviewed libraries like BLAS and the Boost libs and etc. We want people to feel confident and to look at the source. We want the million eyeballs approach to FOSS development. So we need to foster confidence and motivate people to not be afraid to read code. We want novices to learn to roll into the process and learn the fundamentals of computer programming, i.e. data types and day-one algorithmic thinking, rather than panicking and shutting down. A GUI throws a lot at you all at once and a CLI is only a prompt and a cursor. We've been discussing a lot about cognitive load theory, and maybe the mainstream Corporate driven CS pedagogy that focuses on GUI IDEs is a part of the problem.
Also, you're gonna want to bash on that Linux-driven big iron out there someday, so you might as well start learning how now. Pun intended. On Sun, Mar 25, 2018 at 3:26 PM, Andrew Francis < andrew.fran...@mail.mcgill.ca> wrote: > Hello Maxim: > > > >Please don't think that I'm a hardcore pedant, but... SWC, in fact, > teaches Command Line Interface (CLI), not just some abstract "Shell" > > > To me, shell is a synonym for command-line interface. > > > >Toyota and others have to enforce this feedback loop (to stay > competitive, lower prices, "improve"). > > > Any organisation, or person can benefit from the principles of various > manufacturing/inventory control/quality > > management techniques (i.e., Just-in-time from Kaizen and say the notion > of not tying up money in the form of [excess] > > inventory). So "stay competitive, lower prices" are just end goals of a > for profit company in an particular industry. > > > Yes there is some feedback loop in these systems. However I would argue a > hallmark of many of the > > aforementioned systems is some form of statistical quality control. And > an extensive toolbox concerning stuff > > like defining metrics. Comparing stuff like Kaizen to CLI (or CLI as > Kaizen) just seems to be a comparing > > apples-to-oranges argument. > > > I am looking at my tattered copy of the "Black Belt Memory Jogger: A > Pocket Guide for Six Sigma Success." I think it would > > be far more interesting to see what techniques could be used to improve > SWC. > > > Cheers, > > Andrew > > > P.S - I have limited knowledge of SWC. However I have been to workshops > about teaching SWC that remind me of > > say "quality circles" that come out of Kaizen. > > > ------------------------------ > *From:* Belkin, Maxim <mbel...@illinois.edu> > *Sent:* 25 March 2018 14:16:23 > *To:* Andrew Francis > *Cc:* Moore, Nathan T; discuss@lists.software-carpentry.org > *Subject:* Re: [Discuss] Why do we have to do the Shell lesson? > connection to Toyota, Kaizen? > > Please don't think that I'm a hardcore pedant, but... SWC, in fact, > teaches Command Line Interface (CLI), not just some abstract "Shell" (to > teach "Shell", we'd have to unset PATH). And CLI comes hand-in-hand with > REPL <https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop>. > If you abstract away from "human vs. computer" thing, each "party" in REPL > waits for some input from the other party, processes it and provides > feedback. So, there is a *continuous feedback loop* that is built into > CLI. This is, in my opinion, the true beauty of CLI. Toyota and others have > to enforce this feedback loop (to stay competitive, lower prices, > "improve"). > > What we (humans) decide to do with the free time we get as a benefit from > using computers - is totally up to us. We could use it to do some > "important work" (e.g. improve Unix toolset)... or think about abstract > things as an exercise to the brain 🙄. The latter exercise is what > computers can't do. Yet. > > Maxim > > > > On Mar 25, 2018, at 11:14, Andrew Francis <andrew.fran...@mail.mcgill.ca> > wrote: > > Hi Nathan: > > I have a graduate background in operations management including a green > belt in Total Quality Management (TQM). > I admit I am not a practitioner and it has been a while since I have > thought about this stuff. I have not read "The Toyota Way," > but I am familiar with kaizen (as practised on a factory floor as opposed > to the software methodology) and continuous improvement > methodologies. > > For me, the core of TQM is a cycle based around describing, measuring, > analysing, improving and controlling a process. > I feel the UNIX shell and its utilities is a tool set to achieve specific > manual and automated tasks. One wants to be competent > with a shell much in the same way one wants to be competent with a lathe > or a CNC machine used in a work flow. > So I think there is a little bit of stretching analogies here. I think you > could make a better argument if you said that continuous > improvement methodologies should be used to better the quality of SWC > programmes themselves. > > Cheers, > Andrew > > > > > > ------------------------------ > *From:* Discuss <discuss-boun...@lists.software-carpentry.org> on behalf > of Moore, Nathan T <nmo...@winona.edu> > *Sent:* 25 March 2018 09:30 > *To:* discuss@lists.software-carpentry.org > *Cc:* bkallenbe...@udayton.edu; Ferstl, Andrew D; Phan, Chris L > *Subject:* [Discuss] Why do we have to do the Shell lesson? connection to > Toyota, Kaizen? > > I've been reading "The Toyota Way to Continuous Improvement" by Liker & > Franz. I think there's a connection between the stories in this book and > the SWC Shell lesson that we insist is in every workshop. > > The book describes Lean/6-sigma/Kaizen strategies for improving the > efficiency of a business. I'm just a dumb physicist who's never worked in > manufacturing, so I'm sure I don't really understand the techniques. To > me, it sounds like the general practice is to have collaborative meetings, > look for more efficient ways to move material across the shop floor, and > look for ways to make/deliver the same (or better) product with fewer > people. After this, implement and see if these ideas work. > > In about half of the case studies, these increases in efficiency lead to > layoffs and corporate profits. Yuk! > > In the other half of the case studies, (this is the "Toyota Way"), instead > of layoffs, the freed up capital, space, and people-hours are used to look > for other places where the product/manufacturing process can be improved. > In practice at places like Toyota this cycle of product/process improvement > is continuous and the continuous improvement (and resource freeing) drives > a productive, continuous feedback loop. > > What does this have to do with the shell? Why should you learn the > shell? The rationale feels like the same as Kaizen - if you embrace the > shell commands, you will have more free time, which allows you to do other > important work and find other repetitive and mundane things to automate > with Shell/python etc. > > If you work in operations engineering or similar and feel I have this all > wrong, please educate me! > > Hope you are all enjoying your day. > > Nathan Moore > Physics, Winona State > _______________________________________________ > 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 > -- Kevin Vilbig
_______________________________________________ Discuss mailing list Discuss@lists.software-carpentry.org http://lists.software-carpentry.org/listinfo/discuss
