> The problem here isn't that there's two perspectives (in fact, there are many more than 'two cultures of programming'), it is that you tried to teach people p

> The problem here isn't that there's two perspectives (in fact, there are many more than 'two cultures of programming'), it is that you tried to teach people programming by bombarding them with 50 new tools (git, LaTEX, shells, piping, etc). Yes, those are extremely useful tools for engineers and serious programmers. However, they really aren't necessary or core to programming so much as they are core to engineering, sysadmin-ing, typesetting, etc. Yes and no. I agree that complex tooling should be kept to a minimum. I recently help run a small intro to programming bootcamp for my bio / bio E lab with another developer and we had great success using python on JupyterHub as our teaching tool. We were also able to introduce git via the GUI in our final session and people picked up the basics pretty quickly. Keeping things as simple as possible definitely helps with learning. With that being said, we still had a lot of people questioning why you would want to use python over excel for data analysis, people asking why you would use git over dropbox, and just general confusion over why best practices matter. I think part of the problem is that it's hard to motivate people to do more work than they have to until they suffer and then see the light: using python is more time consuming than using excel; using git is harder than using dropbox; employing best practices is harder than not employing best practices in the short term. For example, I didn't understand why source control mattered until I started collaborating on projects and got lost when changes were applied. I didn't understand why unit testing mattered until I started writing larger programs and getting owned by bugs etc.