28
edits
Changes
Created page and added content from notes from code4lib 2018 breakout sessions and talk.
= Teaching Beginners =
People working in our fields often find themselves teaching technology to beginners. This may be through formal workshops offered to the public or to peers in our fields; to colleagues who need to learn new technology in the workplace; or through informal peer teaching where we share technology with others in any setting. Below are some tips and ideas from the code4lib community on teaching technology to beginners. (Some of these tips came from [http://2018.code4lib.org/talks/for-beginners-no-experience-necessary a talk] and two breakout sessions at [http://2018.code4lib.org/ code4lib 2018].)
== General tips ==
*Do not assume experience with Git or the Command Line. Be careful about the Bash shell as well. If you want your attendees to have familiarity with certain tools, don’t assume that they do. It is especially annoying if you go to a workshop where those tools are not the focus, but it is assumed that attendees are well-versed in them.
*At the same time, when teaching it can be good to send people to do an exercise and, if they can't figure it out or run into issues, they can use git to move further along in the program so they are caught up with the rest of the class. However, if git is not the focus of the workshop and it is not an assumed skill, the git commands to do so should be very clearly communicated to the attendees.
*When you distribute code that is long, number sections in the comments so people can more easily navigate it. Number the exercises. Numbers give us a common language for navigating.
*Heavily comment code with pseudo-code and explanations about what each section does.
*Notebooks for teaching programming, such as the [https://jupyter.org/ Jupyter notebook] can give users a great intro, because you can give them the code to run through the notebook.
*Instead of saying that a particular idea is ‘easy’ or ‘hard’, say that the idea is ‘foundational’ or a ‘building block’, and this other idea is ‘more complex’. If an attendee is struggling with an idea, saying that it is ‘easy’ only makes the person feel worse. They already felt stupid because they didn’t get the idea; now they feel even more stupid because they didn’t get an ‘easy’ idea.
*If you encounter students who are either silent or are being angry towards you, it may be that they are trying not to cry either by being stonily silent or covering it with another emotion (i.e., anger.) This is not a funeral, it's a workshop, so people don't want to cry.
*As an instructor, avoid saying too much, such as, "We'll do x here, but if you are doing y you would do a and if you were doing z you would do b". If you are teaching x, just say, "We will do x here." Full stop. Don't show off by bringing up other examples. Some people talk a lot when they are nervous, and teaching and public speaking can make people nervous. Also, most people will talk to fill silence in a conversation. Be okay with not talking and having quiet so people can think and process information.
*Similarly, plan silences and pauses. It is hard to learn something complex when someone is talking and you are trying to figure out if you need to be listening while also trying to do this new task.
*Don’t make fun of people who mispronounce words, they learned them from reading. Similarly, if someone has clunky code it may because they are self-taught; be gentle when you show them a new way. (See the [https://www.recurse.com/code-of-conduct Recurse Center Rules] on 'well, actually' and other social problems.)
*Reading good code on github is good workshop takeaway. It is great for workshop leaders to hand out lists of projects people can investigate on their own. It is also important to demonstrate projects with good documentation.
*If attendees are allowed to choose their own operating systems for a workshop, then the instructor needs to provide instructions for Mac, Linux, and Windows, if they are different. Instructors should not just wave their hands and say 'I'll show you this system. The other ones are different." Even better is to use a platform-agnostic approach so that beginners can focus on the specific tool and not spend time trying to figure out problems with their computers. Also, when beginners make mistakes, they can just start over and not have ruined the whole thing.
*There are Chrome extensions that run a web server in the browser. There are web-based interpreters for programming. It may be nice to give people the option to use a web-based interpreter or a desktop one, so those who feel more comfortable with a desktop one can do so, but everyone can play in the web-based one.
*When designing a workshop, try to work with a fresh install and without admin privileges. You may not realize that you need dependencies or admin privileges until you test.
*Avoid sports metaphors or idioms that may not make sense outside a certain cultural group. If attendees need to have knowledge of a particular domain prior to taking the workshop, that should be clear in the workshop description.
*Asking attendees to raise their hands if they need help is problematic. It is ableist. It also requires people to self-identify as needing help in front of a room of their peers. One alternative approach is to provide attendees with two different color post-it notes. As the workshop progresses, they attach one color to the top of their computer when they have finished an exercise. They use another color to indicate when they need assistance. This still requires self-identification of needing help to an extent, but it is not as obvious as raising a hand.
== Gaining teaching experience ==
*If you want some teaching experience, collaborate with instructors to help them run workshops. When someone offers a workshop, don’t be afraid to email and ask if they want teaching assistants, or a co-teacher. They may be happy to have help. At the same time, if teachers do not want help, they should not feel pressured to accept such requests.
== Learning how to teach beginners ==
*Library organizations seem to be good at providing professional development opportunities for training librarians for reference instruction, but not for technology instruction. We need professional development opportunities for teaching technology to adults.
*We don’t need to reinvent the wheel; we just need to talk to the people who work in this area already. For example, instructor training is offered by [https://software-carpentry.org/ Software Carpentry] and [https://librarycarpentry.github.io/ Library Carpentry].
*Another resources is the [https://www.diglib.org/groups/digital-library-pedagogy/ DLF Digital Library Pedagogy Group].
*We need training on peer teaching and mentoring. This is especially important in senior/junior technology job relationships. This is often part of someone’s job description, but we are not formally trained how to do this. Pair programming can be good if people are not too far apart in skill, so they both learn from each other; if they are too far part, it can be frustrating for each participant. Pair programming is not for everyone, though.
== Helping attendees determine if they should attend your workshop ==
*A key problem is that workshops are sometimes advertised as being ‘for beginners, with no experience necessary’. But this is misleading, as the instructors and potential attendees will likely have very different ideas about what that means. A better approach is for instructors to list key skills and experiences, or analogous skills and experiences, that attendees should have before taking the workshop. As an example, people who have used formulas in Excel - even sporadically - are on a completely different level from beginners who are not sure how to use the mouse.
*Instructors should help attendees answer the question, “Is this workshop for me?”
*Recommend people try exercises at [https://www.codecademy.com/ codecademy] or other free online training sites to see if they want to learn more. It may help them decide that now is not the time for them to pursue training in this area. (It's okay for someone to decide that this is not a good time to learn something.) Caring for kids or aging parents; fighting poverty and working multiple jobs; and other personal obligations can interfere with people's ability to find time and mental energy for learning. Sometimes they really want you to give a very gentle introduction with a lot of hand-holding. This is okay. Also, their frustration tolerance level may be very low because of external factors. This is okay, too.
*The people involved with [https://software-carpentry.org/ Software Carpentry] have learned that if you call a workshop ‘intermediate’, no one signs up. So maybe we need to drop this beginner/intermediate/advanced labeling altogether. Just talk about your prerequisites and expected outcomes.
== Respecting the time required for excellent teaching ==
*If teaching colleagues is part of your job, it should be in your job description, such as “10% of time devoted to developing teaching materials and teaching peers”.
*People should be paid to design and teach workshops. Workshop design and delivery requires skill and energy, and people should not be doing this for free. At the same time, be careful of the cost of workshops. Not everyone gets institutional support and they have to make a lot of sacrifices to come to your workshop. Most people in this field are not independently wealthy.
== Creating a positive learning environment ==
*There should be a Code of Conduct for attendees. If nothing else, have attendees read the [https://www.recurse.com/code-of-conduct Recurse Center Rules] (also known as the Hacker School Rules). This helps curtail situations where attendees disparage each other’s operating systems; engage in mansplaining; or respond to a basic question with an overly complex response requiring esoteric techniques that is deliberately designed to confuse and belittle the questioner.
== Texts for teaching and learning ==
*Elizabeth Wickes gave a lightning talk at code4lib 2018 where she asked about programming textbooks for teaching LIS students that do not require trigonometry or advanced skills in specific knowledge domains. Texts that might be used as a model are No Starch Press books like “Learning from Scratch” and “Python for Kids”. Since they are written for children, they do not assume college- or even high school- level familiarity with particular knowledge domains. They are models of clarity.
*The book [http://www.openbookproject.net/thinkcs/python/english2e/ “How to Think Like a Computer Scientist”] uses Python, but focuses more broadly on thinking programmatically.
== Visual programming languages ==
*If you want to teach adults with a visual programming language like Scratch or Blockly, but you do not want to say to your students, “we’re going to do programming for kids”, Blockly is slightly more adult-oriented than Scratch. At the same time, Scratch is not a bad idea. In fact, it may be a relief to your students if you tell them that they are going to do a gentle introduction to programming through one of these languages.
== Next steps ==
*For self-taught and self-directed learners, some recommended resources are [https://www.codecademy.com/ codecademy], [https://www.udemy.com/python-video-workbook/landing-page/ Udemy’s Python workbook course], and the [https://www.coursera.org/specializations/python University of Michigan’s “Python for Everybody” specialization on Coursera]. [https://coderdojo.com/ Coderdojo] and other code practicing sites let you look at other people’s solutions, so you can learn by seeing what other people do
== Teaching workshop series or multi-week courses ==
*Respect students’ cognitive load. There are limits to how much a person can learn at any one moment. If students are feeling overloaded, that may be a good signal to do additional exercises for practice at their current level of understanding, instead of moving forward to a new topic.
*Engage students in dialogue to find out about their mental models. For beginners, what computers do is largely a black box, and they have to come up with models to explain what is happening in the black box until they gain sufficient knowledge to understand what is actually happening in the black box. Their models might be problematic at the early stages of learning; they may make connections where there are none, or assume causality where none exists. Talking them through their models can help us find and correct these misperceptions.
People working in our fields often find themselves teaching technology to beginners. This may be through formal workshops offered to the public or to peers in our fields; to colleagues who need to learn new technology in the workplace; or through informal peer teaching where we share technology with others in any setting. Below are some tips and ideas from the code4lib community on teaching technology to beginners. (Some of these tips came from [http://2018.code4lib.org/talks/for-beginners-no-experience-necessary a talk] and two breakout sessions at [http://2018.code4lib.org/ code4lib 2018].)
== General tips ==
*Do not assume experience with Git or the Command Line. Be careful about the Bash shell as well. If you want your attendees to have familiarity with certain tools, don’t assume that they do. It is especially annoying if you go to a workshop where those tools are not the focus, but it is assumed that attendees are well-versed in them.
*At the same time, when teaching it can be good to send people to do an exercise and, if they can't figure it out or run into issues, they can use git to move further along in the program so they are caught up with the rest of the class. However, if git is not the focus of the workshop and it is not an assumed skill, the git commands to do so should be very clearly communicated to the attendees.
*When you distribute code that is long, number sections in the comments so people can more easily navigate it. Number the exercises. Numbers give us a common language for navigating.
*Heavily comment code with pseudo-code and explanations about what each section does.
*Notebooks for teaching programming, such as the [https://jupyter.org/ Jupyter notebook] can give users a great intro, because you can give them the code to run through the notebook.
*Instead of saying that a particular idea is ‘easy’ or ‘hard’, say that the idea is ‘foundational’ or a ‘building block’, and this other idea is ‘more complex’. If an attendee is struggling with an idea, saying that it is ‘easy’ only makes the person feel worse. They already felt stupid because they didn’t get the idea; now they feel even more stupid because they didn’t get an ‘easy’ idea.
*If you encounter students who are either silent or are being angry towards you, it may be that they are trying not to cry either by being stonily silent or covering it with another emotion (i.e., anger.) This is not a funeral, it's a workshop, so people don't want to cry.
*As an instructor, avoid saying too much, such as, "We'll do x here, but if you are doing y you would do a and if you were doing z you would do b". If you are teaching x, just say, "We will do x here." Full stop. Don't show off by bringing up other examples. Some people talk a lot when they are nervous, and teaching and public speaking can make people nervous. Also, most people will talk to fill silence in a conversation. Be okay with not talking and having quiet so people can think and process information.
*Similarly, plan silences and pauses. It is hard to learn something complex when someone is talking and you are trying to figure out if you need to be listening while also trying to do this new task.
*Don’t make fun of people who mispronounce words, they learned them from reading. Similarly, if someone has clunky code it may because they are self-taught; be gentle when you show them a new way. (See the [https://www.recurse.com/code-of-conduct Recurse Center Rules] on 'well, actually' and other social problems.)
*Reading good code on github is good workshop takeaway. It is great for workshop leaders to hand out lists of projects people can investigate on their own. It is also important to demonstrate projects with good documentation.
*If attendees are allowed to choose their own operating systems for a workshop, then the instructor needs to provide instructions for Mac, Linux, and Windows, if they are different. Instructors should not just wave their hands and say 'I'll show you this system. The other ones are different." Even better is to use a platform-agnostic approach so that beginners can focus on the specific tool and not spend time trying to figure out problems with their computers. Also, when beginners make mistakes, they can just start over and not have ruined the whole thing.
*There are Chrome extensions that run a web server in the browser. There are web-based interpreters for programming. It may be nice to give people the option to use a web-based interpreter or a desktop one, so those who feel more comfortable with a desktop one can do so, but everyone can play in the web-based one.
*When designing a workshop, try to work with a fresh install and without admin privileges. You may not realize that you need dependencies or admin privileges until you test.
*Avoid sports metaphors or idioms that may not make sense outside a certain cultural group. If attendees need to have knowledge of a particular domain prior to taking the workshop, that should be clear in the workshop description.
*Asking attendees to raise their hands if they need help is problematic. It is ableist. It also requires people to self-identify as needing help in front of a room of their peers. One alternative approach is to provide attendees with two different color post-it notes. As the workshop progresses, they attach one color to the top of their computer when they have finished an exercise. They use another color to indicate when they need assistance. This still requires self-identification of needing help to an extent, but it is not as obvious as raising a hand.
== Gaining teaching experience ==
*If you want some teaching experience, collaborate with instructors to help them run workshops. When someone offers a workshop, don’t be afraid to email and ask if they want teaching assistants, or a co-teacher. They may be happy to have help. At the same time, if teachers do not want help, they should not feel pressured to accept such requests.
== Learning how to teach beginners ==
*Library organizations seem to be good at providing professional development opportunities for training librarians for reference instruction, but not for technology instruction. We need professional development opportunities for teaching technology to adults.
*We don’t need to reinvent the wheel; we just need to talk to the people who work in this area already. For example, instructor training is offered by [https://software-carpentry.org/ Software Carpentry] and [https://librarycarpentry.github.io/ Library Carpentry].
*Another resources is the [https://www.diglib.org/groups/digital-library-pedagogy/ DLF Digital Library Pedagogy Group].
*We need training on peer teaching and mentoring. This is especially important in senior/junior technology job relationships. This is often part of someone’s job description, but we are not formally trained how to do this. Pair programming can be good if people are not too far apart in skill, so they both learn from each other; if they are too far part, it can be frustrating for each participant. Pair programming is not for everyone, though.
== Helping attendees determine if they should attend your workshop ==
*A key problem is that workshops are sometimes advertised as being ‘for beginners, with no experience necessary’. But this is misleading, as the instructors and potential attendees will likely have very different ideas about what that means. A better approach is for instructors to list key skills and experiences, or analogous skills and experiences, that attendees should have before taking the workshop. As an example, people who have used formulas in Excel - even sporadically - are on a completely different level from beginners who are not sure how to use the mouse.
*Instructors should help attendees answer the question, “Is this workshop for me?”
*Recommend people try exercises at [https://www.codecademy.com/ codecademy] or other free online training sites to see if they want to learn more. It may help them decide that now is not the time for them to pursue training in this area. (It's okay for someone to decide that this is not a good time to learn something.) Caring for kids or aging parents; fighting poverty and working multiple jobs; and other personal obligations can interfere with people's ability to find time and mental energy for learning. Sometimes they really want you to give a very gentle introduction with a lot of hand-holding. This is okay. Also, their frustration tolerance level may be very low because of external factors. This is okay, too.
*The people involved with [https://software-carpentry.org/ Software Carpentry] have learned that if you call a workshop ‘intermediate’, no one signs up. So maybe we need to drop this beginner/intermediate/advanced labeling altogether. Just talk about your prerequisites and expected outcomes.
== Respecting the time required for excellent teaching ==
*If teaching colleagues is part of your job, it should be in your job description, such as “10% of time devoted to developing teaching materials and teaching peers”.
*People should be paid to design and teach workshops. Workshop design and delivery requires skill and energy, and people should not be doing this for free. At the same time, be careful of the cost of workshops. Not everyone gets institutional support and they have to make a lot of sacrifices to come to your workshop. Most people in this field are not independently wealthy.
== Creating a positive learning environment ==
*There should be a Code of Conduct for attendees. If nothing else, have attendees read the [https://www.recurse.com/code-of-conduct Recurse Center Rules] (also known as the Hacker School Rules). This helps curtail situations where attendees disparage each other’s operating systems; engage in mansplaining; or respond to a basic question with an overly complex response requiring esoteric techniques that is deliberately designed to confuse and belittle the questioner.
== Texts for teaching and learning ==
*Elizabeth Wickes gave a lightning talk at code4lib 2018 where she asked about programming textbooks for teaching LIS students that do not require trigonometry or advanced skills in specific knowledge domains. Texts that might be used as a model are No Starch Press books like “Learning from Scratch” and “Python for Kids”. Since they are written for children, they do not assume college- or even high school- level familiarity with particular knowledge domains. They are models of clarity.
*The book [http://www.openbookproject.net/thinkcs/python/english2e/ “How to Think Like a Computer Scientist”] uses Python, but focuses more broadly on thinking programmatically.
== Visual programming languages ==
*If you want to teach adults with a visual programming language like Scratch or Blockly, but you do not want to say to your students, “we’re going to do programming for kids”, Blockly is slightly more adult-oriented than Scratch. At the same time, Scratch is not a bad idea. In fact, it may be a relief to your students if you tell them that they are going to do a gentle introduction to programming through one of these languages.
== Next steps ==
*For self-taught and self-directed learners, some recommended resources are [https://www.codecademy.com/ codecademy], [https://www.udemy.com/python-video-workbook/landing-page/ Udemy’s Python workbook course], and the [https://www.coursera.org/specializations/python University of Michigan’s “Python for Everybody” specialization on Coursera]. [https://coderdojo.com/ Coderdojo] and other code practicing sites let you look at other people’s solutions, so you can learn by seeing what other people do
== Teaching workshop series or multi-week courses ==
*Respect students’ cognitive load. There are limits to how much a person can learn at any one moment. If students are feeling overloaded, that may be a good signal to do additional exercises for practice at their current level of understanding, instead of moving forward to a new topic.
*Engage students in dialogue to find out about their mental models. For beginners, what computers do is largely a black box, and they have to come up with models to explain what is happening in the black box until they gain sufficient knowledge to understand what is actually happening in the black box. Their models might be problematic at the early stages of learning; they may make connections where there are none, or assume causality where none exists. Talking them through their models can help us find and correct these misperceptions.