* ########################################################### Planning for Spring 2025 May 27–30th (Tues.–Fri.), IN-PERSON in the eScience Studio Website: https://uwescience.github.io/2025-05-27-uw/ Workshop Repo: https://github.com/uwescience/2025-05-27-uw/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held in-person in the eScience Studio. All sessions will be held from 9am-12pm PDT. The workshop is Tuesday–Friday instead of Monday–Thursday. * Day 1, 9am-12pm: Unix Shell * instructors: Zeb Burke-Conte * helpers: Noah Benson , Jose Cols (need to leave at 11:20) * Day 2, 9am-12pm: Git * instructors: Noah Benson * helpers: Jihyeon Bae , Eleftheria Beres , Rose Xu * Day 3, 9am-12pm: Python 1 * instructors: June Yang * helpers: Noah Benson , Zeb Burke-Conte , Jose Cols (need to leave at 11:20) * Day 4, 9am-12pm: Python 2 * instructors: Naomi Alterman * helpers: Noah Benson , Suleeporn Sujichantarart (Yui) , Jose Cols , Eleftheria Beres ########################################################### Planning for Winter 2025 January 13–16 (Mon.–Thurs.), ONLINE over Zoom Website: https://uwescience.github.io/2025-01-13-uw-online/ Workshop Repo: https://github.com/uwescience/2025-01-13-uw-online/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held online over Zoom. All sessions will be held from 9am-12pm PDT. Please sign up with your name and email ("Noah Benson "). * Day 1, 9am-12pm: * Unix Shell * instructors: Naomi Alterman * helpers: Hannah Mandell * Day 2, 9am-12pm: * Git * instructors: Curtis Atkisson * helpers: Hannah Mandell * Day 3, 9am-12pm: * Python I * instructors: Naomi Alterman * helpers: Gemma O'Connor * R I * instructors: Will Kumler * helpers: Bernease Herman Aji John ajijohn@uw.edu (Avaliable till 11am) * Day 4, 9am-12pm: * Python II * instructors: Bryna Hazelton * helpers: Gemma O'Connor , Bernease Herman (must leave an hour early) * R II * instructors: Will Kumler * helpers: June Yang Aji John ajijohn@uw.edu (Till 11am) ########################################################### Planning for Fall 2024 October 21–24 (Mon.–Thurs.), IN-PERSON in the eScience Studio Website: https://uwescience.github.io/2024-10-21-uw/ Workshop Repo: https://github.com/uwescience/2024-10-21-uw/ Organizer: Noah Benson (nben@uw.edu) IMPORTANT: The instructors of this workshop will be recorded; if you sign up to be an instructor, you will be given an opportunity to review your session's recording before we decide to post anything publicly. This workshop will be held in-person in the eScience Studio. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: Will Kumler (if necessary) * Day 2, 9am-12pm: Git * instructors: Curtis Atkisson * helpers: Surbhi Sharma surbhish@uw.edu * Day 3, 9am-12pm: Python 1 * instructors: Naomi Alterman * helpers: Surbhi Sharma surbhish@uw.edu Will Kumler Sonja Wahl swatuw@uw.edu * Day 4, 9am-12pm: Python 2 * instructors: Noah Benson * helpers: Will Kumler (need to leave 30 mins early), Sonja Wahl swatuw@uw.edu Zoe Cheng tzcheng@uw.edu ########################################################### Planning for Spring 2024 June 3–6 (Mon.–Thurs.), ONLINE over Zoom Website: https://uwescience.github.io/2024-06-03-uw-online/ Workshop Repo: https://github.com/uwescience/2024-06-03-uw-online/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held online over Zoom. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Bernease Herman * helpers: Renee Chu (renee.achu@gmail.com) * Day 2, 9am-12pm: Git * instructors: * helpers: Zeb Burke-Conte (zmbc@uw.edu). * Day 3, 9am-12pm: Python 1 * instructors: * helpers: Will Kumler , Renee Chu (renee.achu@gmail.com) * Day 4, 9am-12pm: Python 2 * instructors: Bryna Hazelton (brynah@uw.edu) * helpers: Renee Chu (renee.achu@gmail.com) * Day 3, 9am-12pm: R 1 * instructors: Curtis Atkisson * helpers: Naomi Alterman * Day 4, 9am-12pm: R 2 * instructors: Brandyn Lucca * helpers: June Yang (jyang32@uw.edu), Naomi Alterman ########################################################### Planning for Winter 2024 Jan 8–11 (Mon.–Thurs.), IN PERSON. Website: https://uwescience.github.io/ 2024-01-08-uw/ Workshop Repo: https://github.com/uwescience/2024-01-08-uw/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held online over Zoom. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: Caesar Tuguinay , Aditya Krishna * Day 2, 9am-12pm: Git * instructors: Bernease Herman (or as helper) * helpers: Trisha Prasant Brandyn Lucca (UW email pending) * Day 3, 9am-12pm: Python 1 * instructors: Rob Fatland * helpers: Ian Quah, Brandyn Lucca (UW email pending), Sven Dorkenwald * Day 4, 9am-12pm: Python 2 * instructors: Scott Sterrett * helpers: Ian Quah, Trisha Prasant ########################################################### Planning for Fall 2023 Oct 16–19 (Mon.–Thurs.), ONLINE over Zoom. Website: https://uwescience.github.io/2023-10-16-uw-online/ Workshop Repo: https://github.com/uwescience/2023-10-16-uw-online/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held online over Zoom. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: Noah Benson , YeonJoon Cheong * Day 2, 9am-12pm: Git * instructors: Valentina Staneva * helpers: Noah Benson , YeonJoon Cheong * Day 3, 9am-12pm: Python 1 * instructors: Bryna Hazelton (happy to be a helper instead if someone else wants to be the instructor) * helpers: Noah Benson , YeonJoon Cheong * Day 4, 9am-12pm: Python 2 * instructors: Noah Benson * helpers: YeonJoon Cheong * Day 3, 9am-12pm: R 1 * instructors: Naomi Alterman * helpers: Will Kumler (could be instructor if critical but prefer to help this time) * Day 4, 9am-12pm: R 2 * instructors: Ihsan kahveci * helpers: Will Kumler ########################################################### Planning for Spring 2023 May 30–Jun 2 (Tues.–Fri.), IN-PERSON in the eScience Studio. Website: https://uwescience.github.io/2023-05-30-uw/ Workshop Repo: https://github.com/uwescience/2023-05-30-uw/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held in the eScience Studio seminar room. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: Noah Benson * Day 2, 9am-12pm: Git * instructors: Bryna Hazelton * helpers: Noah Benson * Day 3, 9am-12pm: Python 1 * instructors: Abraham Flaxman * helpers: Noah Benson , Carlos Garcia Jurado Suarez * Day 4, 9am-12pm: Python 2 * instructors: Naomi Alterman * helpers: Noah Benson ########################################################### Planning for Winter 2023 February 27–March 2, ONLINE. Website: https://uwescience.github.io/2023-02-27-uw-online/ Workshop Repo: https://github.com/uwescience/2023-02-27-uw-online/ Organizer: Noah Benson (nben@uw.edu) This workshop will be held in the eScience Studio. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: McKenzie Hagen * technical: Noah Benson , Kelly Chang * Day 2, 9am-12pm: Git * instructors: * helpers: YeonJoon Cheong * technical: Noah Benson , Kelly Chang * Day 3, 9am-12pm: Python 1 * instructors: * helpers: YeonJoon Cheong * technical: Noah Benson , Kelly Chang * Day 4, 9am-12pm: Python 2 * instructors: * helpers: Kelly Chang * technical: Noah Benson * Day 3, 9am-12pm: R 1 * instructors: Naomi Alterman * helpers: Ihsan Kahveci * technical: Naomi Alterman * Day 4, 9am-12pm: R 2 * instructors: Ihsan Kahveci * helpers: * technical: Naomi Alterman ########################################################### Planning for Fall 2022 November 7-10th, IN-PERSON. Website: https://uwescience.github.io/2022-11-07-uw/ Workshop Repo: https://github.com/uwescience/2022-11-07-uw-online/ Noah Benson (nben@uw.edu): organizer/contact-person This workshop will be held in the eScience Studio. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: Kambiz Tavabi ktavabi+work@gmail.com, * technical: Noah Benson * Day 2, 9am-12pm: Git * instructors: Noah Benson * helpers: * technical: Noah Benson * Day 3, 9am-12pm: Python 1 * instructors: Rob Fatland * helpers: Naomi Alterman , Abbie Schindler (aschind@uw.edu) * technical: Noah Benson * Day 4, 9am-12pm: Python 2 * instructors: Scott Sterrett * helpers: Kambiz Tavabi ktavabi+work@gmail.com * technical: Noah Benson ########################################################### Planning for Spring 2022 May 2-5th, Remotely per Zoom. Website: https://uwescience.github.io/2022-05-02-uw-online/ Workshop Repo: https://github.com/uwescience/2022-05-02-uw-online/ Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation Noah Benson (nben@uw.edu): organizer/contact-person This workshop will be held in a single Zoom room on days 1 and 2 and in two separate Zoom rooms (for Python and R) on days 3 and 4. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Naomi Alterman * helpers: (Jen Sobeck), McKenzie Hagen * technical: Jane Koh * Day 2, 9am-12pm: Git * instructors: Naomi Alterman * helpers: McKenzie Hagen Emilia Gan * technical: Jane Koh * Day 3, 9am-12pm: Python 1 * instructors: Rob Fatland * helpers: (Jen Sobeck) Emilia Gan , Abbie Schindler * technical: Jane Koh * Day 4, 9am-12pm: Python 2 * instructors: Abraham D. Flaxman abie@uw.edu * helpers: Emilia Gan , Abbie Schindler * technical: Jane Koh * Day 3, 9am-12pm: R 1 * instructors: Valentina * helpers: McKenzie Hagen * technical: Noah Benson * Day 4, 9am-12pm: R 2 * instructors: * helpers: Gang Li , happy to teach day 3 as well * technical: Noah Benson ########################################################### Planning for Winter 2022 January 10-13th, Remotely per Zoom. Website: https://uwescience.github.io/2022-01-10-uw-online/ Workshop Repo: https://github.com/uwescience/2022-01-10-uw-online/ Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation Noah Benson (nben@uw.edu): organizer/contact-person This workshop will be held in a single Zoom room. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm: Unix Shell * instructors: Hannah Burkhardt (haalbu@uw.edu) * helpers: Scott Sterrett (scott0@uw.edu) Noah Benson (nben@uw.edu) * technical: Jane Koh * Day 2, 9am-12pm: Git * instructors: Noah Benson (nben@uw.edu) * helpers: Hannah Burkhardt (haalbu@uw.edu) * technical: Jane Koh * Day 3, 9am-12pm: Python 1 * instructors: Naomi Alterman (naomila@uw.edu) * helpers: Derya Gumustel (deryag@uw.edu), Scott Sterrett (scott0@uw.edu) * technical: Jane Koh * Day 4, 9am-12pm: Python 2 * instructors: Naomi Alterman (naomila@uw.edu) * helpers: Derya Gumustel (deryag@uw.edu), Scott Sterrett(scott0@uw.edu) * technical: Jane Koh ########################################################### Planning for Fall 2021 October 11th - 14th, Remotely per Zoom. Website: https://uwescience.github.io/2021-10-11-uw-online/ Workshop Repo: https://github.com/uwescience/2021-10-11-uw-online/ Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation Noah Benson (nben@uw.edu): organizer/contact-person This workshop will be held in a single Zoom room on the first two days and will split into R and Python rooms on the third and fourth days. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm * Room 1: the Unix shell * instructors: Bryna Hazelton (I'm happy to let someone else do this, but I can if no one else signs up) * helpers: Naomi Alterman (naomila@uw.edu) * technical: Jane Koh * Day 2, 9am-12pm * Room 1: Git * instructors: [Happy to allow for a new SWC instructor as I have taught plenty, but happy to fill in if not] Bernease Herman (bernease@uw.edu) * helpers: Naomi Alterman (naomila@uw.edu) * technical: Jane Koh * Day 3, 9am-12pm * Room 1: Python * instructors: * helpers: Rob Fatland, Anupama Jha (anupamaj@uw.edu) * technical: Noah Benson * Room 2: R * instructors: Anthony Barente (valenta4@uw.edu) * co-instructor: Timothy Middelkoop (tmiddelkoop@internet2.edu) (just got certified - can only do day 3) * helpers: Naomi Alterman (naomila@uw.edu) * technical: Jane Koh * Day 4, 9am-12pm * Room 1: Python * instructors: Will Fondrie (wfondrie@talus.bio), I can help instead if needed * helpers: Rob Fatland * technical: Noah Benson * Room 2: R * instructors: Naomi Alterman (naomila@uw.edu) * helpers: Anthony Barente (valenta4@uw.edu), happy to teach as well * technical: Jane Koh ########################################################### Planning for SnowEx 2021 Software Carpentry June 21-22nd, Remotely per Zoom. Website: Workshop Repo: Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation __: organizer/contact-person beginners) workshop (9am-12pm PST) Preliminary schedule: https://snowex-hackweek.github.io/website/preliminary/swc.html *Day 1: Monday June 21, 2021¶ Time Topic 00:00 - 00:10 Getting connected to JupyterHub environment via GitHub 00:10 - 00:20 Orientation to the JupyterHub environment 00:20 - 01:10 Unix Shell (Topics 1 to 4) 01:10 - 01:30 Break 01:30 - 3:30 Git/GitHub (Topics 1 to 8) Instructor: HP & Joachim Meyer (j.meyer@utah.edu) Helper 1: Scott will help out initially to make sure people can sign in Helper 2: Naheem Abdesi (naheemadebisi@u.boisestate.edu) Helper 3: HP Marshall, hpmarshall@boisestate.edu *Day 2: Tuesday June 22, 2021¶ Time Topic 00:00 - 00:30 More orientation to IPython and Jupyter 00:30 - 01:50 Python Programming (Topics 1 to 4) 01:50 - 02:10 Break 02:10 - 03:10 Python Programming (Topics 6 to 9) IPython & Jupyter Instructor: Scott Henderson, scotty@uw.edu Python Instructor: Scott Henderson, scotty@uw.edu Helper 1: Joel A. Gongora, joelgongora@boisestate.edu Helper 2: Evi Ofeekze, eviofekeze@u.boisestate.edu Helper 3: Katie Breen, cbreen@uw.edu Helper 4: Naheem Abdesi (naheemadebisi@u.boisestate.edu) ########################################################### Planning for Spring 2021 May 10th - 13th, Remotely per Zoom. Website: TBA Workshop Repo: TBA Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation Noah Benson (nben@uw.edu): organizer/contact-person This workshop will be held in a single Zoom room on the first two days and will split into R and Python rooms on the third and fourth days. All sessions will be held from 9am-12pm PDT. * Day 1, 9am-12pm * Room 1: the Unix shell * instructors: Negin Valizadegan * helpers: Naomi Alterman , Noah Benson * technical: Jane Koh * Day 2, 9am-12pm * Room 1: Git * instructors: Bernease Herman * helpers: Naomi Alterman * technical: Jane Koh * Day 3, 9am-12pm * Room 1: Python * instructors: Will Fondrie * helpers: Rob Fatland , Meredith Rawls , Anupama Jha * technical: Noah Benson * Room 2: R * instructors: Calvin Pritchard * helpers: Naomi Alterman Valentina Staneva (I have a meeting 10-11) * technical: Jane Koh, Ping Chao Mamiya (helper) * Day 4, 9am-12pm * Room 1: Python * instructors: Will Fondrie * helpers: Noah Benson , Rob Fatland , Meredith Rawls (~10am+) * technical: Noah Benson * Room 2: R * instructors: Calvin Pritchard * helpers: Naomi Alterman , Valentina Staneva * technical: Jane Koh, Ping Chao Mamiya (helper) ########################################################### Planning for Winter 2021 January 11th - 14th, Remotely per Zoom. Website: https://uwescience.github.io/2021-01-11-uw-online/ Workshop Repo: https://github.com/uwescience/2021-01-11-uw-online/ Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation Noah Benson (nben@uw.edu): organizer/contact-person Python (beginners) workshop (9am-12pm PDT) Day 1 am the Unix shell: instructors: Amanda Tan helpers: Adam , Noah Benson Day 2 am Git: instructors: Chad Curtis (ccurtis7@uw.edu) helpers: Adam , Jose Hernandez helpers: Rob rob5@uw.edu, Noah Benson Day 4 am Python: instructors: Scott Henderson helpers: Rob rob5@uw.edu, Jose Hernandez ########################################################### Planning for Fall 2020 October 5th - 8th, Remotely per Zoom. Website: https://uwescience.github.io/2020-10-05-uw-online/ Workshop Repo: Jane Koh (janekoh1@uw.edu): assistance with technology and facilitation Python (beginners) workshop (9am-12pm PDT) Day 1 am the Unix shell: instructors: Noah Benson , helpers: Rob Fatland Day 2 am Git: instructors: Chad Curtis helpers: Bernease "Also Happy to Serve as Instructor" Herman , Emilia Gan Day 3 am Python: instructors: Valentina Staneva helpers: Noah Benson , Rob Fatland , Vishwa Pardeshi Day 4 am Python: instructors: Bryna Hazelton helpers: Noah Benson , Rob Fatland , (Backup, if 3 not needed) Emilia Gan ########################################################### Planning for Spring 2020 May 11th - 14th, Remotely per Zoom. Website: https://uwescience.github.io/2020-05-11-uw/ Workshop Repo: Anthony Arendt (arendta@uw.edu): assistance with technology and facilitation Python (beginners) workshop (9am-12pm PDT) Day 1 am the Unix shell: instructors: Anthony Valente (valenta4@uw.edu) helpers:, Noah Benson (nben@uw.edu), Alicia Clark (clarka34@uw.edu),Jose Hernandez(joseh@uw.edu)Valentina Staneva(vms16@uw.edu) Day 2 am Git: instructors: Bernease Herman (bernease@uw.edu) helpers: Anthony Valente (valenta4@uw.edu), Jose Hernandez(joseh@uw.edu), Backup: Amanda Tan (amandach@uw.edu) Day 3 am Python: instructors: Scott Henderson (scottyh@uw.edu) helpers: Meredith Rawls (mrawls@uw.edu - could maybe instruct), Noah Benson (nben@uw.edu), Backup: Amanda Tan (amandach@uw.edu)Valentina Staneva(vms16@uw.edu) Day 4 am Python: instructors: Bryna Hazelton (brynah@uw.edu) helpers: Jen Sobeck; jsobeck@uw.edu, Meredith Rawls (mrawls@uw.edu), Backup: Bernease Herman (bernease@uw.edu) [can instruct if still needed] ########################################################### Planning for Winter 2020 January 21st-24th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2020-01-21-uw Workshop Repo: https://github.com/uwescience/2020-01-21-uw Python (beginners) workshop Day 1 am the Unix shell: instructors: Mar Drouhard helpers: Anthony Valente Day 2 am Git: instructors: Mar Drouhard helpers: Hyeon Jeong Kim , Shervin Sahba Day 3 am Python: instructors: Daniela Huppenkothen helpers: Eleanor Lutz, lutze@uw.edu, Mar Drouhard (could be instructor if needed) Day 4 am Python: instructors: Daniela Huppenkothen helpers: Eleanor Lutz, lutze@uw.edu (needs to leave early at 10:30am), Tony Cannistra , Kristen Schwabe-Fry ########################################################### Planning for Fall 2019 October 1st-4th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2019-10-01-uw Workshop Repo: https://github.com/uwescience/2019-10-01- Suw Python (beginners) workshop Day 1 am the Unix shell: instructors: Kairsten Fay (kairsten.fay@gmail.com) - Fred Hutch helpers: Anthony Valente (valenta4@uw.edu), John Huddleston (jlhudd@uw.edu) - UW/Fred Hutch Day 2 am Git: instructors: John Huddleston (jlhudd@uw.edu) - UW/Fred Hutch helpers: Kairsten Fay (kairsten.fay@gmail.com) - Fred Hutch Day 3 am Python: instructors: Shervin Sahba (ssahba@uw.edu) helpers: Meredith Rawls (mrawls@uw.edu) - will arrive ~9:30, Alicia Clark (clarka34@uw.edu), Kristen Schwabe-Fry (ksfry@uw.edu) Day 4 am Python: instructors: Meredith Rawls (mrawls@uw.edu) helpers: Chad Curtis (ccurtis7@uw.edu) ~will have to leave early at 11 tbd/backup: Shervin Sahba (ssahba@uw.edu) ########################################################### Planning for Summer 2019 July 15th- 18th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2019-07-15-uw/ Workshop Repo: https://github.com/uwescience/2019-07-15-uw/ Python (beginners) workshop Day 1 am the Unix shell: instructors: Shervin Sahba (ssahba@uw.edu) helpers: Simon Waldman (simon@simonwaldman.me.uk) Hyeon Jeong Kim (kimh11@uw.edu) Carolin Spice (cspice@uw.edu), Ezgi Yucel (yucel@uw.edu) Day 2 am Git: instructors: Simon Waldman (simon@simonwaldman.me.uk) helpers: Shervin Sahba (ssahba@uw.edu)Carolin Spice (cspice@uw.edu) Ezgi Yucel (yucel@uw.edu) Day 3 am Python: instructors: Jaime Schatz (jaimelynschatz@gmail.com) helpers: Eleanor Lutz (lutze@uw.edu) Carolin Spice (cspice@uw.edu) Day 4 am Python: instructors: Eleanor Lutz (lutze@uw.edu) helpers: Carolin Spice (cspice@uw.edu) Ezgi Yucel (yucel@uw.edu) ########################################################### Planning for Spring 2019 April 23rd- 26th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2019-04-24-uw/ Workshop Repo: https://github.com/uwescience/2019-04-24-uw/ Python (beginners) workshop Day 1 am the Unix shell: instructors: Cecilia Noecker (cnoecker@uw.edu) helpers: HJ Kim (kimh11@uw.edu), Rob Fatland (rob5@uw.edu) 9am-2pm Day 2 am Git: instructors: Dave Williams (cdavew@alleninstitute.org) helpers: HJ Kim (kimh11@uw.edu) Day 3 am Python: instructors: Bernease Herman (bernease@uw.edu) helpers: Meg Drouhard (meg.drouhard@gmail.com), Jimmy O'Donnell (jodonnellbio@gmail.com) Day 4 am Python: instructors: Meg Drouhard (meg.drouhard@gmail.com) helpers: Cecilia Noecker (cnoecker@uw.edu), Jaime Schatz (jschatz@kingcounty.gov) ########################################################### Planning for Winter 2019 January 15th - 18th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2019-01-15-uw/ Workshop Repo: https://github.com/uwescience/2019-01-15-uw/ Python (beginners) workshop Day 1 am the Unix shell: instructors: Chad Curtis (ccurtis7@uw.edu) helpers: Yee Mey Seah (ymseah@uw.edu) , HJ kim (kimh11@uw.edu) Day 2 am Git: instructors: Michael Beyeler (mbeyeler@uw.edu) helpers: HJ kim (kimh11@uw.edu) Day 3 am Python: instructors: Wu-Jung Lee (leewj@uw.edu) helpers: Meredith Rawls (mrawls@uw.edu, willing to co-instruct but only available 10am+) Day 4 am Python: instructors: Meredith Rawls (mrawls@uw.edu) helpers: Meg Drouhard (meg.drouhard@gmail.com) Python (experienced) workshop Day 1 am the Unix shell: instructors: Ariel Rokem (arokem@uw.edu) helpers: Meg Drouhard (meg.drouhard@gmail.com) Day 2 am Git: instructors: Colin Dietrich (colinrd@uw.edu) helpers: Chad Curtis (ccurtis7@uw.edu) Day 3 am Python: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Eleanor Lutz (lutze@uw.edu) , Michael Klein (michael.e.klein@gmail.com) Day 4 am Python: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Charles Reid (charlesreid1@gmail.com) ########################################################### Planning for Fall 2018 October 1st -4th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: Workshop Repos: https://github.com/uwescience/2018-10-01-UW-swc https://github.com/uwescience/2018-10-01-UW-dc Python workshop Day 1 am the Unix shell: instructors: Kate Hertweck (k8hertweck@gmail.com) helpers: Chad Curtis (ccurtis7@uw.edu), Yee Mey Seah (ymseah@uw.edu), Callin Switzer (cswitzer@uw.edu) Day 2 am Git: instructors: Aaron Marburg (amarburg@uw.edu) helpers: Yee Mey Seah (ymseah@uw.edu), Colin Dietrich (colinrd@uw.edu) Day 3 am Python: instructors: Chad Curtis (ccurtis7@uw.edu) helpers: Bree Norlander (norlab@uw.edu), Wu-Jung Lee (leewj@uw.edu), Colin Dietrich (colinrd@uw.edu) Day 4 am Python: instructors: Bree Norlander (norlab@uw.edu) helpers: Chad Curtis (ccurtis7@uw.edu), Wu-Jung Lee (leewj@uw.edu) R (Data Carpentry) workshop (cf. http://www.datacarpentry.org/R-ecology-lesson/ ) Day 1 am Introduction to R: instructors: Jose Hernandez (jmhernandeze@gmail.com) helpers: Dan McCloy (drmccloy@uw.edu) Day 2 am Starting with data: instructors: Valentina Staneva (vms16@uw.edu) helpers: Dan McCloy (drmccloy@uw.edu), HJ Kim (kimh11@uw.edu) Day 3 am Aggregating and analyzing data with dplyr: instructors: Cecilia Noecker (cnoecker@uw.edu) helpers: Aji John(ajijohn@uw.edu), HJ Kim (kimh11@uw.edu) Day 4 am Data visualization with ggplot2: instructors: Cecilia Noecker (cnoecker@uw.edu) helpers: Aji John(ajijohn@uw.edu) "on call" backup: ########################################################### Planning for Summer 2018 August 28th-31st , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://github.com/uwescience/2018-08-28-UW Workshop Repo: https://uwescience.github.io/2018-08-28-UW/ Python workshop Day 1 am the Unix shell: instructors: Vikas Pejaver (vpejaver@uw.edu) helpers: Sam White (samwhite@uw.edu), Chad Curtis (ccurtis7@uw.edu) Day 2 am Git: instructors: Dave Williams (cdave@uw.edu) helpers: Callin Switzer (cswitzer@uw.edu), Ritvik Vasan (ritvikv@alleninstitute.org), Sam White (samwhite@uw.edu) Day 3 am Python: instructors: Eurika Kaiser (eurika@uw.edu) helpers: Meredith Rawls (~10am), Sam White (samwhite@uw.edu), Chad Curtis (ccurtis7@uw.edu) Day 4 am Python: instructors: Meredith Rawls (mrawls@uw.edu) helpers: Ariel Rokem (arokem@gmail.com), Shwetha Canchi Murali (smurali@uw.edu) R (Data Carpentry) workshop (cf. http://www.datacarpentry.org/R-ecology-lesson/ ) Day 1 am Introduction to R: instructors: Callin Switzer (cswitzer@uw.edu) helpers: Cecilia Noecker (cnoecker@uw.edu) Tiernan Martin (tiernan@futurewise.org) Day 2 am Starting with data: instructors: Aji John(ajijohn@uw.edu) helpers: Cecilia Noecker (cnoecker@uw.edu) Tiernan Martin (tiernan@futurewise.org) Day 3 am Aggregating and analyzing data with dplyr: instructors: Aji John(ajijohn@uw.edu) helpers: Jimmy O'Donnell (jodonnellbio@gmail.com) Stephen Kaluzny spkaluzny@gmail.com Day 4 am Data visualization with ggplot2: instructors: Aji John(ajijohn@uw.edu) helpers: Jimmy O'Donnell (jodonnellbio@gmail.com) Stephen Kaluzny spkaluzny@gmail.com "on call" backup: ########################################################### Planning for Spring 2018 April 16-19 , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website:https://uwescience.github.io/2018-04-16-uw/ Workshop Repo: https://github.com/uwescience/2018-04-16-uw Python workshop Day 1 am the Unix shell: instructors: Charles Reid (charlesreid1@gmail.com) helpers: Ariel Rokem (arokem@uw.edu) Bree Norlander (norlab@uw.edu) Anisha Keshavan (anishakeshavan@gmail.com) Day 2 am Git: instructors: Meredith Rawls (mrawls@uw.edu) helpers: Bree Norlander (norlab@uw.edu) can't get there until 10:00-10:15, Ariel Rokem (arokem@uw.edu) Day 3 am Python: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Emilia Gan (efgan@uw.edu), Meredith Rawls (mrawls@uw.edu) ~9:45-10:45 and ~11:15-12pm, Yee Mey Seah (ymseah@uw.edu) Day 4 am Python: instructors: Yee Mey Seah (ymseah@uw.edu) helpers: Dan McCloy R (Data Carpentry) workshop (cf. http://www.datacarpentry.org/R-ecology-lesson/) Day 1 am Introduction to R: instructors: Ben Marwick helpers: Dwight Barry (dwight.barry@seattlechildrens.org), Sam White (samwhite@uw.edu), Aji John(uw.edu) Day 2 am Starting with data: instructors: Ben Marwick helpers: Dwight Barry (dwight.barry@seattlechildrens.org), Sam White (samwhite@uw.edu),Aji John(uw.edu) Day 3 am Aggregating and analyzing data with dplyr: instructors: Ben Marwick helpers: Dwight Barry (dwight.barry@seattlechildrens.org), Sam White (samwhite@uw.edu),Aji John(uw.edu) Day 4 am Data visualization with ggplot2: instructors: Ben Marwick helpers: Sam White (samwhite@uw.edu),Aji John(uw.edu) "on call" backup: Jaime Schatz - Python (jaimelynschatz@gmail.com) ########################################################### Planning for Winter 2018 January 8, 9, 10, 11 , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2018-01-08-uw/ Workshop Repo: https://github.com/uwescience/2018-01-08-uw Python workshop Day 1 am the Unix shell: instructors: Allison Smith (kasm@uw.edu) helpers: Ariel Rokem (have to leave at 10:50! arokem@uw.edu), Jaime Schatz (jaimelynschatz@gmail.com), Jennifer Sobeck (taking over for Ariel once he departs) Day 2 am Git: instructors: Meg Drouhard helpers: Jaime Schatz (jaimelynschatz@gmail.com), Michael Beyeler (mbeyeler@uw.edu) Day 3 am Python: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Bree Norlander (norlab@uw.edu)(have to leave at 11:30), Grace Telford (otelford@uw.edu), Nick Foti (nfoti@uw.edu) Day 4 am Python: instructors: Bree Norlander (norlab@uw.edu) helpers: Dan McCloy, Meg Drouhard (Meg needs to leave at 11:15) R (Data Carpentry) workshop (cf. http://www.datacarpentry.org/R-ecology-lesson/) Day 1 am Introduction to R: instructors: Ben Marwick helpers: Aji John(ajijohn@uw.edu) (10:30-Noon), Valentina Staneva (vms16@uw.edu) Day 2 am Starting with data: instructors: Ben Marwick helpers: Stephen Kaluzny (spkaluzny@gmail.com),Aji John(ajijohn@uw.edu) (9-11AM) Day 3 am Aggregating and analyzing data with dplyr: instructors: Ben Marwick helpers:Aji John(ajijohn@uw.edu) (10:30-Noon) Tony Cannistra (not certain I can make it after all –– waiting on details.) Day 4 am Data visualization with ggplot2: instructors: Ben Marwick helpers: Aji John(ajijohn@uw.edu) (9-11AM), Valentina Staneva "on call" backup: ' Valentina Staneva: might be able to help with some of the other data carpentry sessions ########################################################### Planning for Fall 2017 October 2nd-5th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2017-10-02-uw/ Workshop Repo: https://github.com/uwescience/2017-10-02-uw/ Python workshop Day 1 am the Unix shell: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Ariel Rokem (arokem@gmail.com) Daniel Shapero (shapero@uw.edu) Jennifer Sobeck (jsobeck@uw.edu; might be able to instruct, though 1st time), Colin Dietrich (colin.dietrich@gmail.com) Day 2 am Git: instructors: Aaron Marburg (amarburg@apl.washington.edu) helpers: Dan McCloy (drmccloy@uw.edu), Floris van Breugel (floris@uw.edu), Noah Brenowitz(nbren12@uw.edu), Colin Dietrich (colin.dietrich@gmail.com) Day 3 am Python: instructors: Dave Williams (cdave@uw.edu) helpers: Daniel Shapero (shapero@uw.edu), Michael Beyeler (mbeyeler@uw.edu), Eleanor Lutz (lutze@uw.edu), Floris van Breugel (floris@uw.edu), Noah Brenowitz(nbren12@uw.edu), Colin Dietrich (colin.dietrich@gmail.com) Day 4 am Python: instructors: Michael Beyeler (mbeyeler@uw.edu) helpers: Daniel Shapero (shapero@uw.edu, Bree Norlander (norlab@uw.edu),Scott Henderson (scottyh@uw.edu), Colin Dietrich (colin.dietrich@gmail.com) R workshop Day 1 am the Unix shell: instructors: Sam White (samwhite@uw.edu) helpers: Jamie Collins (jamesrco@uw.edu Noah Brenowitz (nbren12@uw.edu; I'm a python guy, but can help with shell/git) Day 2 am Git: instructors: Jimmy O'Donnell (jodonnellbio@gmail.com) helpers: Jamie Collins (jamesrco@uw.edu),Sam White (samwhite@uw.edu Noah Brenowitz(nbren12@uw.edu), Mahesh Somashekhar (msoma@uw.edu) Day 3 am R: instructors: Peter Schmiedeskamp (peter@thoughtspot.net) helpers: Jamie Collins (jamesrco@uw.edu), Sam White (samwhite@uw.edu), Callin Switzer (callin.switzer@gmail.com) Day 4 am R: instructors: Jamie Collins (jamesrco@uw.edu) helpers:Sam White (samwhite@uw.edu), Yee Mey Seah (ymseah@uw.edu) "on call" backup: Daniel Shapero (shapero@uw.edu); Jennifer Sobeck (jsobeck@uw.edu) ########################################################### ########################################################### Planning for Summer 2017 June 13th-16th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: http://uwescience.github.io/2017-06-13-uw Workshop Repo: https://github.com/uwescience/2017-06-13-uw Python workshop Day 1 am the Unix shell: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Meg Drouhard (mdrouhar@uw.edu, Michael Wolf(dinningwolf@mac.com), Valentina Staneva (vms16@uw.edu) Day 2 am Git: instructors: Micharel Beyeler (mbeyeler@uw.edu) helpers: Aaron Marburg (amarburg@uw.edu) Dan McCloy (drmccloy@uw.edu) Day 3 am Python: instructors: Meredith Rawls (mrawls@uw.edu) helpers: Dan McCloy (drmccloy@uw.edu), Tony Cannistra (tonycan@uw.edu) Michael Wolf(dinningwolf@mac.com) Day 4 am Python: instructors: Alicia Clark (clarka34@uw.edu) - I am happy to just help though if someone else really wants to teach :) Meredith Rawls (mrawls@uw.edu) - support/backup instructor and/or helper (Alicia and I have coordinated) helpers: Eleanor Lutz (lutze@uw.edu) Dan McCloy (drmccloy@uw.edu) Michael Wolf(dinningwolf@mac.com) R workshop Day 1 am the Unix shell: instructors: Bernease Herman (bernease@uw.edu) helpers: Jennifer Sobeck (jsobeck@uw.edu) Amanda Tan (amandach@uw.edu) Day 2 am Git: instructors: Meg Drouhard (mdrouhar@uw.edu) helpers: Amanda Tan (amandach@uw.edu)Carolina Johnson (csjohns@uw.edu) Day 3 am R: instructors: Elaine Nsoesie (en22@uw.edu) helpers: Yee Mey Seah (ymseah@uw.edu), Michael Vlah (vlahm13@gmail.com), Mayuree Binjolkar (mbinjolkar@gmail.com) Day 4 am R: instructors: Elaine Nsoesie (en22@uw.edu) if someone else is available to teach, I can be a helper! helpers: Yee Mey Seah (ymseah@uw.edu) (dentist appointment conflict, sorry!), Michael Vlah (vlahm13@gmail.com), Mayuree Binjolkar (mbinjolkar@gmail.com) "on call" backup: ########################################################### ########################################################### Planning for Spring 2017 March 27th-28th, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: http://uwescience.github.io/2017-03-27-uw Workshop Repo: https://github.com/uwescience/2017-03-27-uw Python workshop day 1 am the Unix shell: instructors: Alicia Clark (clarka34@uw.edu) helpers: Ariel Rokem (arokem@gmail.com) Aaron Marburg (amarburg@uw.edu), Mike Schwendeman (mss28@uw.edu), Charles Reid (charles.reid@seattlecolleges.edu) day 1 pm Python: instructors: Bryna Hazelton (brynah@uw.edu helpers: YeeMey Seah (ymseah@uw.edu) Adam Richie-Halford (richford@uw.edu), Mike Schwendeman (mss28@uw.edu), Charles Reid (charles.reid@seattlecolleges.edu) day 2 am Git and Github: instructors: Dave Williams (cdave@uw.edu) helpers: Meg Drouhard (meg.drouhard@gmail.com) Bryna Hazelton (brynah@uw.edu), Mike Schwendeman (mss28@uw.edu) day 2 pm Python: instructors: Abraham Flaxman (abie@uw.edu) unless Bryna wants to trade with me---also I'm willing to let someone else have this fun job, just let me know if you want it helpers: Vaibhavi Rangarajan (vaibhavi@uw.edu), Adam Richie-Halford (richford@uw.edu), Mike Schwendeman (mss28@uw.edu) R workshop day 1 am the Unix shell: instructors: Meg Drouhard (meg.drouhard@gmail.com) helpers: Sam White (samwhite@uw.edu), Michael Beyeler (mbeyeler@uw.edu),Xiaofeng Meng (xmeng@uw.edu) day 1 pm R: instructors: Rachael Tatman (rctatman@uw.edu) helpers: Sam White (samwhite@uw.edu), Alathea Letaw (alathea@zoology.ubc.ca) day 2 am Git and GitHub: instructors: Allison Smith (kasm@uw.edu) helpers: Sam White (samwhite@uw.edu), Alathea Letaw (alathea@zoology.ubc.ca), Xiaofeng Meng (xmeng@uw.edu) day 2 pm R: instructors: Kivan Polimis (kpolimis@uw.edu) helpers: Sam White (samwhite@uw.edu), Alathea Letaw (alathea@zoology.ubc.ca) "on call" backup: ########################################################### ########################################################### Planning for Winter 2017 January 9th-12th , WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: http://uwescience.github.io/2017-01-09-uw Workshop Repo: https://github.com/uwescience/2017-01-09-uw Python workshop Day 1 am the Unix shell: instructors: Dan McCloy (drmccloy@uw.edu) helpers: xiaofeng meng (xmeng@uw.edu), Meg Drouhard (meg.drouhard@gmail.com), Ariel Rokem(arokem@uw.edu) Day 2 am Git: instructors: Dave Williams (cdave@uw.edu) helpers: xiaofeng meng (xmeng@uw.edu), Dan McCloy (drmccloy@uw.edu) Day 3 am Python: instructors: Jacob Schreiber (jmschreiber91@gmail.com) helpers: Meg Drouhard (meg.drouhard@gmail.com), Meredith Rawls (mrawls@uw.edu) Day 4 am Python: instructors: Abraham Flaxman (abie@uw.edu) helpers: Ariel Rokem (arokem@gmail.com), Meredith Rawls (mrawls@uw.edu), Michael Beyeler (mbeyeler@uw.edu) R workshop Day 1 am the Unix shell: instructors: Bernease Herman (bernease@uw.edu ) helpers: Yi Cao (ycao16@uw.edu) Emilia Gan (efgan@uw.edu) Kivan Polimis (kpolimis@uw.edu), Day 2 am Git: instructors: Allison Smith (kasm@uw.edu) helpers: Yi Cao (ycao16@uw.edu), Michael Beyeler (mbeyeler@uw.edu), Alex Franks (amfranks@uw.edu) Day 3 am R: instructors: Kara Woo (karawoo@uw.edu) helpers: Stephanie Ballard (ballard4@uw.edu) Emilia Gan (efgan@uw.edu) Day 4 am R: instructors: Jimmy O'Donnell (jodonnellbio@gmail.com) helpers: Dan McCloy (drmccloy@uw.edu), Alex Franks (amfranks@uw.edu) "on call" backup: Rob Fatland (basic [sic] Python) ########################################################### ########################################################### Planning for Fall 2016 October 10th-13th (9 AM - noon every day) WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://uwescience.github.io/2016-10-10-uw/ Workshop Repo: https://github.com/uwescience/2016-10-10-uw Python workshop Day 1 am the Unix shell: instructors: Adam Richie-Halford (richford@uw.edu) helpers:Ariel Rokem (arokem@uw.edu), JoseManuel Magallanes(magajm@uw.edu), Alec Deason (alecwd@uw.edu), Kjell Swedin(kjells@uw.edu) Day 2 am Git: instructors: Ben Weinstein - (weinsteb@oregonstate.edu) helpers: Adam Richie-Halford (richford@uw.edu, happy to do paired instruction for the git collaboration lessons, Ariel Rokem (arokem@uw.edu), Kjell Swedin(kjells@uw.edu) Day 3 am Python: instructors: Billy Charlton helpers: Peter Schmiedeskamp (peter@thoughtspot.net), Ariel Rokem (arokem@uw.edu), JoseManuel Magallanes(magajm@uw.edu), Alec Deason (alecwd@uw.edu)Ning Li(ningli30@uw.edu), Kjell Swedin(kjells@uw.edu) Day 4 am Python: instructors: Peter Schmiedeskamp (peter@thoughtspot.net) helpers: Ariel Rokem (arokem@uw.edu)Ning Li(ningli30@uw.edu), Kjell Swedin(kjells@uw.edu) R workshop Day 1 am the Unix shell: instructors: Sam White (samwhite@uw.edu) helpers: Dan McCloy (drmccloy@uw.edu), Meg Drouhard (mdrouhar@uw.edu), Christopher Bare (chris.bare@sagebase.org) Day 2 am Git: instructors: Dan McCloy (drmccloy@uw.edu) helpers: Sam White (samwhite@uw.edu), Bernease Herman (bernease@uw.edu), Meg Drouhard (mdrouhar@uw.edu), Christopher Bare (chris.bare@sagebase.org) Day 3 am R: instructors: Rachael Tatman (rctatman@uw.edu) helpers: Ben Marwick (bmarwick@uw.edu), Sam White (samwhite@uw.edu), Christopher Bare (chris.bare@sagebase.org) Day 4 am R: instructors: Valentina Staneva (vms16@uw.edu) helpers: Sam White (samwhite@uw.edu), Christopher Bare (chris.bare@sagebase.org), Carolina Johnson (csjohns@uw.edu) "on call" backup: Bernease Herman (bernease@uw.edu) -- Can teach Unix, Git, Python 1/2, can help in any ########################################################### ########################################################### Planning for Summer 2016 June 14th-15th, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: http://uwescience.github.io/2016-06-14-uw Workshop Repo: https://github.com/uwescience/2016-06-14-uw Python workshopabruce5116@gmail.comhttp://pad.software-carpentry.org/swc-teaching-uw day 1 am the Unix shell: instructors: Dave Wiliams (cdave@uw.edu) helpers: Emilia Gan (efgan@uw.edu), Kara Woo, day 1 pm Python: instructors: Ariel Rokem (arokem@gmail.com) helpers:Emilia Gan(efgan@uw.edu), Meg Drouhard day 2 am Git and Github: instructors: Adam Richie-Halford (richford@uw.edu) (first time teaching git, would appreciate extra helpers...have taught shell and python before) helpers: Ariel Rokem (arokem@gmail.com), Bernease Herman (bernease@uw.edu), Kara Woo, Vivek Rai (vivekrai.iitkgp@gmail.com) day 2 pm Python: instructors: Valentina Staneva (vms16@uw.edu) helpers: Billy Charlton, Vivek Rai (vivekrai.iitkgp@gmail.com), Meg Drouhard R workshop day 1 am the Unix shell: instructors: Allison Smith (kasm@uw.edu) helpers: Myeong Lee, Meg Drouhard day 1 pm R: instructors: Valentina Staneva (vms16@uw.edu) (possibly can swap with others) helpers: Myeong Lee, Carlos Espino day 2 am Git and GitHub: instructors: Jes Ford (jesford@uw.edu) helpers: Jeffrey Arnold (jrnold@uw.edu), Myeong Lee, Meg Drouhard day 2 pm R: instructors: Rachael Tatman (rctatman@uw.edu) helpers: Myeong Lee, Carlos Espino "on call" backup: Bernease Herman (bernease@uw.edu) -- can jump in on Git or Shell, also Python with few days notice to review new material Jimmy O'Donnell (jimmyod@uw.edu) -- changing roles and might need to be traveling (will confirm 1 week prior). Can help with all, instruct anything but python. ########################################################### ########################################################### Planning for Spring 2016 March 31st - April 1st, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: http://uwescience.github.io/2016-03-31-uw Workshop Repo: https://github.com/uwescience/2016-03-31-uw Python workshop day 1 am the Unix shell: instructors: Allison Smith (kasm@uw.edu) helpers: Emilia Gan, Bernease Herman day 1 pm Python: instructors: Dave Williams helpers: Emilia Gan, Jes Ford (jesford@uw.edu) day 2 am Git and Github: instructors: Rick Riehle (rriehle@uw.edu) helpers: Bryna Hazelton (bryna.hazelton@gmail.com), Ariel Rokem (arokem@gmail.com) day 2 pm Python: instructors: Jes Ford (jesford@uw.edu) helpers: Rick Riehle (rriehle@uw.edu) Chris Suberlak (suberlak@uw.edu), Jeremy McGibbon (mcgibbon@uw.edu) R workshop day 1 am the Unix shell: instructors: Jimmy O'Donnell helpers: Margaret Hughes day 1 pm R: instructors: Valentina Staneva (vms16@uw.edu helpers: Mike Vlah day 2 am Git and GitHub: instructors: Bernease Herman helpers: Valentina Staneva (vms16@uw.edu) day 2 pm R: instructors: Jeffrey Arnold helpers: Rachael Tatman , Mike Vlah "on call" backup: Ariel Rokem (arokem@gmail.com), if needed, can be helper for R sessions: Dwight Barry (dwight.barry@seattlechildrens.org), Adam Richie-Halford can help with Python sessions if needed (richford@uw.edu) ########################################################### ########################################################### Planning for Winter 2016 January 7-8 2016, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: http://uwescience.github.io/2016-01-07-uw Workshop Repo: https://github.com/uwescience/2016-01-07-uw Python workshop day 1 am the Unix shell: instructors: Bernease Herman (bernease@uw.edu) helpers: Emilia Gan (efgan@uw.edu), Jimmy O'Donnell (jodonnellbio@gmail.com), Jes Ford (jesford@uw.edu) day 1 pm Python: instructors: Jes Ford (jesford@uw.edu) helpers: Jimmy O'Donnell (jodonnellbio@gmail.com), Jason Portenoy (jporteno@uw.edu), Emilia Gan (efgan@uw.edu) day 2 am Git and Github: instructors: Dave Beck (dacb@uw.edu) helpers: Jeff Arnold (jrnold@uw.edu), Jason Portenoy (jporteno@uw.edu) day 2 pm Python: instructors: Adam Richie-Halford (richford@uw.edu) helpers: Sean Patrick Santos (spsantos@uw.edu), Ariel Rokem (arokem@gmail.com), Jason Portenoy (jporteno@uw.edu) R workshop day 1 am the Unix shell: instructors: Rahul Biswas (rbiswas4@gmail.com) helpers: Qian Sophia Zhang , Sam White (samuel.j.white@gmail.com) day 1 pm R: instructors: Allison Smith (kasm@uw.edu) helpers: Ben Weinstein (benjamin.weinstein@stonybrook.edu), Sam White (samuel.j.white@gmail.com) day 2 am Git and GitHub: instructors: Ben Weinstein (benjamin.weinstein@stonybrook.edu) helpers: Qian Sophia Zhang , Sam White (samuel.j.white@gmail.com) day 2 pm R: instructors: Valentina Staneva (vms16@uw.edu, flexible to switch to something else if anybody prefers this lesson) helpers: Sam White (samuel.j.white@gmail.com), Jimmy O'Donnell (jodonnellbio@gmail.com) "on call" backup: Ariel Rokem (arokem@gmail.com), ########################################################### ########################################################### Planning for Fall 2015 October 22nd-23rd, 2015, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor Website: https://richford.github.io/2015-10-22-uw/ Workshop Repo: https://github.com/richford/2015-10-22-uw Python workshop day 1 am the Unix shell: instructors: Regina Carns (rcarns@uw.edu) helpers: Michael Gutteridge(mrg@fredhutch.org) Jes Ford (jesford@uw.edu) day 1 pm Python: instructors: Adam Richie-Halford (richford@uw.edu) Marina Oganyan (marina0@uw.edu) helpers: Ana Malagon* (amalagon@uw.edu) David Williams (cdave@uw.edu) Jes Ford (jesford@uw.edu) Jason Portenoy (jporteno@uw.edu) Eliah Overbey (eliah@uw.edu) day 2 am Python: instructors: Adam Richie-Halford (richford@uw.edu) helpers: Emilia Gan (efgan@uw.edu), Ana Malagon(amalagon@uw.edu) Jason Portenoy (jporteno@uw.edu) Eliah Overbey (eliah@uw.edu) day 2 pm Git and GitHub: instructors: Peter Schmiedekamp (pschmied@uw.edu) helpers: Sean Santos (SeanPatrickSantos@gmail.com) Jason Portenoy (jporteno@uw.edu) R workshop day 1 am the Unix shell: instructors: Thomas Sibley helpers: Allison Smith (kasm@uw.edu), Jimmy O'Donnell (jodonnellbio@gmail.com) day 1 pm R: instructors: Allison Smith helpers: Kara Woo (woo.kara@gmail.com), Jimmy O'Donnell (jodonnellbio@gmail.com), Thomas Sibley day 2 am R: instructors: Valentina Staneva helpers: Allison Smith, Jimmy O'Donnell (jodonnellbio@gmail.com), Kivan Polimis day 2 pm Git and GitHub: instructors: Ariel Rokem (arokem@gmail.com) helpers: Allison Smith, Jimmy O'Donnell (jodonnellbio@gmail.com), Kivan Polimis Adam can also teach git or shell in the python room if needed. *have to leave by 3. ########################################################### Planning for Summer 2015, maximum of two instructors per lesson 25-26 June 2015, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor http://suparee.github.io/2015-06-25-uw * Python workshop day 1 am the Unix shell: instructors: Sam White helpers: H. Kai Yang, Jason Portenoy day 1 pm Python: instructors: Ana Malagon helpers: H. Kai Yang, Jason Portenoy day 2 am Python: instructors:Ana Malagon helpers: Margaret Hughes, H. Kai Yang day 2 pm Git and GitHub: instructors: Ariel Rokem helpers: Margaret Hughes, Jason Portenoy * R workshop day 1 am the Unix shell: instructors: Thomas Sibley helpers: Allison Smith, Jimmy O'Donnell day 1 pm R (Lessons 1-3): instructors: Rachael Tatman helpers: Thomas Sibley, Allison Smith, Jimmy O'Donnell day 2 am R: instructors: Peter Schmiedeskamp helpers:Allison Smith day 2 pm Git and GitHub: instructors:Peter Schmiedeskamp (aux) helpers: Peter Schmiedeskamp: I'd love some experience with another module than github. I am of course happy to teach that too, but I don't want to be too presumptuous. If someone else wanted to teach Git/Github, I'd be especially happy to help out in the capacity of "the collaborator" during that portion. Thomas Sibley: I'm happy to help out with any parts of this. I've put my name down for teaching the Unix shell, and helping out with the R session afterwards on day 1. I might also show up to be a helper on day 2. ########################################################### Planning for Spring 2015, maximum of two instructors per lesson 9-10 April 2015, WRF Data Science Studio, Physics/Astronomy Tower 6th Floor http://efran.github.io/2015-04-09-UW/ * Python workshop day 1 am the Unix shell: instructors: Regina Carns, Jaci Saunders helpers: Ana Malagon, Adam Richie-Halford day 1 pm Python: instructors: Sophie Clayton and Andrew Gartland helpers: Regina Carns, Ana Malagon, Ravi Gandham day 2 am Git and GitHub: instructors: Rachael Tatman helpers: Thomas Sibley, Adam Richie-Halford day 2 pm SQL: instructors: Thomas Sibley, Trevor King helpers: * R workshop day 1 am the Unix shell: instructors: Ben Marwick and Emilia Gan helpers: Esther Le Grézause day 1 pm R: instructors: Esther Le Grézause and Marina Oganyan helpers: Ben Marwick Emilia Gan day 2 am Git and GitHub: instructors: Ben Marwick and Peter Schmiedeskamp helpers: Sam White day 2 pm SQL: instructors: Russell Alleen-Willems helpers: Ben Marwick Sophie Clayton Tiffany Timbers Rachel Tatman Peter Schmiedeskamp (as folks need!) -- preference for spring sessions would be to teach something new in order to get experience with all the modules. Thomas Sibley — Happy to teach any parts of this as needed; taught SQL last time, would do it again. I'll teach any part of the SQL lesson (in the Python room since R is spoken for). I taught the final parts of the SQL lesson in January and would teach those again. I can be a helper for the first part of that day (and maybe the first day?). Marina Oganyan Python or can also do R if needed. Maria Mckinley (availability for workshop itself depends on exact dates) Russell Alleen-Willems - Taught first half of the SQL lessons. Happy to teach both halves again in Spring, with a preference for doing the R class (so I can sit in and learn R!) ########################################################### Planning for Winter 2015, confirmed in bold Two parallel, concurrent workshops. One targeted at researchers in the natural and physical sciences (Python) and one targeted at researchers in the social sciences and humanities (R). The only difference would be the programming language and the background of the instructors and helpers. Of course these would just be a guide to participants, there'd be nothing stopping a physicist from taking the R workshop. Webpage: http://sophieclayton.github.io/2015-01-15-uw/ Dates: Thurs-Fri 15-16 Jan 2015 Venue: eScience Lead Instructor: Jens von der Linden (jensv@u.washington.edu have taught at 3 workshops Here to help. Feel free to email me.) Helpers & Instructors: > * Python workshop > > day 1 am the Unix shell: Maria Mckinley (1-3), Jaci Saunders, Earle Wilson, > day 1 pm Python: Andrew Gartland, Emilia Gan, Marina Oganyan, Ana Malagon > day 2 am Git and GitHub: Sam White, Ana Malagon > day 2 pm SQL: Jens von der Linden, , Dominik Moritz, Russell Alleen-Willems > > * R workshop > > day 1 am the Unix shell: Ben Marwick (1-3), Rachael Tatman (4-5), Tiffany A. Timbers( > day 1 pm R: (Esther Le Grezause), Tracy Fuentes, Chungho Kim, Tania Melo > day 2 pm Git and GitHub: Peter Schmiedeskamp (3-4), Tiffany A. Timbers (1-2) Ben Marwick > day 2 pm SQL: Andrew Whitaker,, Becca Blakewood, Thomas Sibley ########################################################### Welcome to public text pad for the Software Carpentry Instructor Workshop at UW (12-14 Nov 2014) Details and schedule of the workshop are here: http://sophieclayton.github.io/2015-01-15-uw/ Twitter: #swct3uw @swcarpentry @datacarpentry UW Software Carpentry email list http://lists.software-carpentry.org/mailman/listinfo/seattle_lists.software-carpentry.org UW reproducible research group: http://uwescience.github.io/reproducible/ & http://escience.washington.edu/reproducible NOTES: Day One 9:05 am Greg Wilson: Introducing SWC leaders; describing sticky note system as status indicators, enables discrete requests for help - Yellow sticky indicates ready - Pink sticky indicates need help Indicates existence of tons of educational research that's worth referring to, the book 'How learning works' (HLW) is a good summary of primary literature Outline of schedule - Bill: communication - Live practice teaching, video each other, coach each other Lunch - Getting feedback in realtime in the classroom In general, simple version, general rules, ignoring a lot of detail "Never hesitate to sacrifice truth for clarity" Frequent interruptions welcome, more noise = more learning One of the things to be successful is to break down the inequality in the classroom 9:20 am Bill Mills: Theory and practice of SWC workshops. What is SWC trying to do? Teach git, bash, sql, python/r But not overly concerned about the details and mechanics of tools It's not about the mechanics, it's about the underlying ideas, ie. structured data, automation, reproducible, version control, reuse and collaboration These are the fundamental values of SWC. Also build fluency for use without disruption to normal practice. Want bootcamp participants to get value from 3 day * How to get value out of ideas straight away? how to introduce them systematically? * Introduce connections between ideas - a graph, easy to visualise. For example, scripts, bash, commands, variables, file system - all linked ideas, related by, for example, composition, context, use. * Important number for teaching and learning: 7+/- 2 a decent estimate for size of short term memory; the number of items we can keep track of at once. Where our lessons first land in the minds of our students. * How to take information from short term memory to long term memory? Use association, connections between ideas to reinforce pathway from short term to long term memory. Want to make sure these connections are useful and correct in the minds of our students. Tool for reinforcing memory, guide for .... * Exercise: draw concept map (see HLW book appendix B) then draw on the board * First map is often not good, subsequent drafts often better. Concept map is non-linear, which can be more useful than linear links. Maps often nest concepts. Good way to check if relationships are going to make sense to students.Having non-linear structure means you're not committed to order while exploring relationships. Helpful to identify the core ideas - those that have the most connections. Idea of short term memory limited to 7+/-2 facts has a problem of 'what is a fact', making the connections and patterns can shrink many facts down into chunks. * Can help assess student understanding of topic Greg takes a measure of skill in the room using sticky notes: have written bash loop? Have written javascript? Point being we have to find out at the start where are students are at with skills. How to make the teaching more responsive to varied skill levels? * Back to memory chunking... Dr Seuss uses 'whole language' instead, get readers to recognize patterns. Chunking information helps reinforce ideas. Crucial to break up lesson, help students take things from short term to long term memory - making relationships is good. Do exercises to help reinforce relationships, talk in chunks, not continuously. Greg refers to MOOCS, why are they not effective? 'bad teaching at the speed of light' They only repeat the same explanation over and over. Lectures in large halls are just as bad, can't easily switch gears and try alternate explanations to help students. Great to explain things in 3-4 different ways. More expensive, but more effective. * Back to Bill, bubbles reinforce patterns, exercises reinforce connections * Write code live, lots of benefits to students * live coding will limit amount of code presented, better match to short term memory of students * forces instructor to slow down when live coding, gives students a chance for critical thinking * learners get to see process, see how instructor thinks * most important: let students see us make mistakes (can be deliberate!), struggle, (helpful to see how you troubleshoot something), gives students permission to do it wrong, reduce barriers between student and instructor. * Back to concept maps. Use structure to lay out lessons, makes relationships explicit, easy to operationalise. Get students to draw concept maps to inspect their knowledge gained from the lesson. Or get students to add more to your concept maps to find out what you've missed. Do the concept map quickly, roughly, to make it easy to get honest feedback on less polished work. * Technique comes from user interface design (particularly Jeff Johnson) - feedback on "back of the napkin" sketches is more useful and more honest than feedback on something done beautifully Exercise: take concept map previously drawn, come up with an exercise to illustrate, connections between nodes on graph, then combine with another person who did a concept map on a similar topic. Example: git lesson 'pull-add-commit-push' mantra * From drawing concept maps, we imagine the process of learning - getting ideas and making connections between them. Three key waypoints in the navigation of a concept map: novice-competence-master * Novice: knowing nothing about a topic, only solve problems by rote, a recipe-follower, don't know what they don't know * Competent: have key ideas of concept map and most important connections, can solve familiar problems in normal, common circumstances, eg. cooking, driving, for most people. * Master: same key ideas as competent, but have far more relationships between ideas. They can solve unfamiliar problems in novel circumstances, can skip past missing steps * Most important thing for SWC, get students from Novice to Competent. Students make connections by themselves, have to be careful to prepare them with an operational model into which they can put new information in, increase the value of future practice by giving a basic functional model in SWC workshops. Novices need a lot of attention to build sensible models. Have to stop regularly, give exercises and assessments to make sure students are making the right connections. A master may struggle to teach a concept because of the high density of connections that seem obvious. Competent practitioners are more familiar with the novices' way of learning, make computing routine to serve the domain science. * 10,000 h on a task for mastery? No, it's having more connections, more strategies for solving new problems. But need a review or assessment process to check if new ideas actually work. Getting feedback from peers is critical * Feedback needs to be very specific and concrete * (1) break it up into little chunks. makes it easy to digest * (2) has to be very specific, give something actionable, so they know what they have to do to fix it, makes it easier to receive feedback. * (3) has to be polite and respectful, person receiving is vulnerable, have to be gentle, not rude * 'Just' is the passive dismissive adjective - SWC instructors are punished for using it! "Just do this, that and the other thing" <- not helpful to hear for the novice Story from Greg, teaching at Naval Academy, sudden burst of push-ups, students there learning about human performance, 45-90 mins (closer to 45) is hard physical limit for attention to learning, relating to brain chemistry, caffeine doesn't help, getting more oxygen into the brain does help, yoga fine also. * How to get competence for fluent practice? * How to build motivation? * Greg: Be mindful of strategies for keeping some participants from speaking vastly more than others. One exercise is to use three sticky notes: each time someone talks, they place a sticky in front of them. Once all three stickies are used, the person must be silent until everyone spends at least one, at which point everyone gets all three stickies back. 11:00 Warren Code Warren's been sitting in the back observing, apparently There should be several people in the room as the instructional team, one talking and others observing "Classroom Observation Protocol for Undergraduate Stem"/"COPUS" Observations of what's going on at two-minute intervals, in a relatively objective format obviously it's easier for an observer to do this than for the instructor to try and do it at the same time as they're teaching Diagram of the room allows you to track contributions from individuals, to see who's engaging and who's not The next exercise is to do and observe teaching - What is the instructor doing? - What are the students/participants doing? How often do they get a chance to think about an idea? - Did the instructor give opportunities for people to practice what they're being taught? - Are people getting chances to engage and share ideas? Classroom observation protocol for undergrad STEM for logging activity during lessons, very detailed tool for monitoring teaching and learning. We'll get a PDF by email, and see the protocol website: http://cwsei.ubc.ca/resources/COPUS.htm (Q: why is there no code for "students are on their smartphones"?) Good question! There is a column set to track student engagement, which has not as standard a protocol as use requires some interpretation; if your teaching group is interested, they would agree on some use of that space, like write # of students disengaged. A separate protocol for engagement currently being used in a digital distractions study: http://cwsei.ubc.ca/resources/Engagement.htm Basically, observe a subset of students, about 10, for signs of disengagement and track over time. This is why it's useful to have two instructors --observer + instructor 11:15 Bill Mills Before the break, we went over the usefulness of concept maps for systematizing and understanding, as well as for formulating lesson plans Next exercise: 1. Draw another version of your concept map for the purpose of teaching novices 2. Come up with a three-minute lesson that conveys this concept map 3. Put up your yellow sticky-note, find two other people who are done, form a team 4. Take turns as instructor, student, and cameraperson GO! Greg: Why is it so awful to watch yourself on video? It's very different from your mental model of yourself "from the inside" When you're onstage your time sense changes, so you will tend to speak and move faster than usual; this is due to adrenaline/stress Yet another use for a second instructor: to slow you down when you're speaking too fast Bill: reviewing self on video, find gaps in self-perception. Sense of time skewed when performing/teaching. Who can teach their partners' lessons? Feedback from others: "didn't explain why we want to do something", many people looking at camera rather than watching for cues from students. better to keep an eye on students Try to interact with your students to evaluate their engagement Feedback (Warren organising these into 3 categories: Presentation/Content/Activities): * "Need to engage more with audience" * "Forgot to include important points/skipped steps" * "Looked nervous" * "Didn't assess skill level to start" * "Needed to project confidence" * "Connect to practical problems" * "Tie together the lesson" * "Describe benefits" * "Have a visual component" * "Relating to existing knowledge" * "Pace" * "Time management" * "Real-life examples" * "Have the right props" * "Give enough time for thinking'tasks" Presentation * Look at students * Engage with students * Project confidence/don't look nervous * Handle student's answers to questions appropriately * Pace/time awareness * Have appropriate props * Use visuals Content * Motivate your content--say "why" as well as "what" * Include practical examples * Clarity is more important than correctness Activities *Assess skill level of students (and use it to drive instructional choices) *Get students to do things Greg: Have a checklist based on Presentation-Content-Activities to actively check that you're doing everything you need to do in this list, and organise feedback. Similar taxonomy: PCK = pedagogical, content, knowledge. General theory of teaching, on one hand, then on the other hand, domain knowledge on specific theories of education on domains. Now looking the bottom of the etherpad, checklist has some important properties: 1. Sets expectations for learners 2. ?? 3. Changes power balance, makes it Ok to give feedback on checklist, makes feedback more efficient Bill: when co-teaching, get out of the way when the other instructor has the floor, don't interrupt. Stay out of the line of sight for students. Don't steal the punchlines from your colleagues. Use a mechanism to regulate turn-taking. Before lunch exercise: take a sticky note, write one thing you learned, and one thing you didn't get, one think you're still confused about, a question that wasn't answered. This is the paper on student evaluations: http://www.stat.berkeley.edu/~stark/Preprints/evaluations14.pdf Lunch 12:30-1pm Greg: Introductions, normally we'd do it first, but go into the flow of teaching. let's do it now since it's a convenient time. Q: about iron, ice, water spilling.... use sticky notes to indicate answer... when ice melts, what happens (a) stays same, (b) goes down (c) spills Correct answer:(b) goes down Exercise: try to convince your classmates to agree with you about the correct answer for the iron/ice/water question. This is an example of "Peer Instruction"--a more effective way to teach than traditional lecturing. "When people understand something, they all understand the same way; but when they misunderstand they all misunderstand differently" Peer instruction scales to 1000s of people and have been widely validated (cf http://www.sciencemag.org/content/323/5910/122.full & http://advan.physiology.org/content/ajpadvan/29/2/107.full.pdf) . A provably more effective technique: People can't just tune out; they engage with each other and become active learners Critically dependent on having a good question Example of addition problem (19+27 = 36/316/46/37), wrong answers allow diagnosis of incorrect methods, insights into what you need to explain. Let's you know what you need to fix. Ensure wrong answers a useful for instruction. Three different types of assessment (did you succeed at teaching?) * Formative: to guide learning process * Summative: final exam, are you ready to move on? bad reputation - teaching to test. But ok if students have had time to practice * Punitive: to punish, not effective teaching technique Formative feedback is common in sports, music, many other areas of our culture; but academics is still stuck with summative/punitive feedback Good teaching cycle might look like this: * instructor up front, talking, demonstrating, then * after 5-10 mins, need to check in with students "did you get it?" * maybe MCQ (multiple choice question), quick problem Exercise: think of something from your field that you could teach in 5 mins, then think of simple MCQ at end of 5 mins, have about 4-5 possible answers, plausible distractors, wrong answers need to have diagnostic powers, they should reveal mistaken thinking. Then think-pair-share to discuss exercise with peer, give questions and explain how each MCQ answer is useful. "Amateurs talk strategy, professionals talk logistics". Review of a few questions from the exercise to explore the diagnostic powers of plausible distractors. "Physics disease" where people who know something about physics and feel like they know about everything. Anecdote about Richard Dawkins "Why are testicles on the outside?" Dawkins has no sense of humour. Designing good MCQs is hard, one technique is to ask an open-ended questions one year, then collect the answers and in the following year, and use the wrong answers in MCQs. This is a lot easier if the questions don't count toward grades; if they do, students are apt to just Google them We collaborate on software, but not on lessons. Why? We should give back shared teaching materials for others to re-use. RID: Reverse Instructional Design. A good systematic way to design lessons (though not the only way). Normally we teach classes like so * type what we know into powerpoint... * make up some questions from slides for exams... This is the wrong way, the right way is * Figure out what you want the learners to know by the end of the course, write the final exam first * Work back from final exam to identify formative assessments to give practice for final exam * This is called 'test driven design' in software programming, to have an unambiguous requirement for the end of the job Exercise: Return to MCQ exercise, determine what we need to teach so that a student could answer the question successfully. Draw a concept map. Doesn't matter how you get the lesson built, it only matters that it looks like you followed a rational process. The apparent rational process gives it a narrative arc that makes it easier to understand and process, both for others and for yourself-in-the-future. Serves an archival purpose. Exercise: 2 minutes to walk through lesson to get answer from MCQ. Video the lesson. Take notes as you're being taught. Difference between first lesson and second lesson? Fatigue. Never design lessons assuming peak performance. Always assume you'll need some slack, that something will go wrong. If you have 60 min of teaching time, plan for 45 mins of actual teaching activity. Was it easier to give feedback the second time round? Coffee break, then Tracy will teach lesson, 2-3 people give feedback, then Greg to give feedback on feedback. cf. Music masterclass, where people get to see how an expert gives good feedback. Tracy doing live-coding lesson demo, moving around the file system. Five minute presentations are very hard, have to be extremely organised. She is timed. Talking about the shell, Tracy's favorite topic. Shell is empowering - takes away limitation of programs, not limited by someone elses' tool. Survey: how many have used the shell? Use it often? Have programs that can only be used from the shell? In scientific programming, shell use is common because GUI is overhead. Main thing that goes wrong, what are the common error messages? File is not where you think it is, or you're not where you think you are. Unix file structure is the big concept here. Schematic to show folder tree structure... Practice ls and cd commands to navigate terminal. Time is up! Greg calls for feedback from the audience: one +ve piece of feedback and one -ve piece of feedback from cold-calling people. Why alternate +ve and -ve? To be polite and respectful. Why prevent repeat observations? To overcome polite urges and get to the real and less comfortable items of feedback. If you allow repeats, people will tend to repeat safe things, prohibit repeats to get to the tougher items. Greg's comments: good to show motivation, good to seek feedback, explore different levels of familiarity, can start with multiple choice question, even, then skip over if all students get the right answer. Not making a lot of eye contact with audience. Move bottom of window to middle of screen so people at the back of the room can see the coding clearly. Use a helper to copy code into Etherpad because view of history of very limited on screen. Don't ask people to self-evaluate their own knowledge, because people are terrible at that (cf. https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect); ask them a more objective question, e.g. "Do you use the shell regularly?" Q: What do you do when you ask about audience knowledge and just a few people don't know something? A: Depends on whether it's foundation knowledge that will be required to understand the next lesson. If you have closer to a half and half know/don't know, you can pair people up to teach each other. 'Necessary loses' if you help 90% of learners, you've got 10% who didn't get it. Can't waste time on the 10% that will bore the 90%. Never going to be able to help everyone, just have to accept that. You can still make sure that that left-behind 10% aren't *actively demoralized* by your teaching, though. That's still a win. People may give feedback via written forms that they wouldn't give in person or in class, it can help to structure that feedback to prevent trolling and abusive comments. You could also have people vote on specific items you want to know about Single strongest predictor of whether someone learns something? Motivation, two types: extrinsic and intrinsic. SWC is lucky, deals with free-range learners who want to learn. SWC's problem is dealing with demotivation, ie. being treated without respect, too much jargon, not knowing the final goal, repeated failure, unfairness, indifference from instructor, technical problems. Greg's story about his physics test, teacher took two marks of his test because another student did extra work, and the teacher docked the students who didn't do the extra, required work. Greg left physics at this time because he felt it was rigged, that the instructor was unfair. Another story, about student about a female grad student who dropped out because no-one spoke up about bad behaviour from other students. Severe demotivation. Homework: * Write a caricature of you typical student (write it into the etherpad), what do they know already? what are their goals? have they done programming before? We need to know the typical learner who comes into our room. We need to make up a little cartoon story about our learners so we can ask ourselves 'what would our student do?' Bill, Jane, etc. * Think about a demotivational experience you have had and might be willing to discuss 4 pm Wrapping up Day 1 Quick survey of everyone in the room: one-good-comment & one-bad-comment to get a list of feedback, Greg and Bill write it down on the whiteboard. End of Day One Day Two 9 am Greg Outline of the day, refers to book "Building a better teacher" (http://software-carpentry.org/blog/2014/09/building-better-teachers.html) advocates sharing practices between teachers, peer review. differs from western culture of punitive review of teachers 9:05 am Tracy Reflections on feedback from yesterday. Introductions in the middle of the day. Important considerations: * 1. How you meet each other * 2. How the instructor represents themself As an instructor we want to (1) appear competent and (2) appear approachable. To do this, we want to choose the information about ourself that we want to present to our audience. We need to represent ourself as a domain expert, and that varies by context, location. But, if you're in an unrepresented group, showing competence right away can lower the bias that you might face. For example, when introducing self at a Data Carpentry workshop, appear to the learner who works in biology, has recently sequenced plant genomes, but has no experience with genomics. Tracy introduces herself with biosciences and computational experience, show excitement for these fields. But if for a software carpentry workshop, focus on introduction is on software development, open source contributions, version control, how they've helped with productivity and efficiency. When introducing yourself, focus on authentic shared experiences with audience. This sets the tone for your relationship with your audience. Set up competence first, then share stories to lower barriers, show you're a human Exercise: break into groups of four. Possible ways to introduce yourself, who am I, what do I study, why a I here? Write a short bio for the etherpad in advance of the workshop * How do you introduce yourself, how to get people to introduce themselves in your class? * Say what workshop you plan to teach, give a few sentence introduction of yourself and get feedback from your group on (1) how qualified you appear (2) how Discussion on exercise... * Greg says one of the most important things for people to take away from the SWC workshop is a belief that they can do it, a sense of their potential * ask what have you changed your mind about in the last 10 years * instructor mentions relevant computing issues, ask audience to share theirs * ask people to share details of something they're proud to have made with their hands - software is also about making stuff (good to create positive atmosphere), also ask about research disasters (share vulnerabilities) * chose a bio from a hat, deliver that one * pick some candy, tell one thing about yourself for each piece of candy that you got * have prompts to get learners invested/motivating workshop * ask what is your spirit animal <- Bill warns against this because you need to... * Be aware of trivializing cultures/belief systems/etc Be sensitive and culturally neutral * what are you really excited about right now * introduce your partner to the class, gives everyone an immediate friend in the workshop * take care not to burden participants with too much work here * Need to be sensitive to people who are not comfortable to share details, consider stalking, privacy Engaging people from the start, and engaging people with each other leads to a more positive workshop experience. Gives people more hope for their potential coming out of the workshop. Exercise: Introduce yourself to your learner. focus on competence and accessibility. Discussion on exercise: * How valuable are these introductions, should we spend an hour learning about this? Very - crucial to set mood, break down power relations, make it easier for students to ask questions, gets people to feel comfortable to ask questions quicker in the schedule. Yes- gives a base for discussion of relevant issues surrounding instructor-student relationships. * Important to set tone - feedback from instructors indicates that sometime instructors create a distance between them and the learner, which is demotivating and demoralising, have to be deliberate to close the distance between the learner and the instructor * Important to be motivated and motivating, can't assume that people are they because they want to be, might have been force to by adviser, etc. * There are easy ways to spoil a workshop by doing nothing when introducing, that is a choice on our part. Anything you do will be the wrong thing for one person, you have to deal with that. * Disruptive people: not respectful, grumpy, want to show off... From the start if the instructor shows that they respect the learners, then that sets the tone and makes it less likely for other students to be disruptive 10:20 Break for coffee Greg: reviewing SWC workshops content, walk through http://software-carpentry.org/workshops/checklists/lead_instructor.html Think about failure modes, what could we prevent from going wrong? We give you [have you create] your own website (from https://github.com/swcarpentry/bc) so that you have complete control over the information It's on Github so that at least one person instructing knows how to use Github, and also so it's compatible with SWCarpentry's tools Meet with instructors in advance to discuss 'what have we learned recently' and distribute labor of workshop. Set up the Etherpad early so that you can put it on your website 75% of your learners, plus or minus, will actually have the software installed. Don't let installing take too long during the workshop, get a helper to do it, and pair students up while the helper is installing. Pre-workshop questionnaire uses objective tasks/questions to try to get an idea of learner expertise (they're working on this and want feedback) Code of conduct [http://software-carpentry.org/conduct.html] is taken seriously, people have been removed from workshops. Need to be sensitive to the audience, cf. Greg offending a librarian by suggesting they volunteer to instruct - job market is awful for libraries and they're always asked to volunteer in lieu of paid work, which annoys them. Helpers can mingle and address problems pre-emptively. If you have computer problems with one or two people, have everyone pair-program, then you need only half of the class to be capable. Failure modes: no wifi password, fire alarm goes off, your co-instructor is sick, there's a jerk student in the classroom, power outlets, audience doesn't want to engage. Greg's story about training KGB, not very reactive people Administrative support (http://software-carpentry.org/workshops/checklists/admin.html) can help you find instructors, help handle registration. Strongly recommended to charge a fee and donate it to charity, this helps ensure people actually attend. Hack for getting the university to pay for instructor travel: give a standard academic talk at the university where you're teaching, mix it with other career enhancing activities that can go on your CV. Reasons to teach a workshop: to instruct collaborators, Workshops can fulfill requirements for training/professional development Exercise: What would you accept as evidence that SWC workshops are useful/worthwhile? what would a scientist accept as proof? * Pre- and post- testing with a series of tasks * X% of learners report having improved in [metric] * Measure after workshop: Better tools, fewer errors, faster results * Incentivizing feedback: Pre-, post- and 6-month interviews of 1-3 students * Compare social network graph of collaborators on open/closed research papers; so graphs of open research pubs have more desirable characteristics * Get feedback from profs/supervisors * Are you still using the software X months later? * Sell version control/reproducibility Failure modes: * "I don't care if they can program, I care if they can do science" * "The tasks you're testing on are too narrow" * "Self-reporting is non-objective and not scientific" * "Qualitative/interview-based research isn't real science" * Astronomy departments have objected to Software Carpentry workshops because grad students who know how to program will leave for jobs that actually pay Honest instructions think about what they can take OUT of the curriculum, to be honest with the challenges they face. Lunch Greg: talking about peer review, code and data availability. Long term plan: make code and data availability normal What does winning look like? 18% of scientists taking Software Carpentry principles to heart Grad students are the way to get this stuff into the system--they have time to train on this stuff, and will eventually age up into the decision-making positions Tracy: We might see computation being better integrated into existing courses Bill: Meet your students where they are--know what tools they're currently using as well as what their technical expertise is. Think about the learners' emotions. We lose students when we fail to manage their emotional response. Bill's feedback on caricatures, want more detail on where to start learning. And where do we expect them to have gotten to. Ex: Nancy is already familiar with Matlab, so we might spend less time on some of the basics and more time on things that will help her in her goal of getting good at code review Greg reviewing SWC workshop content... Start with Unix shell, many key& fundamental skills of automation and reproducible research are presented in this lesson. Offer concrete skills, then smuggle in big idea. Show skill, then explain that they just learned a big idea, then show a second example to help students see a pattern. Introducing version control: http://www.phdcomics.com/comics/archive.php?comicid=1531 key points: history and collaboration. payoff merge changes logically and efficiently. Use VC as a lead in to open science, choices about licencing, intellectual property rules. At UW? "· All staff work product is owned by the UW. All intellectual property resulting from a faculty member’s appointment, with the exception of academic publications, is owned by UW; academic publications are owned by the individual who produces them" https://depts.washington.edu/amtas/research/BriefGuide.pdf More details: http://www.washington.edu/admin/rules/policies/PO/EO36.html By now students have the idea: break things up into * lots of * little, * reusable functions Good data habits, cf. https://twitter.com/search?q=%23otherpeoplesdata Data Carpentry lesson on using spreadsheet data: https://github.com/datacarpentry/datacarpentry/blob/master/lessons/excel/ecology_spreadsheets.md Greg's story: Drug resistant tuberculosis, long incubation period, high fatality rate. Is is spreading deferentially in poor and wealth populations. Data set 1: patient records with postal code only & blood and sputum tests - have TB Y/N Data set 2: have postal code & median income. Connect TB to income, no correlation, where is the mistake? Homeless people don't have a zip code! This means a large chunk of signal is missing from the data. Police staff do not have their information recorded by Canadian hospitals... People aged 16-21 don't have their addresses recorded also... That is a story to motivate learning about null values in data management. Wants more contributions to lessons on stories to motivate teaching. Can be mistakes, this helps the humanize. Exercise: Come up with a story of your own to motivate a lesson, does not have to be on the topic SWC teaches. Discussion about stories: [ongoing problem with projector, changing screen resolution before plugging in laptop to projector, seems to help] Coffee break until 3pm Greg to demonstrate lesson, us to complete review form... 5 minutes of open Q&A - started with mistake of lack of specificity, the initial question was too open ended, refinement, ask 'who has a good idea about how to run a workshop?' Warren: discussion feedback on Greg's lesson. Forms give some structure to feedback. Tomorrow have a 10 min mini-lesson that will be evaluated using the same form, video-taping groups of three, first thing in the morning. Choose something you've taught before so you can concentrate on the delivery. Greg: collecting feedback, alternating, go around the room and have people say one good thing, then one item to improve. Point of computing is not numbers but insight. And then free-form feedback, listed on whiteboard. Trying to model behavior to show your students. [would be nice to properly realistically do half a lesson to model the experience] End of Day Two Day Three 9 am Greg Outline of the day: 1. mini-lesson exercise 2. Tracy to talk about data carpentry 3. Contributing to lessons via github 9:05 am Warren introducing mini-lesson and review process, each person teachers then gets feedback immediately, then repeat, keep to 8-10 mins for lesson Do exercise then coffee break 10:20 am Warrren Discussion about exercise Deliberate practice: practice based on feedback, targeting specific areas of improvement Get a teaching buddy who will watch you and give you feedback & swap off Graduate students: get your adviser to give you feedback on (1) your teaching, (2) on your grant proposals, (2) on serving on university committees. John Cleese on 12 people you don't want in your meeting, this one www.youtube.com/watch?v=ZWYnVt-umSA ? 10:30 am Tracy on Data Carpentry. One benefit of SWC & DC is that the lesson material exists and generally fits the time frame. Objective: review lessons, then show how you can contribute to the lessons. DC emerged from limitations that people have in data management skills: http://datacarpentry.org/ talk about spreadsheets, R, SQL. Designed to be domain specific, people motivated by data that is real to them. Try to tailor to different needs of different research communities. Currently active on biology, genomics, starting on social sciences and humanities. Welcoming contributions! Lesson development is via github. Lessons are written in markdown, formatting is very light. Typical contribution if you're familiar with git: fork, clone, pull. Or, more easily: edit directly in the browser on github.com. Run-through of browser editing with everyone. Everyone has made an edit and submitted a pull request now Tracy can accept/merge all the requests (https://github.com/datacarpentry/datacarpentry/pulls) Another way to interact with lessons, aside from making pull requests (PR), is to create an 'issue' (https://github.com/datacarpentry/datacarpentry/issues) just to start a conversation without making a PR How big should a single pull request be? Smaller is often better; think of what changes you would want to apply in a single unit. Mozilla Firefox PR average length is six lines. PR mechanism also useful for scholarly writing in general. But do check with PIs and collaborators about how open you can be on a joint project before broadcasting everything on github. Bill: on teaching SWC at UW in near future - decide on what topic you want to teach, you'll just do one topic in a typical SWC workshop. Greg: on roadmaps, origins * What does done look like? Here's the list of aspirational goals: http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745 we should look through and see what makes sense for your field. * How did SWC start? http://f1000research.com/articles/3-62/v1 Things that don't work: week-long courses; only having one instructor; using professional programmers; * Keen to amalgamate collective wisdom on lessons, especially details of content and critically, timing. You can customise the lesson material to your needs, but you must get peer review before teaching the lesson in a SWC workshop. At minimum, from your fellow local instructors, ideally from others in the SWC community on github, submit an issue. On the bimodality of programming learners: http://retractionwatch.com/2014/07/18/the-camel-doesnt-have-two-humps-programming-aptitude-test-canned-for-overzealous-conclusion/ http://www.eis.mdx.ac.uk/staffpages/r_bornat/papers/camel_hump_retraction.pdf http://dl.acm.org/citation.cfm?id=1268845 When organising your workshop, get people to register in groups because (1) people come with built-in support (2) they're more likely to show up (3) people from underrrepresented groups are much more likely to turn up. Bill notes that demotivation and frustration are very common sources that slow students down in workshops, not so much actual technical problems. Lunch Greg introduces Mako Hill (makohill@uw.edu, UW Communication) and Tommy Guy (Microsoft) and they talk about their Community Data Science Workshops: https://openhatch.org/wiki/Community_Data_Science_Workshops_(Fall_2014) Good opportunity to test out helping/mentoring skills in a SWC-type workshop, this event is heavily influenced by SWC. Mentors at all levels welcome! Greg: asks 'what should we redesign'? for the whole workshop, does one-up-one-down written on the board. Bill Howe from UW eScience, giving background to eScience... key idea is people and expertise, not computers. Want to incentivise and reward activities relating to people building expertise, create value of this kind of training in the University. Different levels that eScience helps people: people already active with programming and then people at the bottom of the pyramid - with limited computing skills. Where to next? regular SWC workshops on campus, once per quarter, predictable time and place, eScience has a place for this, old physics astronomy library, now data science studio, good for running SWC workshops. eScience want to give admin support, want to know how to make it easier to run these workshops... improve recognition by Chairs, Deans, etc... couple SWC workshops to another program to encourage people to continue to develop their skills in the Data Science Incubator (http://data.washington.edu/incubator/). Get people talking across campuses (in the Moore-Sloan partnership), a chatroom, maybe. Have a SWC-UW chatroom. Farewell to Greg and Tracy Warren: collecting more feedback, freeform, on paper, recapping of workshop schedule: Day 1: participant introductions, assessments (type, write your own, 5 min lesson using your question), reverse instructional design, teaching sample (Tracy) and feedback, discussion (demotivators, imposter syndrome) Day 2: Workshop introduction strategies, SWC impact evaluation, learner caricatures, capstone sample with feedback Day 3: 10-min prepared lessons with feedback, lesson repository, github repository and pull requests, afternoon visitors, Final wrap-up. Bill: asking to work together, give feedback to SWC central, make pull requests. Mentions Instructor hangouts where people do a 5 min lesson and get feedback: http://forum.mozillascience.org/category/instructor-hangouts Topics we'd like to teach in the WI14 UW SWC workshop: Ben will follow up with Bill Howe to get a room, catering, publicity, etc. we're aiming for two days before the quarter starts: <-- Do you mean January 3/4, the weekend? Software Carpentry (your name, your topic): Sophie Clayton (sclayton@uw.edu), python, SQL or unix shell Emilia Gan -- efgan@uw.edu -- intro R or Python David Fazio - faziod@uw.edu -- Python Chungho Kim - charisut@uw.edu - R, Excel Peter Schmiedeskamp - git, shell, R/Python Tyler Fox - git, happy to be a helper for other workshops Becca Blakewood - most comfortable with R but I'm open to shell and db/SQL also. No python for me yet! Andrew Gartland - Python, git, sql, shell Jaci Saunders - jaclynk@uw.edu - Python or Shell Tracy Fuentes - R - tfuentes@uw.edu Steven Roberts - shell, git, probably more Maria Mckinley - data or software, shell, git or python Earle Wilson - Python or git Data Carpentry (your name, your topic): Tracy Fuentes - Data Workshop for Ecologists, R - tfuentes@uw.edu Andrew Gartland - Python, shell, excel, data, plotting? Peter Schmiedeskamp - R/*ggplot2*, Python/Bokeh? Chungho Kim - charisut@uw.edu - R, Excel Emilia Gan -- efgan@uw.edu -- intro R or Python , shell David Fazio - faziod@uw.edu -- intro R, Excel, possible Tableau using data from Excel. Becca Blakewood - most comfortable with Excel or R; possibly shell/scripting or SQL. Maria Mckinley - data or software, shell, git or python Steven Roberts - Data Workshop for Genomics End of Day 3 and end of the workshop! WRITE CODE LIVE! * Much better than showing up with code on slides * Size of a live coded example matches the scale of short term memory * forces you to slow down * shows that we all make mistakes * text books don't make mistakes: hard to teach debugging! Q: Why didn't we do introductions? Do you do them in a SC class typically? Why or why not? * We were hoping to delay those until more of the registrants showed up... We'll do it at the next break Q: How do you manage teaching SWC when the students have a wide range of skills in programming? - Use helpers to fill the gaps - Teach to the lowest denominator - Pair people up for peer instruction - Use a formative assessment - Necessary losses (if only ~10% are not familiar or falling behind) - Accept that you cannot help everyone, but don't demoralize * ideas and the connections between them - graph-like, so lends itself to visual representation * Hmm. It's hard to draw concept maps in ASCII notes. * Hmm, good point, we might also need to include a drawing link and someone with an iPad * people have cell phones, take a photo and upload. * 7 plus or minus 2: the size of short term memory * Making connections is the process of understanding: we want to give students a guide to creating connections so they don't do it wrong Exercise * Create a mind map/concept map on some topic from Software Carpentry * Time: about 10 minutes * Appendix B in How Learning Works talks about concept maps Rubric for Giving Feedback on Live Teaching * Presentation * Audience contact (facing them, eye contact, voice) * Clarity (can be heard) * Pace (not too fast, not too slow) * Modeling expert thinking? e.g. live coding * Visual component, how well do you use presentation tools? * Projecting confidence * Allow for silence - don't panic * Summarizing/reviewing information when in * Share the floor with your co-instructors * Content * Motivation * Practical examples * Assessment of learners: Find the right starting point (not telling them things they already know, but telling them things thp ey don't) * Language (not using jargon, not using terms that haven't been defined) * Narrative (a clear story arc without digressions) * * What are learners doing? * Does the instructor find out what they already know? * Does the instructor check in on how well the workshop material is sinking in, i.e., opportunities to practice the skills/content observed by instructor team, and regular use of sticky notes to catch confusion? * Are people drifiting off to other work/social media/etc, though this won't really be applicable in mini-lessons but will apply in larger group settings. * Are the learners active or quiet? * Give people time to complete the tasks you give them Pay attention to inherently unequal power dynamic between teacher and student. Every wrong answer should be a useful diagnostic for the instructor Design the questions such that you know what student understands or misunderstands Plausible wrong answers with diagnostic H Did you succeed at teaching? Formative assessment - what we do while the student is learning Summative assessment - at the end - are we done yet/ready to move on ie final exam Punitive assessment - punishing students - create fear and hinder learning What does a good teaching cycle look like? Do something for 10 minutes: talk, demonstrate Check in - did the idea get across? Need a quick formative assessment If every one gets right anwer, we move on. If everyone gets same wrong answer, know that specific problem everyone has. 10-15% of SAT questions are not being counted toward your score; they are simply being tested open source teaching materials! When creating a class? Figure out what you want your students to know. What is the summative assessment? Write class final exam first. What are the formative assessments that I am going to give you along the way? Work back from summative, formative assessments to create practice. Design lessons coherently, rather than haphazardly. Reverse Instructional Design, also called "Backward Design" or "Integrated Design" by some: determine assessment and goals prior to choosing activities and explanations. This is the reverse of teaching a bunch of content and then figuring out a test for it. A helpful resource for working through the various things, from an approach of designing a whole course but including lots of helpful questions and worksheets for smaller-scale lessons as well, is a guide by Dee Fink, available at: http://www.deefinkandassociates.com/GuidetoCourseDesignAug05.pdf "The fact that I can't even get started is a powerful de-motivator." Lost several students who couldn't get the software loaded and working 2 factors that strongly demotivate learners Unfairness Indifference Good * working with others * homework for tomorrow * the "three stickers" trick for managing meetings * Etherpad * using cellphones to record video * deferring introductions until after people had already met * telling us fatigue is normal * instructors are engaging * instructors are efficient * good examples of how to give feedback * good snacks * stories and anecdotes * systematic feedback Bad * tired at the end * still don't really know what Software Carpentry is * unclear instructions for exercises * would have liked prior warning on lesson development * sounds like training is aimed at people teaching engineers * too much talking in the afternoon * instructors could have done better prep * ran over time * need more breaks * need more push-ups * not everyone was here all the time * need more power strips * more instructions for the 3-person videos * close the shades earlier in the day * too rushed to think of topics for the teaching exercise * call out Appendix B (concept maps) earlier * better spaces for teaching practice * need summaries of what was said/taught =============== Day One Homework ========================== Who is your typical learner? Create a paragraph describing a "stereotypical user" in your course. Be as specific as possible. Character bio: What do they know? Skills gaps? What challenges will they have? Nancy's Caricature Nancy is joining a new project where she is encouraged to learn Python. She has experience in data analysis and visualization in matlab, a proprietary software package commonly used in her field. In her previous position, she worked mostly independently but she is now part of a small team and must often share her analysis tools and figure scripts. She also needs to review code that her teammates have written. She has a basic familiarity with the bash shell but would love to learn more about how to automate her work. Karina: My typical learner is an incoming graduate student named Maria. English is not her first language, she is in a new country and she has lots of course work. She needs to speed up on learning a specific software used in her lab (she will be debugging codes). She has taken an introductory course, mainly programming numerical algorithms to solve PDEs but none of the tools taught in the SWC bootcamp. Nikki's learner: Paul is an MD/PhD who grew up in Kenya, and went to the University of Michigan. He has just gone back to Kenya to do research on HIV/AIDS and work in a clinic, and knows computers help other people do things faster. Starting at basic level, what is a file structure, how do you navigate it. Incorporate visual feedback and relevant tasks. Basic shell commands. After paths and general navigation, introduce version control and with simple text files. Once understands version control, start introducing basic programming concepts, variables, conditionals, loops, etc. Basic data analysis. Rachael: Andrea is a first-year linguistics PhD student. She's had a good deal of training in formal logic and data structures in the guise of linguistics classes (though she wouldn't use either of those names). She also has a large amount of raw linguistic data from her fieldwork on Central Pomo saved to an external hard drive but hasn't dealt with it yet because dreads organizing it all. Becca: Cindy is a graduate student in the Library and Information Science program who is interested in how people interact with technology. She has not had any experience with statistics or programming, and may be challenged by some of the new concepts (but is a fast learner). She is capable in Excel, though she has not created any advanced formulas. She has some limited experience editing html and css. - Identify a goal she'd like to accomplish with her data (i.e. visualize data) - Introduce her to using a programming language that can handle statistical analysis and data visualization by using a subset of Cindy's data - Demonstrate similarities between the language and Excel (that which she's familiar with) - Highlight aspects where the language succeeds, but Excel falls short (to show why learning the language will benefit her) - Show her how to start the Jaci: Alex is a new STEM graduate student. Her first project in the lab is to analyze a massive dataset and glean some findings from it. She doesn't know where to start, but has some hunches. Alex is proficient at using gui interfaces on the computer, but has found her dataset too large to manage in a gio framework. She needs to parse out appropriate subsets of data and focus more intently on those few key findings. Alex is hoping that becoming more proficient in a command line interface will enable her to use tools to glean the information she needs from the monstrous pile of data. Sam: Robbie is a first year M.S. student in Biology. He has a solid background in biology and corresponding lab work, as he has worked for a few years as a lab technician prior to attending graduate school. He has a basic understanding of using Microsoft Word and Excel, but has virtually no other computer skills applicable to his research project, including no experience with any operating system other than Windows.Robbie will need to use command line tools in a Unix environment (using the shell) for file manipulation/conversion. Additionally, he'll need to learn a language (either Python or R) that will allow him to perform statistical analysis and data visualization for large datasets that Excel cannot handle. Where is Robbie: Minimal Background experience in computation- Goal: Stats and Visualization (R or Python) Approach: Would want to build on Excel experience and seems would need to first convince of value. Wonderful opportunities beyond the course but first need to get data in universal format, explaining how while Excel has value, the data size is to big. First step and skill set will get comfortable doing something in command line. Realistically might not get too much into Python / R. Provide a large file tab-delimited file, let the try to tell me something about it, open in Excel. Show them how to use command-line: start with pwd, ls, full path to file... Then head command, wc, cat,.... Maybe move to IPython - another benefit, fix mistakes in commands (cut paste) - then matplot lib code figure Steven: Frank is a first year graduate student with experience in ecology / field work. Has fundamental understanding of molecular biology (genes and proteins) and has interest in using genomic data to inform understanding of environmental impacts on species and communities. Expert skills in Microsoft Excel and used R sparingly mainly just copying and pasting code, not knowing what it does. Frank is vaguely aware that there might be public data available, but does not know how to tackle it. Further, when writing collaborative research reports this Word, track changes, and email is the gold standard. Frank: awareness of data but lacks data competencies (assessing the data source, cleaning, ensuring consistency/accuracy, manipulation, analysis). Expert in Excel can mean a lot of things, need to probe that. Need to address what may be lack of curiosity with R - has Frank attempted to understand and failed, or never tried to understand what's being copy/pasted? To teach: Find out what might motivate Frank to start using R. Ask what kinds of things Frank has accomplished (or does regularly) in Excel; try to recreate one or more of those tasks using R. Discuss examples of structuring and manipulating data in Excel compared to R - alternate how they are alike and how they are different (starting from concept maps might help). Walk through an example of some R code he's used but not understood. Continue to appeal to Frank's motivation and summarize how tasks/practice support his goals. Advanced: Ask Frank to map his analysis and reporting workflows. Provide an overview of reproducible research and show a combination of tools that can replace the MS Office workflow. Maria: Suzie is a 2nd year grad student in Geology. She has learned some Matlab along the way, even taking a class on it. The class was a data analysis course, and was more focussed on the math and making that into code than about how to code, however. So far she has gotten by by making copies of files when she wants to make major changes, but she is beginning to see that this is not really sustainable. She knows her code isn't great, but not sure how to improve it, and it doesn't really look much different from her colleague's code. She can more or less find her way around the file system from the command line, but can't do anything more complicated than that, and sometimes still gets confused about paths. She has heard of object oriented programming, but has no idea what that is. Suzie could really benefit from learning about GitHub or another form of version control! Also some more general “best practices” for programming tips. If everyone’s at her level, peer exercises would probably work well to help students fill in the gaps in each others’ knowledge. It also seems that quick reviews of really basic things (like the file structure) might help give her a really strong foundation. Ben: Li is an incoming graduate student in archaeology with some basic stats and data handling experience using Excel. She uses MS Word and IE and struggles with viruses on her Windows computer. She has never used the command line and is not familiar with any programming language or even that Excel has functions to operate on ranges of cells. English is not her first language and she is not familiar with how to get help beyond her classmates and instructor. She wants to collect and analyse data for her dissertation, and wants to do scientific archaeology and is ready to learn to code, but is not yet aware of the many traps and tricks of using R, which her adviser is requiring her to get to know. David: Darwin is a upcoming candidate for the MSIM (Master of Science Information Management) program. He is a disabled Veteran and is new to programming language. Darwin is mostly self taught and his previous experience includes MS Office 2010 suite, LDAP/Portal roles, Web/Tier authentication, SQL, Oracle, SAP, Supply Chain Guru, and hands on experience with Tableau. Darwin is excited to learn code and looking forward to opening opportunities through this experience to the overlooked in society; individuals with disabilities, minorities, women, homeless veterans, and people that the system has failed. Chungho: Xiao is a first-year MUP (Master of Urban Planning) student. He came from Shanghai, China. As of now, he is familiar with MS Word and Excel. However, he is not used to planning methods which cover data tools such as R, GIS, and so on. This is because his undergraduate major was environmental science. In addition, he has hard time in quickly understanding materials in English. Nevertheless, he has strong enthusiasm to catch up new data tools and knowledge about American planning. Starting Points: 1) Unfamiliar with standard planning data types and US data sources 2) Excel User - level undefined; Programming Novice 3) Needs written materials to help with language barrier Learning goals: 1) Find and download a typical planning dataset 2) Load, plot, and evaluate dataset using R; 3) Best practices for data management and workflow 4) Automation of repetitive tasks 5) Document what you did in scripts in a reliable, transparent, repeatable way Sophie: Beth is a second year grad student in geophysics working with numerical models. She was thrown in at the deep end at the beginning of her project, and just given other people's FORTRAN and Matlab code to work with. She had no previous programming experience. She's at the stage now where she has taught herself basic shell commands, and how to do very specific things, but has no idea about version control, and automating tasks in the shell. She's keen to learn more, but doesn't know what she needs to know in order to be more productive. -Since the student has gained some familiarity with shell commands, I might use that as the starting point and demonstrate a very basic shell script that automates a very simple task (i.e. modifying all the names of files in a directory). -then, since she really needs to learn programmingconcepts to understand the code she has to work with, try to make connection that this script (a collections of commands stored in a file) is very similar to a Python function -- to demonstrate that learning a programming language is not such a huge step up from what she has already done in learning shell commands. -finally, git could be introduced to show that the old FORTRAN and Matlab code could be worked on using version control, so that she can change the code without worrying that she won't be able to "backtrack" if her changes don't "work" Emilia: Learner Name: Laura, Age: 25 Biology grad student, worked as a lab tech before applying to grad school. Great lab skills, finding her research straightforward to conduct as far as knowing the methods she needs to use and how to troubleshoot them. Not yet doing a lot of data analysis (more data gathering stage still). Doesn't see the point of learning how to program, as there are GUI point and click programs that she's been using, or her group sends their analysis out. Not particularly fond of math. Only uses computers of internet and word processing. Not even especially fond of Excel. starting point: complete novice, need to do a good job of persuading her that computing tools can be useful for her. potential progress: load data into python/R, make a graph, or do some kind of operation over the whole dataset without corrupting original data. repeat an operation with more than one dataset (e.g. write a simple script and run it on different data files). Regina's learner: Chris is a first- or second-year graduate student in vulcanology. He has taken an introductory computing course in undergrad, but he's mostly self-taught in Matlab and Unix. He doesn't know how to use version control and usually doesn't comment his code. He'd like to know how to make code that's more efficient, reusable and redistributable. starting point: I think that he knows the basic concepts for programming. However, it is expected that his ability is not honed enough to share it with other peers. So, he is required to have experience in terms of communication, sharing materials, and so on. potential progress: He can experience co-work with others by communicating and sharing materials which he or others produce. In addition, he can learn skills about version control and code explanation. I expect that he would learn different approach to make code more efficient, reusalbe, and redistributable by engaging other learners and instructors. Tracy F: Lucia is a first generation college student. She's in her 3rd year of her undergrad in environmental science. She has had an intro stat class that used SPSS and several lab classes that required data entry and calculations in Excel. She has no programming experience and doesn't see the point. Peter S: Rolando is a first year masters of urban planning student. He is an avid bicyclist, which was his motivation for studying urban planning. He hasn't taken a statistics course since he left his undergraduate program in comparative literature 10 years ago. Nevertheless, he has questions--questions that he will probably answer with R. He has no other technical computing experience. Reasonable goal in two days: Learn what scripting is / why useful, load data, basic descriptive visualizations. Earle: My typical learner is a new grad student who studies geoscience. He (Jeff) has had some programming experience in MATLAB, but wants to learn Python. He specifically wants to learn how to use Python to do basic data analysis and visualization. However, Jeff is very busy with classes and wishes he had more time to devote to learning Python. Moreover, Jeff already knows enough about MATLAB to get by with his day-to-day research; Jeff doesn't need to learn Python, he wants to learn Python. Basic outline for Jeff: 1. start with a visual exercise with a canned dataset, focus on visualizing the data in a specific way 2. Provide a basic overview of what you just did, with a focus on syntax media-oriented (display) 3. unstructured exercise: create three different variants with which to display the dataset. (or as many as time allows). circulate with helpers/instructors to assist Tyler: Typical learner is a grad student from the humanities who wants to begin text mining literature with R. She is a motivated learner, but has little programming background. Her data sources are based in Excel. She is a mid-to-advanced computer user. John: Lee is an incoming linguistics master's student, early in his research career. He has a lot of experience using computers, but has only heard about programming, and no idea what R (etc.) might be. He is intelligent and motivated to succeed in school, but has no free time due to course load and outside activities (life in general). Starting point for Lee: Since Lee doesn't know much about programming, I would start by showing Lee why he might find programming useful. I would ask Lee about the kind of tasks he needs to do on a daily basis and come up with examples of how scripting/programming would help him do those tasks. Outline for Lee: Lee probably has to do a lot of data mining, so I would start with a simple routine that loads a data file (say a simple text file), perform some basic operation on the data (e.g. find instances of a certain word) and create some sort of visual output (frequency of word per line). Brian: Postdoc, an expert in the lab and has deep domain knowledge in immunology Has been doing sequence analysis in excel (obviously requires some computational skills) but would greatly benefit from learning how to write code to load files, run simple preexisting tools (alignment, BLAST, translation, etc.) No scripting experience. Basic stats understanding. Has experience with tabular data. Awareness of tools but no experience. Day 2 Be relatable to the learners in the room, but also give them a reason to listen to you as someone who knows what they're talking about If you're in an underrepresented group, it helps to establish your competence immediately. Try to establish yourself as one or two steps ahead of your learners; change how you introduce yourself depending on your audience Highlight what you have in common with your audience if you want to build rapport and seem approachable. Highlight your differences from the audience if you want to emphasize expertise that you have and they don't. Setting the tone and empowering students is the most important part of a SWC workshop Task 1: Learner Introductions What are some possible introductions at the beginning of a workshop? Icebreakers: * "Tell us something you've made that you are proud of" * "What is your greatest research disaster?" * "I used to think, now I think" * Ask the students to think of a relevant computing issue they're experienced and share theirs with the class * Have everyone write a short bio, put bio in hat, have learners read random bio * Pick candy from a bag (Skittles/M&Ms), tell one thing about yourself per candy * What is your spirit animal and why? - this is a bad example as it is culturally insensitive, do not use. Modify before using -- e.g. leave out "spirit" what about, "If you were an animal, what would you be?" * Post short bios before class * "What are you excited about right now?" * Pair intros, then introduce your partner * Small group intros, find commonality among the groups https://github.com/swcarpentry/bc/ One giant repository is rather intimidating and hard to navigate: moving towards different repositories for each lesson. You can still see older Software Carpentry versions. Lessons from Version 4: Nobody watches videos: people want findable things like text, that you can search through, flip through quickly, and find what you’re looking for. It also takes 3.5 hours to produce 10 minutes of video, so why bother? Plus maintenance. Don t do it! Used to be more topics, so instructors could pick and choose, but version 5 streamlined it to the parts that are most important. Even using a text editor can be difficult, if it’s a concept you’re unfamiliar with. Difference between a word processor and a text editor? Difference between a command prompt and a text editor when they’re all just boxes with letters in them? The power of loops and shell scripts becomes apparent pretty quickly, and hopefully people get excited because you’re showing them things that are useful. Shell commands transition well into real programming languages, like Python, where learners now understand the very basics, and you can explain that they’re what you use when the shell isn’t enough. You’re actually doing a “bait and switch” to trick them into learning things they thought were complicated and boring. There are lesson scripts on GitHub, not for you to read off verbatim, but so that people have notes to look at later, and you have a sense of what/how to teach. Version control: great for collaboration! And undoing your own mistakes/changes of mind. Which do you teach first? Doesn’t matter, just emphasize the pay-off. Version control leads into open science as a topic for discussion. Good way to end day 1 of your workshop, because engaging but not too taxing. Weigh the pluses and minuses of making your research open source, and encourage learners to find out the rules at their institution for ownership of intellectual property. Rules at universities are usually unplanned, they evolve, so check it out. Day 2: introduction to Python. Show them data analysis that reveals data was faked; catches attention. Debugging or “defensive programming” is part of the lesson, because by later in the day mistakes will have been made. Purpose is to give them the big idea of what programming looks like, and how it’s done. Syntax, specific functions, etc. they’ll Google later. Just need to convince them that it’s worth their time to learn. #otherpeoplesdata : horror stories. Real world stories about how to han http://f1000research.com/articles/3-62/v1 What does "done" look like in scientific computing? http://www.plosbiology.org/article/info%3Adoi%2F10.1371%2Fjournal.pbio.1001745 What did we get wrong? What does not apply for your discipline? Anyone interested in Software Developers in Research Labs mailing list: https://mailman1.u.washington.edu/mailman/listinfo/research_lab_devs