TA Tips For Doing Badly

So, you're an A+ student and you're bored with doing so well and are looking for a change. However, you've been so good for so long, you've forgotten how to do badly. Herein lies my "TA Tips For Doing Badly." This was based on my personal observations while TAing, and has since been added to by other TAs who will testify that these are all genuine occurrences that they have experienced and will help you in your quest to do badly.

Make some typos in the digits of your student ID and the first letters of your last name.
Don't number your questions. This achieves maximum effect if you also do the questions out of order, and mix up various parts of the questions.
Don't staple your assignments. Don't use a paper clip either. Just fold the corner in a fashion that is virtually guaranteed to come apart on the first paper sorting. When doing this, it is also a good idea to make sure your name is not on all of the pages. If it is, the TA has a fighting chance to put the whole mess back together and staple it for you, which you don't want. Remember, you are trying to do badly!
If you have a staple fetish and have to staple your assignment, staple pages together in a random order. This is particularly effective if you combine it with the first rule of not numbering questions. Write on each page differently so the TA has to turn the assignment by 90 or 180 degrees whenever s/he goes to the next page.
An alternate solution to the stapling dilemma: submit your assignment as a collection of separate parts inserted at different places of the pile (This is easily achieved by submitting bits at different times). Make sure those parts reference each other so it is impossible to mark one question without looking at as many other parts as possible.
Write illegibly. I mean really illegibly. I don't mean your typical "the TA will have to strain to read this" kind of illegible. I mean the kind where three out of five TAs will look at the writing and not have a clue what is written. This is best mixed with really bad grammar and spelling, so as to prevent even basic contextual analysis of the sentences. Some techniques to help you with illegibility:
1. Use 4H pencils.
2. Make sure you write the answers by holding a sheet of paper on your knee while trying to move your foot along with some background music. Write with your left hand if you are right-handed, and with your right hand if you are left-handed. After each sheet is complete in this manner, tear it into 4 or more "equal" pieces and then attach them back together with a tape (you need "equal" pieces so you can attach them in the wrong order and with some of them turned around). (Don't forget to write a note: "Sorry about the writing; I was writing in a car." Parts of this sentence should be on at least two pieces.)
3. Stains (for example blood stains) and burnt parts of the paper help sometimes.
Ignore grammar and spelling. Some people are just stuck with the ability to write legibly. If you are one of these, then make sure you spend some time getting the grammar and spelling wrong. A simple spell checker, available on every OS today, will help you in this task. You should run the spell checker and make sure you have at least one word spelled incorrectly per sentence. Unfortunately, grammar checkers are not generally available. What passes for grammar checkers (e.g. from Microsoft) are really style checkers. They are useful in ensuring a generally insipid style, but probably will not help you in getting the grammar wrong. On the good news front, you probably went to a school that encouraged bad grammar by focusing on "creativity." If you still need help, Strunk and White wrote a wonderful little book called "The Elements of Style." It (mostly) demonstrates good grammar, so read that book and attempt to break at least one of its rules in each sentence you write.
Make your assignment fatter than anyone else's. This is best achieved by printing out random irrelevant junk. Source code is a particularly good choice for fattening up assignments. Better is test output. Remember that just because you've used "submit" so the TA can read your code, and test it, is no reason not to print it.
Further tips on making your answers longer:
1. For every word in the question copy its definition from the book somewhere in the middle of a paragraph you are writing so it is harder for the TA to find and skip over.
2. Answer the question by a paraphrasing it in some convoluted way. The more extra and unnecessary words you type the better.
3. Make your sentences at least 5 lines long, and make sure they are grammatically incorrect. Using non-English words also helps.
4. Remember that a picture is worth a 1000 words! Whenever asked to draw something, don't do it! Describe it in words.
Have your program print our random irrelevant junk to obscure the results. The more the better. You may be compulsive in getting your program correct, but don't let that get you down. You can still do badly by burying the correct results in mind-numbing amounts of "debugging" output.
Draw broad sweeping conclusions based on two data points. This is even better if you draw a graph that ignores the actual data points you have gathered.
Make sure you have at least 6 decimals in every answer you give. Especially effective when the answers are incorrect!
If you are asked to present results, construct a table (taking the previous point into account, of course). If you are asked to graph results, make sure that your graph covers a much larger range than do the data points. Your entire plot should be compressed into the middle third or less of the the axes. It is also useful if the axes extend beyond legal values for the item being plotted. For example, a probability graph should have a range that includes values less than zero and greater than one.
If you are subsequently required to discuss your results, simply describe your graph. Pretend that the TA somehow lost your graph and therefore must rely on your colourful description of every rise, fall, and bend.
Never be precise. If the maximum performance of something is X and you measure X-a, write the following:
1. a is small: It performed well.
2. a is in the middle: It performed reasonably.
3. a is large: It performed poorly.
When the answer to a question is either "yes" or "no" or just a number, make sure the answer is very hard to find. Put it somewhere in the middle of a sentence in a middle of a paragraph and make sure it is not highlighted or otherwise identified.
If you are lucky, and a question asks you to fill in a table, don't draw the table, but instead discuss each square separately in one long paragraph.
In general, answer each question with one long paragraph. It should always be one continuous line of text.
Avoid writing formulae. Instead express any formulae in words (For example, "Force is the first derivative of the product of the inertial mass and the first derivative of the position of an object, which can be simplified, in instances where the inertial mass is effectively approximated by a constant, as the product of the inertial mass and the second derivative of the location of the object." is far better than "F = d/dt(mv) = ma.")
If you are using "scratch paper," such as the back side of printouts, submit it instead of the final copy. This is especially useful if it is not immediately clear that the printed portion is not part of the assignment.
Start as many of your sentences as you can with phrases of the form "As stated in Chapter 5, ...", or "Along the lines of the material presented in the book, ..." so the TA will have to carefully read several pages before realizing that it is irrelevant to the question.
Some tips on programming badly:
1. Ensure you code has very long lines that wrap around in any reasonable terminal window size.
2. Make sure your comments are positioned in such a manner that it is hard to distinguish between code and comments. For example:
  
  /*****/x*=1/1;/*x*=2/3;************************************************* x *= x *1/ 2; // comments are fun.. here is some art: __ __ x = x * (2 - 1/1); // this is a commented out piece of a comment \*\ /*/ x = x * 2; // la la la la | o | x = (6 - 2*3); // ra ra ra |__-__| x = x - 1; // this is a comment for a non-commented out part
3. start functions on the same line you end previous ones and make large breaks before function calls inside other functions:
  1. void /* = */ f(x) { // large piece of code in one line;
  2. void /* */ = g(x); // { large piece of code in one line;
  3. void /* */ = h(x); { large piece of code in one line; } /* ... ;*/ void t(x) { another piece of code
4. Make sure your output is different in its format from the one specified in the assignment. Then argue to the death that you still deserve points for correctness.
When all else fails, cheating is a very effective method of doing badly. Remember, cheating is insufficient if you don't get caught. There are many methods for ensuring you get caught, but I'll only list some of the more blatant ones.
1. After copying someone else's assignment, make sure you submit it immediately after they do. That way your assignment will be next to theirs, which increases the odds of the cheating getting caught.
2. Better yet, if you make a photocopy of another person's assignment, attach the photocopy to your own assignment before submitting it.
3. When copying verbatim from the text book without citation (this is plagiarism, in case you were not aware), it helps if the text is written in a distinctive style that will increase the likelihood of getting caught. It is better if you can persuade a dozen of so of your classmates to copy the exact same paragraphs, also without citation. That way the TA is sure to catch it, if for no other reason than reading the same thing so many times.
4. When programs are submitted electronically have someone email you their solution code, save the email, edit the comments identifying the original author, and submit the file as is. Nothing will get you caught more easily than a compile error complaining about invalid syntax in the e-mail header. This has the added bonus of identifying who you cheated off.
5. Copy the TA's own code. Try and ensure that the TA whose code you copy is the one that grades your assignment. This virtually guarantees that you will get caught (Yes, this, as with everything else in this list, has happened!)!

Paul A.S. Ward

Last modified: Thu Nov 3 16:07:53 EST 2005