I was a Teaching Assistant (TA) for CS201, which was taught by Kevin Sullivan. To help the other TAs, I created these notes. Many of these notes could apply to any class, not just CS201.
This document was designed to help CS201 TAs improve their question answering skills. It might also be helpful for TAs in other areas, as it deals with basics such as courtesy, correctness, clarity, etc.
Last updated: 19 January 1998
Maintained by: Travis Emmitt
=====================================================================
1) The Purpose of this Document
2) Examples of What Not to Do When Answering Email
3) Goals
4) Guidelines
5) Summary
=====================================================================
1) The Purpose of this Document
The goal here is to provide new and returning TAs both concrete and
general advise on how to be good TAs. It was originally aimed at the
Grad TAs maintaining electronic office hours. However, the advice
and examples are probably of interest to undergraduate TAs as well.
=====================================================================
2) Examples of What Not to Do When Answering Email
The following are examples of emailed questions and responses that
actually occurred (to our shame) during the early part of the Fall
of 1997 semester. As a matter of fact, they all happened on one
night (a Sunday), and prompted the creation of this document.
---------------------------------------------------------------------
2.1 SUBJECT: Borland's Breakpoints
> > I'm trying to debug my program and I'v encountered some
> > difficulties with breakpoints. I've set breakpoints, but
> > when I run the program, it doesn't stop at the breakpoints.
> > I've enabled the stop at breakpoints option in the project
> > options and still haven't had any luck. How do I use
> > breakpoints correctly? Thanks.
>
> Unfortunately, I had the very same problem and eventually
> resorted to using printf()s to output variable values.
> I will forward this to the rest of the TAs to see if they
> had any better luck. If you find out the answer, please
> tell us!
>
> Thanks,
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
There are two wrong messages that the GTA was sending here:
1) "I don't know the answer. Do you know the answer?"
This placed the ball back in the student's court without any
real assurance that we would ever get back to him with an
answer. This was not only totally unhelpful, but it actually
undermined any sort of confidence he might have had in our
ability to answer a question. A BIG no-no.
2) "When confronted by a challenging problem, I give up and
resort to hacking."
This provided a horrible example to the student. The whole
point of the class (Software Development Methods) is to teach
them NOT to just hack away aimlessly. The GTA's email said
the complete opposite, so the student is either going to think
the GTA's a complete idiot for not adhering to the Software
Development principles portrayed by the class, or else that
the Software Developement class itself is totally stupid
and a waste of time. A terrible message to send!
In this case, what the TA *should* have done is say, "I don't know
the answer to your question right now, but I will get back to you
before noon tomorrow with the answer." Better yet, since that day
was Sunday and we don't actually have to be answering email on Sunday,
the TA should have waited until Monday, when he could have had an
answer for the student.
---------------------------------------------------------------------
2.2) SUBJECT: Default Project File
>
> > Is there a way to have Borland 5.0 go to a default of
> > EasyWin, so that you don't need to create a project file
> > every time you write a program? I think the default that
> > it is set to now is just a plain DOS application. The
> > reason I ask is because I remember v. 4.52 had a default
> > of EasyWin.
>
> I believe we're actually going to stop using EasyWin and
> switch back to Application. We'll go over the exact steps
> needed in lab. Until then, assume you have to create a project
> file for every program.
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This is not nearly as harmful as example 2.1, but it is still weak
in that it doesn't provide an answer to his question and portrays
the TA as being uncertain: "I believe..."
The TA should have waited until Monday, or said "I don't know right
now but I'll get back to you either tomorrow or in lab with the
answer." The TA should *not* have let himself sound like he was
making a guess.
---------------------------------------------------------------------
2.3) SUBJECT: Post Lab 1
>
> > Can we set a limit to the number of porblems that will be
> > generated?
>
> Assume the user enters a reasonably small number.
> We don't need to be ultra-robust. If you want a
> ballpark figure, say 100 problems max. No one
> wants to give a student much more than that!
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Here, the main problem is that when the TA said "we don't need to be
ultra-robust", the TA was undermining what is being taught to the
students in class. Part of the class is to teach students that they
*should* be robust.
Also, the TA could have communicated with the other TAs first to come
up with what they all felt was a reasonable maximum value. That would
have helped coordinate responses to similar questions.
---------------------------------------------------------------------
2.4) SUBJECT: Postlab
>
> > with the fstream library,
> > is there any way to clear all the contents out of a file?
> >
> > does the output file have to exist before the program is run or
> > can it somehow be created during the program execution?
>
> I'm not familiar with the fstream library. However, I
> would guess that just about any file stream library would
> included at least one routine for creating a file (open
> in write mode). Usually, write mode overwrites anything
> that may have existed in the file previously. Append
> mode appends to the file. So you want write mode.
> Hope that helps!
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The problem is that the TA sounded like he was taking a guess. He
should have either waited until Monday when he could get a solid
answer for the student, or should have said something more definite
like: "Try using write mode to overwrite existing files. If that
doesn't work, send me email."
Yes, the TA's email was probably helpful to the student, but it made
the TA sound like he didn't want to put forth the effort of actually
finding out how to overwrite files using the fstream library. In a
sense the TA might have conveyed a sense of laziness on his part,
and certainly a lack of authoritativeness.
---------------------------------------------------------------------
2.5) SUBJECT: max number of problems
>
> > Since we are instructed to use the subset of C++ learned in
> > CS101 (ie: no linked lists), it seems that we would have to
> > place an arbitrary limit on the number of generated
> > problems in Postlab 1. Am I correct in this
> > assumption? If so, what would be a reasonable limit?
>
> 100 sounds reasonable to me. By the way, you don't
> need linked lists to create a dynamic array. You can
> simply use memory allocation routines such as malloc
> to allocate the array on the fly. Example (note this
> is in straight C):
>
> int *iarray, size;
>
> printf ("gimme a size: ");
> scanf ("%d", &size);
> iarray = (int *) malloc (size * sizeof (int));
>
> /* now you can reference iarray[0] through iarray[size-1] */
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A simple answer like "Yes, 100" would have sufficed. Of course, the
TA could have waited (as in example 2.3) until he had discussed an
ideal limit with the other TAs.
That the TA provided an example was a good gesture, but the problem
is that the TA was mentioning malloc() when perhaps the student had
not heard of malloc() before, which might have been confusing. Since
the example was completely unnecessary, this was taking the rather
big risk of confusing the student, for the comparatively small payoff
of telling him there's another way to handle dynamic allocation.
The GTA should have kept it simple, or if he had an example that he
was sure would be helpful to the student, the TA should have given
that example instead of the iffy one he gave him.
---------------------------------------------------------------------
2.6) SUBJECT: Pre-Lab 2, Part 2
>
> > When we print out the revised list for the pre-lab, should we
> > avoid using setw()? I wasn't sure because the instuctions said
> > that in the old version, space was wasted or else insufficient,
> > but I didn't know if that meant screen space or memory space.
>
> I believe they're talking about memory space.
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The "I believe" is weak. If the TA wasn't sure about the answer, he
should have either waited until Monday or promised that he'd get back
to the student as soon as he had a definite answer.
---------------------------------------------------------------------
2.7) SUBJECT: PostLab 1
>
> > Why can't my program correctly multiply past 10000? It
> > multiplies shorter nembers fine, for example (89*63)=5607,
> > but it has trouble with longer ones. I'm using 'long
> > double' and it still is giving me crazy answers like
> > (7877*649)=365. What's the deal?
>
> double is floating point, right? try just using long
>
> long i;
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The TA's response was probably not helpful to the student, and if
anything, the "right?" phrase could have made the TA sound like he
was unsure of basic C variable types, which most of us would consider
downright embarassing.
The TA should have asked the student to provide him with the specific
code fragment that was causing errors. The TA could have then looked
over the student's code to find exact what was going wrong with types.
---------------------------------------------------------------------
2.8) SUBJECT: face page
>
> > What is the "face page" that we are told to use in the program
> > requirements?
>
> Please specify which requirements, which lab, which
> page... I'm confused by your question!
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This is more a result of the TA not having read beginning section of
the lab manual, where it specifically states what a face page is.
One of the things we need to do is make sure we all have personal,
up-to-date copies of the lab manual to use as a reference.
The TA should have taken the time to scan the manual to see if it
ever mentioned a "face page," and then told the student what page to
read to find out about what a face page is.
---------------------------------------------------------------------
2.9) SUBJECT: Linked List
>
> > I am having trouble building a linked list. A few questions:
> >
> > 1) on slide 11 of Review of Important Topics, what are the
> > arrows between temp_node & data, temp_node & next.
>
> I cannot look at these slides (don't have permissions) so
> you should try to get in touch with either Dr. Sullivan or
> one of the other students in your class who *does* have
> permission to view those slides. Sorry about that!
>
> > 2) when I use the exact syntax of the slide for the struct
> > definition the compiler gives a "type name expected" error
> > after the statement:
> >
> > struct node {
> > int data;
> > *node next(error here);
> > };
>
> I don't understand what you mean by "error here" within
> the next definition. One thing you might want to try, though
> is declaring it as node *next instead of *node next. PLease
> let me know how this works
>
> GTA
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The TA's advice in the last paragraph to use node *next instead of
*node next was correct, though he should have made himself sound more
confident in his answer.
The problem is the first paragraph, where the TA tells the student
that he cannot look at the slides and so therefore doesn't know the
answer. The TA said "sorry" but made no promise to get back to the
student with an answer.
The TA should have forwarded this message to Kevin to get an answer
to the slide question, and then responded to both questions once he
had an answer to both of them. Giving an answer to only one of the
student's questions was not good enough.
=====================================================================
3) Goals and Guidelines
So what *are* we supposed to do when responding to students' questions?
In order to be good TAs, we must always keep in mind the underlying
goals of both the course and our assistantship.
3.1) The Goal of the Class
First and foremost is the goal of the class. The essential
message of the Software Development Methods course is that
software development is a responsible engineering discipline.
So:
DO NOT encourage students to resort to hacks.
DO NOT encourage them to skimp on robustness.
DO NOT encourage them to loosely interpret design specs.
3.2) The Goal of the TAs
Our goals are secondary, but not much less important to
either the students or us. We need to be a responsive
resource for the undergraduate students.
We want to teach the students to view the TAs as being
dependable, helpful, and authoratative.
----------------------------------------------------------------------
4) Guidelines
4.1) Keep your deadlines.
(This is for the TAs who hold electronic office hours)
Always respond before the deadline is up. This means 4 hours
after the message is sent for any message sent Monday through
Friday, 9-5.
If you don't know the answer to a question and the deadline
is approaching, send the student a response anyway, saying
something along the lines of:
"I'm sorry, I don't know the answer to your question right
at this moment but I promise to get you an answer by such-
and-such a time," where such-and-such a time is *soon*.
If, when the new deadline approaches you still don't have an
answer, you need to send out another message to the student
saying that the problem is turning out to be more difficult
than you expected, that you're still working on it, and that
you will get back to him before "so-and-so", where so-and-so
is another new deadline, still relatively soon.
If you cannot possibly respond to all the CS201 email in time,
ask one or more of the other TAs to help you out.
You need to keep assuring the student that we are working hard
to solve his problem and that we will have a definite answer
for him shortly.
4.2) Be correct.
Do not guess. Do not even sound like you are guessing. Get
a definite answer, through whatever means (fellow TAs, Kevin,
man pages, newsgroups, gurus) and then present your answer to
the student with confidence and directness.
Ask the student for code fragments if that helps you understand
his question better.
Use the undergraduate TAs. They've been through this course
before and are eager to help.
4.3) Be authoritative.
You've all heard it before: How you say something is just as
important as what you say. It is incredibly important that we
convey an air of authority and dependability to the students.
Always try to speak with professional confidence. Be polite
but firm. If you cannot say something definitive and helpful,
then either seek out a better answer yourself or pass along
your question to someone who is better suited to answer the
question.
Kevin would much rather we sound authoritative all the time and
have to correct ourselves once in a while (but preferably not
very frequently!) than for us to develop a reputation for being
uncertain and undependable and therefore untrustworthy.
Says Kevin, "Of course, ever since Plato, the most essential
intellectual skill of all is to *know when you don't know*
something, to admit it, and to seek out an answer if necessary.
Authority combined with ignorance is the worst of all."
4.4) Be clear and concise.
Keep your responses as terse and unambiguous as possible. You
should give examples, but be 100% sure that your example is
appropriate. If you have any doubts, save your example to a
file and send it to the other cs201 TAs, asking them, "Is
this appropriate?" before mailing it to the student.
========================================================================
5) Summary
To sum up the main points of these guidelines and the examples:
o Always meet your 4-hour deadlines. If you can't respond with
an answer, respond with a promise to have an answer soon.
o In answering questions, no guessing. If you know the answer,
say it directly. If you don't know, find out.
o Always be correct, courteous, clear, concise, clockwise, and
confident!
========================================================================
If you have anything you'd like to add, please email me any changes and
I'll incorporate them.
Travis
Last updated: 19 January 1998
Maintained by: Travis Emmitt
This is some email I sent Kevin at the end of last semester. We need
to decide how to resolve these issues before we get too deep into this
semester.
> Kevin, there are certain students that I think are clueless or lazy
> and are hiding behind their groups. I have seen students getting
> help from their friends even when it's not a group project. I know
> we're not supposed to do anything about it, but it seems a little
> unfair to the wiz kids and workaholics to let the slackers end up
> with the same lab grades.
>
> I don't know what we can do about it this semester, but in the future
> you might try:
>
> 1) More extra credit. The slackers won't even try it, since they
> are interested only in doing the minimal amount of work.
>
> 2) More quizzes and exams in class. This will at least get the
> slackers thinking about the class so that maybe they will be
> able to actually do the lab work.
>
> 3) When students are finished in lab, they MUST LEAVE the lab area.
> This reduces the "oh, don't worry about it, I'll help you when
> I'm done with mine."
>
> 4) Busier lab sections (longer labs, more class discussions), so
> that the smarties don't have any TIME to help the slackers and
> the slackers will realize that they NEED to do the work themselves.
>
> 5) Actually have a grade for in-lab activities. Right now we only
> care about the pre-lab and post-lab. So the slackers who just
> give up and don't even try to get help aren't currently getting
> penalized. Right now we don't know *who* is doing the pre-labs
> and post-labs. It could be the slackers, but it could just as
> easily be their friends.
>
> 6) Quizzes during lab. If the slackers aren't scared into trying to
> get prepared for class, they might not bother.
>
> 7) Don't put a whole lot of weight on the students' evaluations of
> each other's work. The workaholics will often be polite or feel
> sorry for the slackers, because the slackers will make a REALLY BIG
> EFFORT to kiss up to the brainiacs, and the brainiacs will eat it
> up.
>
> 8) Have *all* students give a solo presentation at some time during
> the year. If we randomly select students to talk about their
> pre-labs and in-labs, then maybe the slackers will get scared
> into doing the work.
Please email all comments/questions to me.
Travis