How to answer a programming question

In my courses, I usually have a page of questions online, like these:

Somewhat to my surprise, many students don’t know how to answer a programming question. So here are Jamie’s Simple Steps to Answering a Programming Languages Question:

  1. Use an obscure file format
    WordPerfect is good, a .tiff file embedded in a spreadsheet is better, or best of all convert your answer to a .gpx course file. At all costs avoid simple, portable solutions such as .txt or .odt.
  2. Never cut-and-paste question number and text above your answer.
    Your marker can infer what question you are answering, probably by viewing the question sheet on a second computer which he or she will purchase specially to commemorate the honour of marking your work.
  3. Omit name, student ID, e-mail, or any other identifying marks.
    Call your file “questions.gpx”, or better still just “q”. Send from an anonymous e-mail account, or at least, from a non-university account with a suggestive identification such as “mangaLover” or, for that classic touch, “n00b”.
  4. Do questions in random order.
  5. Don’t check your answers for syntax errors, especially obvious ones, or try to compile them to see if they will actually run.
    If your compiler cannot parse your code then it is unworthy.
  6. If a question asks you to write a function called foo, rename it
    … to one or me or kermit or perhaps something in Thai script. You know better.
  7. Where possible, overwrite core system names. For instance: a function that adds two numbers could be called unit or int or map or and, or for that classic touch, if, then or else. If you lack the imagination to invent new names for your functions or to reuse old ones, then call all your functions tuple or stuff. On no account use a systematic naming scheme, such as giving the function in the answer to Question A part 1 the name A1.
  8. Never comment on or explain your answer.
    Your genius speaks for itself. (I even shouldn’t have to say that.)
  9. Test cases are for wimps.
    If you must test (for instance if the cowardly question insists on it) then neglect corner cases such as 0, a, z, fn x => x, or the empty list [].
    Users who run your program on corner cases deserve what they get, whatever that may be.
  10. Never comment, indent, or annotate your code.
    Code should be written on one long line without linebreaks and with minimal spaces, preferably in Comic Sans 8pt.
  11. Constants, variables and functions should have unsuggestive — or better still, misleading — names.
    For instance, a program to calculate the total of a list should be called average (true story). ASCII codes should always be given as unelaborated raw numbers, in binary if possible or, if you’re feeling cheerful, in octal.
  12. File suffixes (the kind that help a browser to implement one-click preview) are also for wimps.
    If your lecturer can’t be bothered to download your file, open it with a binary editor, figure out what file format you were using, rename the file accordingly, open it locally with a compatible editor, mark it, reupload it … and then repeat this cycle for all 85 students on the course, then he is not worthy to read your work.
Back