How to ask your teacher a question

One of the major problems that teachers encounter, especially at University, is dealing with badly formulated questions from students. Some questions are almost impossible to answer sensibly and that's often because the goals of students and their teachers are quite different. Frequently the student has the goal I want to pass the next assessment whereas the teach has the goal I want my students to fully understand what I'm teaching them. These aren't the same thing. The former goal can be met just by learning a bunch of facts and examples and developing a bit of exam technique. The latter requires deep thought and sustained interest, but usually leads to better results in assessments and later life. There's a reason why your teachers want you to understand your subject and not just pass the exam -- they want you to better enjoy what your learning, be better prepared for upcoming work and be more successful in your degree and later life.

If you are a student, it's as well to consider how you can ask a good question to get better value from the time you spend in class. Here's a quick guide to doing that, which I hope you'll find helpful.

Remember that you can do your homework
Not only are homework questions set to help you learn, they are specifically devised to help you gain a sense of confidence about your own ability to master your subject and pass the assessment. No question is "impossible" although many will require real thought and creativity on your part. Many students come from school where they were shown techniques (like, "how to write an essay" or "how to prove a theorem by induction") then asked to practice those techniques. Often, homework questions were essentially the same as examples the teacher had described. At University there is a much bigger jump between what you see in lectures and text books and what you are asked to do for homework. You are expected to apply what you've learned in new situations and that leap of creativity will become more demanding as your degree progresses. However, no teacher sets an impossible question. You can do the work you've been set and really you just need to work hard and be persistent to do well.

Understand what the goal is
If you're stuck with a homework question then you need to know what that question is intended to teach you. Usually homework questions relate directly to the learning outcomes of the lectures they go with. Usually they are graded so that they get harder as you go along. Lecturers set questions with the intention that anyone who has completed them all will have understood everything that has been taught and be ready for any assessment on the subject. Homework questions aren't random and they aren't intended to catch you out or give you a hard time. They are set to help you understand your subject better. So, when you're stuck with your homework the first thing you need to ask yourself is "What is this question supposed to teach me?". That should give you a hint about what your lecturer is looking for and where in your notes or reference material you can look for more information.

Read around the subject
At University you are reading for a degree. You need to be aware of the major prior art in your area of study -- that is, you need to have read about the research that other people have done. Read your lecture notes, read text books, read Wikipedia, use Google. Read widely and take notes. Most of what you might be "stuck" on or finding "difficult" has been written about ad nauseum. Read up and you probably won't have to ask your teachers half as much as you thought.

