August 2010 Archives

Available on iTunes or OU Podcasts

The Open University has a huge number of short podcasts available and many are related to ancient history. Roman Funerary Monuments is part of their course on the classical world. The title accurately describes the content. There are 7 video podcasts in this series with a combined running time of roughly half an hour. All the videos are available in either iPod or a larger (640×360) format, with PDF transcripts. The visuals entirely consist of Roman funerary monuments in their modern state with documentary style narration. The necropolis at Isola Sacra features heavily.

Rather than focus on the monuments themselves, these podcasts use them to provide an insight into Roman culture. As the most common form of remnant surviving from Roman times, funerary monuments are a useful primary source. Epitaphs provide names (Roman names were very informative), ages, family relations and sometimes a short biography. Thus the dead could create a lasting image of themselves, emphasising the positive aspects of their life (in a Roman context) and omitting the negative. Freed slaves tended to take particular advantage of this, with their tombs being more extravagant than others of similar wealth. Funeral monuments also suggest that family relationships were important (especially among freed slaves, perhaps because as such relationships would have been limited under servitude). Roman law prohibited funeral monuments inside cities, so they were built alongside the roads leading out of the towns. Spots directly alongside the road being the prime location. Tombs also sought to catch the eye, and were designed to be visited. They often contained items to promote a longer stay such as art, furnishings, and in one case, a well.

This series is well worth a viewing.

Coder, programmer, software developer, IT engineer. Whatever it is called, my profession has changed the way I think. I started learning to program 23 years ago as a hobby, started studying it seriously 17 years ago and have been doing it as a job for 13 years. Now I seem to think a great deal straighter than I did before - straighter than when I was in my early twenties and studying postgrad logic. By thinking straight, I mean following a chain of logical rules to their conclusion - determining what they imply and where any gaps in the rules or strange corner cases exist. Straighter in that I can quickly work out the logical chain, identify problems, and ignore unimportant avenues of thought. I don't tend to take the scenic route anymore; I go straight to the destination.

This makes sense to me, most of my job as a programmer is thinking straight. Writing the code is very easy once the language is mastered. Instead, the job comes down to solving problems with code. At the start of a project this is done by precisely specifying the steps of the solution in code. No ambiguity is allowed and all the possible situations must be covered. Edge and corner cases will cause bugs, so must be considered. As the project progresses, any changes or additions must take into account interactions with the body of rules already encoded in the existing codebase. As the complexity of the system increases, so do the possible interactions and it gets harder to run through them. This is one of the reasons big systems tend to have so many problems and why experienced coders try to keep things as simple as they can.

It seems reasonable that I have trained myself this way. I have far more than the suggested 10,000 hours of practice. A back of the envelope calculation suggests I'm close to 50,000 hours. That much practice is bound to etch a groove in my thought process. Sometimes that groove is too easy to follow and I get lost in thought, monomaniacally thinking about a system. In software development this state is often sought out and is no bad thing, except in your interactions with other people. Sometimes I wonder if a similar process is at work in other professions, perhaps with less than ethical results.

I studied a Business degree mid career (so far). It hasn't been of huge career advantage to me, as I have learnt I am happiest just coding away. However, I did learn the basics of some other professions. There was a semester of accounting and another of contract law. In both courses the lecturers spent some time detailing how case law or accounting rules were applied - explaining that it wasn't intuitive and you just had to follow the general rules. What!? I found it quite simple to apply the rules and I achieved good marks with little effort. I just did the same thing I did every day, simply swapping lines of code for case law.

My impression is that both law and accounting use similar thought processes to programming - applying rules to reach a desired end state. While programming uses exact statements of software logic; law and accounting use the written language in laws, cases or standards. This natural language is more malleable and open to interpretation. I sometimes wonder if people in other professions get similarly lost in their rules. Focussing on just beating the problem as presented to the exclusion of other concerns. This could offer a generous excuse for the motivation behind results like tax evasion, or dodgy financial products.

I was looking to learn how to write a non-blocking IO server in Java, but couldn't find one that suited my needs online. I found this example, but it didn't handle my situation. There is also Apache MINA, but it was a little complex for my simple needs. So armed with these examples and a couple of tutorials (here and here), I created my own.