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 process.

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.

Final Comments

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.