Entries from January 1, 2009 - January 31, 2009
Unknown Quantity by John Derbyshire and Finding Moonshine by Marcus du Sautoy

Ten years ago I took a series of mathematics courses with the Open University (a distance-learning university based in the UK). I had always wanted to take my understanding of mathematics beyond what I had done at A-Level, and this seemed to be the best way to do it. I did much of the course work on the trains to and from my work. This was back in the bad old days when British trains were subject to frequent delays and cancellations. However, when my train was late I just used the time to do work that I would have otherwise had to do in the evening or at the weekend, so in a way, I turned the delays to my advantage.
One of my aims in taking these courses was to get a basic understanding of group theory, which I kept coming across in my reading. The Open University courses did cover group theory, but we ran through it rather quickly so that, although could answer questions on various parts of the subject, I didn't have any overall feel for how the parts fitted together. I wasn't until I read Unknown Quantity by John Derbyshire and Finding Moonshine by Marcus du Sautoy that my course notes started make sense to me.
Both books are rather similar in the area they cover and in the level at which they cover it: Unknown Quantity is a history of algebra in general, Finding Moonshine is a history of the more restricted field of group theory. Du Sautoy has the advantage over Derbyshire in that he is an actual practising group theorist (at least until recently) and he supplies some interesting insider details on the Cambridge University group theorists and John Horton Conway in particular. However, this advantage is counterbalanced a little by Du Sautoy's tendency to get diverted into the arty side of symmetry. Still, both books are excellent and I would heartily recommend both to anyone studying or intending to study algebra at university undergraduate level.
If Google did Archaeology...

A thought that came to me while watching Phil Harding knapping flint on television a few months back:
If Google did archaeology they would scan all of the stones and soil particles from an archaeological site, identify each fragment of flint and produce a 3D software model of it, and then use software to reconstruct the original lumps of flint, and the sequence in which the fragments were taken off.
How Not to Write Software User Documentation

There are few things that make my heart sink more than software user documentation that is just a description of the software's menu items and dialog boxes. When I go to user documention, I do not go to it in order to find out whether the File menu has an Open option, nor whether I can use the latter to select a the file I want to open. This sort of thing is obvious to almost everyone nowadays, and where it is not obvious it can be found by looking up and down the menus and at the dialog boxes themselves.
If you are a writer of software user documentation and you ever find yourself tempted to write user documentation like this, then I recommend that you first read the following words of advice taken from 'Read Me First, A Style Guide for the Computer Industry' (2nd Edition, published by Sun Microsystems Inc, 2003):
As a writer, you research, organize, and communicate information for the reader, who depends on you. In your relationship with the reader, you are the expert. Keep this point in mind when you make decisions about what information to present and how that information addresses the reader's questions.
Often a product provides several different ways to accomplish a single task. You might decide that you owe the reader an explanation of each method. However, remember that the reader is more interested in using the product than in understanding all options. Choose the best method for most of your audience, and tell the reader to use that method.
After you commit to the best course of action, you might explain to the reader that other methods exist. Tell the reader where to find your descriptions of those methods. Also tell the reader why and in what situations options A, B and C are useful.
(You will also be doing your readers a service if you tell them clearly when something is difficult, or impossible to do, rather than remaining silent and leaving them to find out for themselves.)
One of the most important contributions a writer makes is to anticipate the reader's questions and provide appropriate answers. A writer must anticipate questions about related topics as well and provide cross-references to where those questions are answered. As the subject matter expert, a writer can create a climate of understanding that is far more significant than merely recounting facts about the product.
See that? The job of a writer of software user documentation is to "create a climate of understanding", not just to recount a list of facts about the product!
Day Three as a Teaching Assistant

Not so much to report for my third day. I must be getting used to it. I did spend a couple of lessons sitting next to some boys who had reputations for disrupting classes. I talked with them about the work and how boring it must be to them, and various other things. The first one settled down and worked quite well. The other was worried that his friends might be laughing at him (I couldn't see that they were) and only did a little work, but at least he wasn't too disruptive. The rest of the lessons were less memorable for me, at least.
Well, the first three days haven't put me off my plan of becoming a teacher. We shall see what happens next week.