Skip to content
This repository has been archived by the owner on Jan 3, 2018. It is now read-only.

Two additions to the guide #637

Merged
merged 1 commit into from
Aug 10, 2014
Merged

Two additions to the guide #637

merged 1 commit into from
Aug 10, 2014

Conversation

lsblakk
Copy link
Contributor

@lsblakk lsblakk commented Aug 1, 2014

No description provided.

@wking
Copy link
Contributor

wking commented Aug 1, 2014

On Thu, Jul 31, 2014 at 05:17:11PM -0700, Lukas Blakk wrote:

M novice/teaching/01-general.md (21)

I think “never” is too strong ;). For keyboard stealing, I agree that
it's better to have students in the driver's seat, but you have to
balance that against time their spending out of the flow of the rest
of the class. Unless you do something to get them going faster,
they're never going to catch up. Not catching up is fine if you have
a helper for every behind-the-ball student (yay one-on-one tutoring),
but if you're not so flush with helpers, you'll have to take some
shortcuts.

I also agree that blindly copy/pasting is an act of faith in the
source of the pasted code. But that's also true of any software or
script you run. I think it's important to have students ask “do I
trust the source of this code” before running it, but often the answer
is going to be “yes”. With a class full of scientists, this sort of
critical thinking should have been drilled into them for years in the
context of finding reliable sources, so they've already internalized
most of the “this is a reliable source” cues.

I think a better reason for not copy/pasting (as the instructor), is
that it slows you down (like writing things out on the chalkboard,
instead of blowing through a set of slides) and gives students time to
keep up.

@lsblakk
Copy link
Contributor Author

lsblakk commented Aug 1, 2014

This is for a guide, so I believe it to be valuable to put in guidance about how taking over a keyboard can shut down a student's learning. Could be amended to "Do everything you can to avoid taking over a student's keyboard and if you feel that is the only option remaining, ask them first before touching it".

For the copy/pasting - I realize now that this is more something for the instructors to share with students and not for the instructors to take on themselves. Will look and see if there is a better place for this.

@wking
Copy link
Contributor

wking commented Aug 1, 2014

On Thu, Jul 31, 2014 at 09:56:48PM -0700, Lukas Blakk wrote:

This is for a guide, so I believe it to be valuable to put in
guidance about how taking over a keyboard can shut down a student's
learning. Could be amended to "Do everything you can to avoid
taking over a student's keyboard and if you feel that is the only
option remaining, ask them first before touching it".

That sounds much better to me :).

For the copy/pasting - I realize now that this is more something for
the instructors to share with students and not for the instructors
to take on themselves. Will look and see if there is a better place
for this.

I don't think we have a “system administration” section, but I think
something like that would be a good place for this sort of
student-directed advice. You could move from this sort of negative
advice (“don't …”) on to more positive advice (“do …”) and touch on
root (or generic admin privileges), package management (system wide
and per-user), and software stacking (see also #152 and #365). I
think that would all be useful stuff to review with new users (or
newly-serious users), but I don't know where such a block would land
in our two-day curriculum.

gvwilson pushed a commit that referenced this pull request Aug 10, 2014
Two additions to the guide
@gvwilson gvwilson merged commit 85be1c6 into swcarpentry:master Aug 10, 2014
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants