provide solutions?

[stephenturner]

Suggestion: split each md file into sections with headers for ## problem and ## solutions?

[noamross]

Agree, mostly, but a challenge I'd like to tackle in this to not just provide the solutions but examples of how to get there, as in:

• How to understand the error message?
• How to find the answer in help files?
• What to google to solve this problem?
• How to convert this problem to a minimum reproducible example?

[SamPenrose]

I can't speak to R's footguns, but I strongly support basing pedagogy on "getting unstuck." It is the fundamental skill of computer programming.

[noamross]

@SamPenrose If I make sub-folders by language would you have a source of python/shell beginner questions to provide?

[SamPenrose]

I could certainly invent some, but that feels against the grain of SWC. What equipped helpers with clipboards and asked them to record the pain points they observed? At the end of the day we could type into a shared repository.

[noamross]

Yes, I want to keep this as "raw data" for now. Gleaning stuff from workshops is a good idea. I may put out a request for that once I have this organized a little better.

[dpastoor]

@noamross I don't know if it'd be beyond the scope, but one thing that is a constant battle for my in my group and teaching new students is helping them understand how to evaluate a 'reasonable' solution before blindly copying and pasting.

For better or worse, there are be some really nasty (or old school) 'solutions' that, if anything, reinforce bad practices.

For example, here is one snippet of code that one course used to show how to calculate the mean and sd for groups:

with(seiz.data, tapply(NSeizure, TRT, function(x) {
    sprintf("M (SD) = %1.2f (%1.2f)", mean(x), sd(x))
}))

which gives

but is horribly and needlessly overly complex and makes it quite obtuse.

[noamross]

Yikes! Yeah, that's certainly something to keep in mind. I'm still mostly gathering material for this set of lessons, so nothing is out of scope yet.

Just spitballing, but maybe some guidelines to suggest would be to use solutions that are:

1. Highly upvoted questions and answers on StackOverflow
2. Repeated on multiple sites
3. Are in package vignettes, or materials by package authors.
4. Have some consistency in syntax or approach with what you've been taught or the things above.
5. A solution that you understand or can explain (A great standard, but maybe a high bar, practically.)

And to avoid

1. Are on low-voted (or closed) questions; experienced answerers generally downvote or close rather than answer these.
2. Solutions that depend on packages that have not been updated in a long time