Lab TAing

One of my colleague just got a TA ship and is in charge of teaching the electronics lab. Since I had TAed this lab previously, she approached me for any tips or tricks I had to offer. As I am always too eager to dole out advices, we had a good twenty-minute discussion on what one ought and ought-not to do. The gist of my advice was that role of the TA was to assist the students do the experiments without resorting to any kind of spoon-feeding. Towards this end, I would stress the importance of the following.

1. Do the experiment in advance, even if it is piece of cake. Performing the experiment yourself makes potential problems surface when there would seem to be none. Some of them may be really trivial, e.g., an experiment setup may be such that it may require three probes per person, and you may need to get extra probes beforehand. If the experiment is complicated, you could also jot down the possible mistakes students are going to make.

2. Ask the students to start doing the experiment as soon as they arrive, without waiting for the TA. The students should also be encouraged to skip a problem if they are struck if the TA is not available or busy somewhere. These practices help control congestion especially if you have a large class and for particularly difficult experiments.

3. Never tell the solution, always drop progressively easier hints. Not only will this make the students think harder but also make them smarter, taking some load off the TA's shoulders for future experiments. You could try to give the students some pointers in the beginning but the best practice is to let them figure out everything by themselves. However you must be available for hinting whenever they are struck.

4. Visit each student periodically, see what numerical values they obtained and whether they are in the ballpark. Encourage students to doubt their solutions and "feel" the circuit. The ability to approximately solve circuits is extremely important. When a student shows you his value, think aloud on how you would confirm that the value is approximately correct. Encourage the students to emulate this reasoning style.

5. Encourage proper report writing skills. Depending on the instructor/course, one may or may not have to submit lab reports and those require specific guidelines to be handed out. But the process of jotting down observed values in the lab is also important. Encourage students to write down everything, including what may have went wrong.

6. Drop examples of real-life applications where the said circuits are being used. It takes away the monotony of lab work.

7. Lab exams are the easy part (at least for the TA). These are days when you can relax while the students toil.

Apart from these, I also follow the philosophy that for the time a person is my student, "their business is my business." In particular, I remember a related incident where a co-TA's best student did not show up at the final exam. While discussing the grading policy later, I was surprised to learn from him that he did not even send an email inquiring his student about what had happened as "it was none of his business". I disagree with this ideology but do understand that it may be something cultural.

Proposal Reviews

I recently got an opportunity to review a couple of NSF proposals my professor gave me. Interestingly, one of the proposal was excellent while the other one was mediocre. I thus learned a lot comparing their writing styles.

For those new to the dojo, most state, army and private funding is procured by submitting proposals to the corresponding agencies which are mostly peer-reviewed. The intent of the proposal is to pose research problems, solving which would significantly advance the state of the art. These problems must somehow be related to the authors past work, thereby establishing his/her credibility. In the end, not all problems need to be solved. The idea instead is to establish concrete directions of future research that are promising not only for the author but for the entire community.

While I am no authority on proposal writing, I could point out some "common mistakes" I have noticed thus far.

1. Wish-list: The proposal should not sound like the future-work sections of conference papers. One cannot simply say that NP-hard problems will be investigated without explicating the exact approach. In fact each proposed problem must be devoted a couple of paragraphs at least: one formulating the problem and another giving an insight into the proposed solution methodology and possible challenges.
2. Text-only: Mathematics is a language. Use of equations helps express problems clearly. While it is necessary to keep the description at a higher level, one or two equations per-page is not scary at all.
3. Secret-designs: It is possible for a reviewer to pick up the proposed solution and start working on it. However, proposals which entice reviewers into taking up the problems are always considered the best and always get accepted. Its a risk that has to be taken.
4. Jargon-master: Peer reviewed proposals do not need to use DARPA-like jargon except probably beyond the summary. Buzzwords like cyber-infrastructure should not be used in a proposal that investigates routing protocols.
5. Can-be-generalized: The usefulness of running examples cannot be stressed more. However, generalizing toy-examples is often easier said than done. I have seen at least two proposals that described their approach on toy examples and left the problems at that stage.