How to Effectively Use Lab TAs
Goal of this Guide
Often students do not quite understand either what purpose Lab TAs are
meant to serve, or how to best use this resource to their advantage. In
this brief guide we try and help the 126/226/217 student understand
both of these issues. Now, we know that if you're already in the lab,
you're there because you want help, and more importantly you want to learn.
We know that getting up the learning curve can be frustrating, which is
exactly why the TAs are there every day to help you learn. That being said,
the most important thing to remember is that working with a TA is a two way
street. Leveraged correctly, a good Lab TA can help guide you not just toward
solutions, but really a better understanding of how to approach hard
problems in general. Unfortunately, a lot of people don't immediately
see how to do that, so that's why we wrote this guide.
Ask Concrete Questions!
The most common issue we run into are students that frame their questions
in ways that make it hard for us to help them. In general, these tend
to be rather ambiguous and of the "what's wrong with these 50 lines
of code" sort. Instead of focusing on what makes a question bad though,
here are some examples of good ones.
1) I'm working on N-Body for COS 126, and it's beyond me why
all of my planets are flickering. I have tried moving my calls to
StdDraw around, but I just don't understand what is causing this behavior.
2) I'm working on my HeapManager in COS 217, and for some reason I always
fail the FIFO test cases. I have already written a thorough Heap test function
and ran the program with GDB.
3) I'm working on the COS 226 baseball assignment and I'm having trouble
constructing the MaxFlow graph. I wrote out some examples, so I think I
understand the algorithm, but I don't see how to translate that into code.
The thing that makes them good questions is that they are the product
of a student's own exploration. Programming isn't like other
subjects where there is always a set way to go about getting a solution, much
of the joy and learning comes from the process itself. If you want to know
what a particular line of code does, don't ask us, compile it up and find out
for yourself. Don't fear the mistakes, welcome them, they're part of the
Check that you Have a Well-Defined Question
An easy test for whether or not a question is good is asking yourself, "if a Lab TA comes to help, can I explain to him/her the problem, as well as what I have tried doing to solve it?" If you can answer yes to this question, then asking a Lab TA for help is likely a good idea.
Now bear in mind, it's not as though we're asking you to get to the point of rage-quit before you ask for help; the point of the Lab TAs is to prevent the rage-quit. More than anything we're just asking that you make an honest effort before giving up on a problem. Ultimately, this process of struggling and achieving self-discovery is the best way to become an strong programmer, and is how all of the TAs themselves started out. Thus when we help, it is with the goal of jump starting this process in you.
At this point I'll wrap this up with a few final comments. I know this
has been longish, but thanks for bearing with me to this point. I wouldn't
be writing all of this if I didn't think it would help you on your path
to being a better programmer. We all understand that at times a task
just seems daunting, and the question of where to even start is enough
to intimidate you. In these instances we're happy to help too. Just
show us you have read the assignment and background material,
and given it some good
thought before giving in. You will likely find a TA will give you only a slight
hint or suggestion for direction, and they certainly will not tell you
what is wrong with a chunk of code or what a particular algorithm is.
I think you'll agree with me once you have had the joy of finding the
solution yourself, that the journey was worth the challenge, with
of course, a little help along the way :).
-Alex Daifotis, Head TA 2013-2014
--Last updated by Cristian Alonso and Evan Petersen, 2015.