Other points we can think about working in

[kaijagahm]

Other points that have been brought up in other educational resources about this topic that we could consider working in (or not):

Concept	Explanation	Suggested way to integrate	Sources
"Code that I don't have to run"	Experienced users won't actually have to tinker with everything, so formatting is useful because it helps them see the code and results clearly and makes the process of helping faster by saving them steps	Episode 5--reprex package--formatting section, another justification for why we should care about formatting at all	1. Help me help you
Being polite to other people's computers	Don't clear the environment, don't introduce new variables, don't make a lot of files and forget to clear them, etc	Out of scope for this lesson, I think, but consider briefly mentioning in the intro or elsewhere	1. Help me help you
Screenshots are bad (and other "don't"s)	Common practices that I often see that are bad practice, and an explanation of why they are not helpful	I have this in the intro but I think it's demotivating there. Consider working in each "don't" next to the corresponding "do" in the lesson as a callout	1. Discourage screenshots of code and/or errors, 2. Screenshots can be helpful, but only text can be copied and executed, 3. Help me help you, 4. An image of your code is not helpful
Using backticks for formatting		Unnecessary I think, because {reprex} does this automatically.	1. How to ask good questions
Further discussion of the emotional aspects of this and helper/learner relations	Learners are frustrated because they've never been taught this stuff; helpers are frustrated because people don't give them enough information to help and therefore don't make good use of their time	Out of scope for the lesson except brief mention in the intro (which is already there). Belongs in my TAR paper.	1. Is the R community hostile?, 2. Why is StackOverflow ... so scary?