If that sounds like far too much work then remember that you need to be smart about how you read. Art students are usually very good at this -- many of them need to write an essay a week and read at least ten books for each essay. That's at least three hundred books a year. How on earth do they manage it? Well, they don't (despite what you might think) read books all the way through and they don't feel guilty about the parts they've "missed". This came as quite a revelation to me (D'OH!) but it's an essential academic skill and one that doesn't seem to come naturally to science students. The trick is to be directed when you read. Have a goal and read only those parts of the book / website / ... that are necessary to achieve your goal. Try not to get lost in interesting stuff along the way -- if you see something that intrigueues you, just make a note of it and come back later. If you're using RTM then add it to your Read/Review list.

For example, you might be stuck learning about "Turing Machines". A good place to start would be to answer the question "What is a Turing Machine?". Read up on what a Turing Machine is until you can give a clear and succinct answer (then write it down for your revision notes). Next you might want to get a little more detailed and specific and ask yourself other questions. "What can a Turing Machine compute?", "What other machines and languages are equivalent to Turing Machines?", and so on. By the time you've finished you should have a very clear picture of what Turing Machines are all about. If you don't and you still think you need help from a teacher, then you should have a clearer idea of exactly what you don't understand. That should at least help you to ask a more specific and directed question.

Have a go first
If you go to your teacher and say "I can't do this homework question" don't expect your teacher to just give you the answer. Remember, the questions are there to help you learn, they aren't just meaningless hoops to jump though. If you do take this approach, expect your teacher to teach you something about the subject matter and maybe to lead you gently towards answering the question yourself, rather than just giving a straight answer. This should help you reach your "learning outcomes" and to think more independently about the work you are doing.

Better than just saying you "can't" do the question have a go at it and see how far you get. Even if you don't get very far at all your teacher will see how you're approaching the work and that will give him or her a much better idea of where you might be stuck and what you haven't understood. That way, your teacher can help you learn specifically what you need to know, rather than just hoping that at some point during your discussion you'll figure out whatever it is you misunderstood.

Be specific
To get good value from your teachers you need to be clear about what it is you need help with. A vague question like "What is object oriented programming?" or "What is epistemology?" isn't really going to get you very far. Questions like that really require whole books to be written to answer them. Be clear and specific about where you're confused. Do you know what an object is? Are you aware of any philosophies of knowledge? Start with the very basics and figure out the jargon or concept that confuses you and ask about that. If you're so confused that you really don't know what you don't know then go back to your lecture notes or syllabus. You should have a list of "learning outcomes" or something that tells you what you should be learning. Go through each of these and work out which ones you do and don't understand. Then read your lecture notes and reference material and see if you can figure it out for yourself. If not, then ask, but ask something specific. Not "What is object oriented programming?" but "What is a class?" ... Not "What is epistemology?" but "What did Russell mean by knowledge by description?" ... Be clear about what you don't know.

Fractal curves in Python

We've set our first year students the task of drawing some fractal curves in Python with the fantastic turtle module. Apparently the Dragon curve is a pain, so here's an alternative starting point for anyone getting stuck: the Torn Square curve. I've included shots of part of the curve after one and two recursive calls; just to give an idea of how the shape is constructed.

Object virgin?

Recently, I have mostly been writing up some lecture notes on objects and classes. Now, an object is really just a bunch of data and some operations to manipulate that data. So, lists and operations to add and remove elements from them, whatever.

So, how to explain that to first year programmers? Well, I suggest not by introducing a "Pizza making robot" or a "Person" object. These are not entities which easily reduce to the "data and operations on it" model. I don't know what a person is, but I'm sure it's not just a collection of data and algorithms, even in a very abstract sense. As John says, a Person object really ought to have methods called "respire()" and "excrete()", but the ones in text books usually just have lame things like "get_age()".

In the end, students seem to respond better to programmatic examples (even if they are quite abstract) than really fake examples that are supposed to be "relevant" to them. Better to give them a PrintServer than a Person.

How to pass your final year thesis project

I've been thinking for a while that it would be good to distill some of the advice that colleagues and I give to students doing final year thesis project, so here it is -- enjoy!

Think of yourself as an academic.

Whatever you want to do when you leave University, your work will be written for academics and marked by them. A thesis project is like a small research project and to get the best marks available you should run your project with that in mind. So, you need to perform a thorough literature survey, follow a sound methodology, critically analyse your results and so on.

Have a hypothesis (or a thesis statement or a research question).

A lot of students approach their projects by saying "I want to do this", like "I want to invent a Foo, written in VB". This is not the best way to get good marks. Your project needs to have some sort of clear purpose and in the academic world it's best to state that purpose as a hypothesis, thesis statement or research question. These three are really just different ways of stating the same thing and which you choose is just a matter of taste. So, if your project is a study on the ratio of smokers which develop cancer (e.g. "I want to do some statistical analysis on smoking") then you might phrase that in one of these ways:

• Smoking is correlated with cancer -- hypothesis
  
• Smoking is correlated with cancer -- thesis statement
  
• Is smoking correlated with cancer? -- research question
  

Or, perhaps you want to design a new GUI widget to replace list boxes:

• Users will find WidgetFoo easier to use than ListBoxes -- hypothesis
• Users will find WidgetFoo easier to use than ListBoxes -- thesis statement
• Is WidgetFoo easier to use than a ListBox? -- research question

Part of the point of phrasing your work like this is that it should change the way you think about the work. You now have a very clear goal to reach -- to prove your hypothesis / thesis statement or to answer your research question. Everything you do in your project should now be directed towards this one goal.

Also, you have reduced your risk of failure. What if WidgetFoo turns out to be rubbish? Well, then you have still answered the research question or disproved the hypothesis -- you've got a result. In your write-up you can probably say a lot about why WidgetFoo wasn't as good as you thought, how you achieved your results and how other researchers can use your work to invent even better widgets.

Produce something useful to others.

So, you've got a hypothesis to answer. Great. But your teachers will still want to be convinced that the hypothesis you've chosen is worth six months of your time and lots of hours of their time. How do you know if your work is useful? Firstly, make sure you've read the relevant literature. Use Google, go to the library, talk to potential users. There should be a group of people in the world who have a clear reason to be interested in what you're doing. That might be a section of the research community, a user group, a company, whoever -- but there must be someone who wants your hypothesis validated or disproved. You should convince whoever's marking your thesis that this group of people exists by explaining in your thesis what the current literature says about the area you are working in and how your work contributes to this area.

Do something (a bit) novel.

You're not expected to win a Nobel Prize on the back of your undergraduate work. However, there's no point in doing something that everyone has done a million times before. The worst example of this in Computer Science is a project which is basically "I'm going to write a website with a database". Usually the website is for a friend or relative and the database keeps track of users. There's nothing wrong with that if there's some real novelty in it (e.g. you've just invented a new sort of database and this is a demonstrator for it). But often this is something that most first years could complete for a coursework (so, it isn't stretching you) there are simple, free tools that can do the job for you (it's not novel) and the user is bogus (noone's interested in it). Choose wisely!

Have clear success / failure criteria.

This should be taken care of when you write your hypothesis (or thesis statement or research question). However, it's important to know what will constitute a "successful" project for you. What results do you want to end up with? Once you know that, you can choose the appropriate methods to use in your work (e.g. will you be running a focus group? Writing a questionnaire? Writing some programs -- and testing them somehow?). You can also think about reducing the risks in your project. What if you don't finish part of your work on time? Is there some catch-up time in your schedule? What if early tests go badly? Is there time to repeat them?

Don't change the world.

Don't choose a project which is just far too big. If you're going to invent a new computer, writing an OS from scratch and a windowing environment for it is not a one-person, six-month, part-time job. Keep it small and give yourself some scope for extending the project if it goes better than you thought.

Even if you've chosen something small with a clear hypothesis, once you've written out a project schedule it will still feel like far too much to do. You will feel overwhelmed. The trick to reducing your fear early on (and making sure you work to schedule) is to break down your work into small tasks. Each task should have it's own goal and deliverables with it's own success criteria and a deadline. So, if your hypothesis is "WidgetFoo is easier to use than ListBoxes", your sub-goals might be:

• Produce a literature survey on list widgets.
  
• Write comprehensive unit tests for WidgetFoo in the Gtk widget set.
  
• Implement a WidgetFoo in the Gtk widget set.
• Debug (goal is to pass all unit tests).
• Devise usability experiments (deliverable: methodology document).
• Write application software for testing in the experiments.
• Perform experiments.
• Analyse data.
• Write-up thesis.

Note that these tasks are dependent on one another. WidgetFoo cannot be written before you know how to test it. The experiments cannot be run until you have designed them and decided how to analyse the data they will produce.

Your new list will make life a lot easier, but you will probably still feel that it's too much to handle. To feel better about your work and motivate yourself, it's a good idea to take each of your sub-goals and write out the next physical action you need to perform to carry out that task. So, for the literature survey the next action might be "Google for 'list widget'". For the unit testing your next action might be "Find documentation about the UnitFoo testing framework". And so on. Most people find action lists much more motivating than task lists. Scroll down to see more stuff on productivity and where to keep your lists!

Choose a project that will maintain your interest.

Six months is a long time. If you choose a boring project (maybe you think it'll be "easy") then you'll quickly lose interest, get bored, stop working and possibly fail. In some ways, it's good to choose a project with a lot of scope (so you can change direction a bit and still address your hypothesis) in an active area of research (so there's lots of work to build on). On the other hand, some people would find that sort of project unfocused and confusing.

When you plan your project, think hard about what motivates you. Is it reaching towards a really interesting goal, or the fear of failing really badly? Either way (or both) you need to keep that motivation in mind whenever you're working. So, choose something interesting to do, give yourself at least a little scope for changing the details of the project over the year and keep in mind why you want to succeed (or not fail!).

Don't be too dependent on clients.

If you have a client to work for, especially one from industry, be careful about how you plan your project. If you are expecting resources from your client what will you do if they don't turn up on time? If you want the client to test your work, what do you do if they get a major order in when you're ready to test and noone has the time to help you out? What if the client goes out of business? What if you have to sign a non-disclosure agreement -- can the University still mark your work?

Having a "real" industrial client can be a big bonus. For one thing it's very easy to say that someone is really interested in what you're doing for the project. However, you need to make sure that if the client pulls out or doesn't cooperate you'll still have a viable project. Plan well and you won't have any problems.

Understand that research is not reading and a thesis is not a report.

Most undergraduates (at least in Computer Science) seem to be pretty confused about what research really is. It certainly isn't about using Google or reading in the library. Research means adding something new to the body of knowledge on a particular subject. This is why it's so important to know what work has already been done (so you know your work is novel), to have a clear hypothesis (so you know what new understanding you're adding) and to write up your work well (so other researchers can use it).

Also, understand the place of your thesis. You are not writing a report which tells people what you did. You are writing a thesis which tells people about the research you have done. This can be structured in whatever sensible way you prefer, but it needs to have the following parts:

• An introduction. What's your hypothesis? Why is your work interesting? What are your trying to achieve?
• A literature survey. What have other people done? What new knowledge will your work add? What is the current state of the art missing and how are you going to address that?
• Your methodology. How did you go about validating / disproving your hypothesis? Why is your method sound? Why should anyone trust your results?
• Your results. What did you do? How?
  
• Your analysis of your results. What do your results mean? Why are they interesting? Did you validate your hypothesis or disprove it?
• Conclusions. What did your work contribute and how could it be continued by others?
  

Eat well, sleep well, get some exercise and take a day off every week.

Basically, look after yourself. To work productively you need to be in good physical and mental condition. If you feel ill or your not coping well with life, slow down a bit and take a break. Don't eat junk food all the time or you'll feel sleepy and miserable. Cut down on caffeine and alcohol or you'll get stressed and sleep badly. Sleep a sensible number of hours every night -- consistency is important. Get some exercise because you need endorphins to keep you happy and some oxygen getting to your brain. Omega-3 and the sorts of minerals that aren't found in hot dogs will keep your brain working sensibly.

Most of all, take a whole day off University work every single week. It doesn't matter what you do with that day (have fun, earn money, write a novel, whatever) but working every day will limit your creativity massively. Most very creative (and productive) people find that their best ideas come after a day off. This gives your mind a chance to consolidate all the material you have learned, synthesise it and solve some of the problems you've been considering. In fact, to revise for an exam or solve an interesting problem, it's a good idea to spend a few days working really hard at reading everything you need to know and taking notes, then take a day off directly before the exam or the day before you're going to write the solution to your problem. This will give you the best chance to properly understand everything you're working and be creative about it.

Be productive but don't spend time on productivity.

You need to organise yourself well, which is a difficult problem in itself. However, if you spend even five per cent of your time on productivity management (e.g. using Microsoft Project!) then that is far, far too much and a massive waste of your most important resource -- your time.

Good productivity strategies are effortless, effective and fun to use -- and take almost no time at all. I can recommend David Allen's Getting Things Done strategy and RememberTheMilk for managing lists of action items.

One thing you can do to really give yourself a head-start in the workplace is to estimate how much time it'll take you to do every single task in your project. You'll start out finding that your estimates are stupidly far out, but as your project progresses you'll get better and better at correctly estimating your tasks. Joel Spolsky has a nice essay on how to do this simply, which you can use with RememberTheMilk.

Vote for this article on reddit.com!

Python and stuff

Lately, I have been messing with the Python compiler module. It's a *very* nice interface, as far as OO things go and definately my second choice to SML.

On the teaching front, it seems that Adam is also blogging. No complaints about my lectures so far, but then I didn't check the archives...

Computer magic

One of my colleagues often says that beginning CS students seem to think that computers work by magic. They sit in lectures and watch an experienced magician recite incantations, then go to the lab and type those incantations in for themselves. Understanding the incantations seems a bit optional. After all, this is magic -- who knows what could happen to the person that stares into the heart of it.

So, it is with some alarm that I'm observing my own use of the machines. My laptop is currently going bonkers and periodically refuses to boot. My incantation for solving this problem is to maniacally move the mouse during bootup. This might seem insane (and possibly is) but the hang-on-boot always happens when the message "Starting system message bus" appears and every time I've been moving the mouse in my paranoid way, the machine struggles a bit but finally manages to boot. When I forget the magical incantation I find myself looking round to see that I missed the error message and the laptop needs a hard reset. I can't decide whether these experiences consitute anything remotely falsifiable or not. Perhaps if I move the mouse without feeling paranoid I'd get a different result? What if someone else moved the mouse? Would they have the special spidey-powers to make it work? Who knows.

James points out that this particular incantation is due to a set of experiences that many people our age have suffered: using Windows 3.1. That damn thing really would just spuriously hang and moving the mouse at least gave you a clue as to when a reset was needed. The upshot is that a whole generation of us that wiggle the mouse whenever a web page takes a while to load.

Tempting, then, to base the course notes we're currently writing on a sub-natural understanding of how machines work. We could trade in our LaTeX times for something far more archaic and ask the Uni printers to use parchment for a change. Perhaps we could, at last, entice the Harry Potter generation to Uni and end the current down-turn in CS majors.

Chunking up and down

As I was eating museli this morning, it dawned on me that the failure of Objects First teaching is all to do with chunk size. Most students seem to think better in small chunk sizes during the learning process, then chunk up when they've gained competency. Objects require big-chunk thinking, because you need to be able to abstract over smaller chunks of information to think clearly about the structure of your programs. Beth Adelson did some fascinating work which showed that in programming, "experts" have much bigger chunk sizes than "learners". This bears out in the classroom too. The most common question I get asked by students who struggle with programming basically amounts to "what line of code do I write next". This tells me that they haven't chunked-up to thinking about algorithmic structure, so I know they won't cope well with object structures.

Objects-First expects students who cannot chunk large to do so, and it's no wonder they get so confused! My intuition on this is that OO-First will soon fade out pretty soon as a pedagogical fashion and Python will help enormously. In Python you can choose no program structure, functions, objects, whatever you want, so teachers aren't constrained to an OO-First approach. Unlike Java, an un-structured program needn't jump through hoops to print a word to the screen, so students have the benefit of being able to learn one chunk at a time.

Functional programming in Python

I was dismayed to read about Guido wanting to remove lambda, reduce, map and filter from Python. Although Guido's point about list comprehensions (and indeed the shocking complexity of some "fold" style transformations) is sensible, I'm not convinced that reducing the nice mixture of functional / imperative / OO is the best way to go. I mean, people can write spaghetti code in any paradigm, that doesn't mean we should abolish nested loops or multiple inheritance, right?

It was disappointing to read that Guido things that arithmetic is where functional style stuff is used most (well, I'm paraphrasing a bit there). While this might be true for reduce (or not, I dunno), it certainly isn't true for the rest. String munging and simple parsing is a good example of where the functional style can be very elegant. For example, the following takes a type declaration of the form "int, int, int -> int" and returns a list of the constituent types (e.g. ['int', 'int', 'int', 'int']). Of course, you could do this with loops, or regexps, or a lexer generator (!), or whatever, but the functional style is just so damn nice to look at:

def parse_types(s):
  import string
  def rem_arrow(s):
    return filter((lambda x: not(x == "->")), s)
  def strip_commas(s):
    return map((lambda x: rstrip(x, ',')), s)
  return rem_arrow(strip_commas(string.split(s)))

Note, that I could have used a bunch more lambdas here, but explicit def's are more readable. Whilst Guido complains about over-use of lambda, this is a matter of good style.

Bob tells me that someone once said (Abramsky?) that good language design should make anything semantically undesirable syntactically impossible. Here, Guido is trying to make bad stylistic decisions syntactically impossible, which I guess is the opposite view to Perls many ways to do everything and all of them unreadable. I have some sympathy with Guido's view, but can't help feeling pretty heartbroken about the idea of losing lambda.

Oh, and I'm not (nor have ever been) a Lisp or Scheme hacker.

Python for introductory programming

It's been a seriously deficient amount of time since I last blogged; although James has been keeping up better and has even posted his excellent noise.

Like James I've been thinking a lot about the new Creative Computing course, which is one of the most exciting teaching-related things going on at the moment. Python will, of course, rule as an introductory language, and one of the nice things about it is how easy it makes "difficult" tasks. At the moment I've really fallen for the turtle module, which implements Papert-style turtle graphics -- something I've been meaning to hack onto Java for ages, and never got around to. In particular, turtle.py provides both an imperative and OO interfaces, making it ideal for leading students through different stages of the curriculum. Of course, it's also great for all sorts of things like recursion (think von Koch curve).

Looking through the available text books, there's some great Libre material, including the excellent Dive Into Python (for experienced programmers). One dissappointing aspect of many books I've seen is a lack of examples. Many texts seem to introduce one major concept per chapter, each with one long worked example. To my feable mind that's just not enough and (to quote someone clever) there should be more than one way to do everything, and that should be made clear to students. After all, flexibility of thought is, I reckon, one of the major attributes of a good programmer and it can only be taught by endless exposure to different styles and techniques. Python is also nice for this; it has great facilities for pure functional programming along with fantasticly nice syntactic suger for all the major imperative structures. What could be better for beginners?

Rotting your brain...

I'd forgotten all about this, but John reminded me that email rots your brain, dropping as many as 10 IQ points. Ouch!