Tutoring  Dos  and  Donts  

Unofficial  alien  of  CS  5  Gold  

Unofficial  alien  of  CS  5  Black  

Unofficial  turtle  of  CS  5  Green  

Unofficial  alien  of  CS  42  

Official  sponsor  of  this  presenta>on  

u  

Thank  you!  

Gracias!  Merci!  

Danke!  

Grutoring  Overview  

•  Black  and  Gold  have  shared  labs,  some  shared  assignments,  and  shared  tutoring  hours  

•  Green  has  its  own  labs,  few  shared  assignments,  and  some  dedicated  tutoring  hours  

•  CS  42  and  CS  60  have  tutoring  >mes,  but  no  scheduled  labs  

•  but…  we’re  all  in  this  together!  

Grading:  Thursday  nights  at  10pm  

 We’ll  start  on  9/8!  

 ½  -­‐  please  bring  

laptops!    

Show  submissions…  

•  Please  “make  the  rounds”  •  Ask  “how  are  you  doing?”  •  Try  to  avoid  “camping  out”  at  your  own  computer  

•  Try  to  avoid  being  “taken  hostage”  

   

In  lab/tutoring  hours…  

Help  students  help  themselves  •  Don’t...  

–  Say  “Oh,  I  see  your  problem!    Just  change  this  here…”  •  Do…  

–  Ask  “What  kind  of  error  are  you  ge\ng?”  –  Help  explain  the  error  message  and  how  it  might  be  helpful  –  Suggest  debugging  strategies  (more  on  this  on  this  in  a  moment)  

–  Ask  “Do  these  strategies  sound  good  to  you?    Let  me  let  you  work  on  this  a  bit  and  I’ll  come  back  in  a  few  minutes  to  see  how  you’re  doing.”  

–  In  some  (rare)  cases  is  it  good  to  reveal  the  problem  directly  •  Student  is  very  frustrated  aaer  repeated  efforts  •  You  are  very  frustrated  aaer  repeated  efforts  •  You  are  besieged  with  ques>ons  and  need  to  do  triage  

Some  debugging  strategies  

•  Look  at  the  error  messages  and  try  to  explain  what  they  are  saying  

•  Test  each  func>on  independently  before  moving  on  – Test  on  small  values  that  can  be  “hand  verified”  – Test  on  “edge  cases”    

•  Use  print  statements  •  Use  the  interpreter  

If  the  problem  is  conceptual…  

•  Back  away  from  the  keyboard  

•  If  you  don’t  feel  comfortable  explaining  the  concept,  see  if  you  can  switch  places  with  another  grutor  –  or  send  the  student  to  one  of  the  profs  

   

If  you  don’t  know  the  answer…  

It’s  OK!      

Admit  it  -­‐-­‐    a  great  thing  to  say:    I  don’t  know…but  let’s  figure  it  out!    

Model  problem-­‐solving  and  debugging  skills.    

Wild  guesses  can  do  more  harm  than  good.    

S9ll  don’t  know?  

Never  leave  students  hanging…  •  It’s  your  responsibility  to  get  the          

 ques>on  to  someone  who  can  answer  it.  

Do  •  Find  someone  else  who  can  answer  the  ques>on.  •  Or,  help  them  send  clear,  complete  email  to  the  help  

alias/Piazza  site.  •  Or,  compose  the  email  yourself  and  cc  the  students  –  

be  sure  that  the  file  in  ques9on  has  been  submi:ed!  

Don’t  •  Shrug,  and  walk  away.  •  Say  “I  don’t  know.  Find  the  prof,”  and  walk  away.  •  Say  “I  don’t  know.  Send  an  email,”  and  walk  away.    

What  if  you  DO  know?  

Be  Respecmul!      Beware  The  Curse  of  Knowledge    

“Lots  of  research  in  economics  and  psychology  shows  that  when  we  know  something,  it  

becomes  hard  to  imagine  not  knowing  it.  As  a  result,  we  become  lousy  communicators.”  

Prepara>on  

Before  you  show  up  to  lab/office  hours:  •  Read  the  assignment  carefully!  

•  Think  how  you’d  approach  the  problems…    

•  Op>onally,  review  solu>ons  But  -­‐-­‐  there  are  o@en  many  ways  to  solve  a  problem!  

     

These  count  as  paid  work    

Other  thoughts/>ps?  

Any  strategies  that  you  find  par>cularly  effec>ve  or  ineffec>ve?  

A  Case  Study:  Monte  Carlo  Pi  

The  idea   Buggy  code!