#if DEBUG
// do some special code
#endif
Unity3D has a similar system. Mostly the docs (available here) seem to suggest this is for specialist code for different platforms: iPhone, Web, PC, etc. Thus the defined parameters are set in advance (e.g. UNITY_IPHONE). However, there is one that is useful for debugging, UNITY_EDITOR. This will only be set if the application is running inside the Unity3D GUI. Once you build the app those lines of code will be skipped. It can be used like the below example - very handy.
#if UNITY_EDITOR
Debug.Log("Debugging");
#endif
According to this Unity3D forum post it is also possible to define your own project specific preprocessor parameters.
]]>SharpUnit works like a standard unit testing framework for C# code in Unity3D (although all output goes to the console, but that is fine for me). Although my work has largely been in UnityScript (Unity3D's JavaScript like language) and this didn't work so well due to issues with compilation order and SharpUnit's use of .Net custom attributes. After making the changes below, I found SharpUnit works well, and I'll probably be using it for my unit testing.
Unity3D compiles scripts in a set order (as described here). Thus if you have C# code that references a UnityScript class there can be a problem - although the reverse is not such an issue. When testing UnityScript with SharpUnit this means that the C# Unity3D_TestRunner class can be an issue. It references the TestCase classes, which I want to write in UnityScript. To do this I put the SharpUnit code in a folder under the Plugins top-level folder (the Standard Assets folder would have also worked). This means the SharpUnit code is compiled first. Then my tests went in a new folder together with a UnityScript rewrite of Unity3D_TestRunner, as shown below. This UnityScript TestRunner script is then attached to the TestRunner GameObject (in a special testing scene) rather than the C# version as described in the SharpUnit instructions.
#pragma strict
import SharpUnit;
function Start () {
var suite: TestSuite = new TestSuite();
suite.AddAll(DummyTest());
var res: TestResult = suite.Run(null);
var reporter: Unity3D_TestReporter = new Unity3D_TestReporter();
reporter.LogResults(res);
}
Other possible solutions to this problem would be to just write my code in C# or to change SharpUnit to load TestCase classes dynamically at runtime. Rewriting the TestRunner seemed easiest.
The other problem encountered is that SharpUnit uses the C# custom attribute [UnitTest] to identify its test methods. The equivalent in UnityScript is a script directive (see the relevant section here). Thus @UnitTest needs to be placed at the top of each test function.
After that change I could run UnityScript tests with SharpUnit. An example test is below:
#pragma strict
import SharpUnit;
class DummyTest extends TestCase {
var dummy: String;
/** Setup test resources, called before each test. */
function SetUp() {
dummy = "lkjkjh";
}
/** Dispose of test resources, called after each test */
function TearDown() {
dummy = null;
}
/** Sample test that passes */
@UnitTest
function TestDummy_Pass() {
Assert.NotNull(dummy);
}
/** Sample test that fails. */
@UnitTest
function TestDummy_Fail() {
Assert.Null(dummy);
}
}
The format of the course was alternating sessions of lessons on management with physical tasks. The physical tasks were set up so that during the first session the least experienced member of each team would lead it, and the last practical was led by the most experienced.
The course started with a task, thus I started as a team leader. The idea was that the whole team would be blindfolded and led into the bush. There we would be handed a rope and we had to form it into a square. As team leader I was allowed to remove my blindfold if I wished, but then I wouldn't be allowed to move or touch the rope. I kept the blindfold on. Everyone else had to stay blind regardless. It didn't go very well - neither team completed the task. My team's square was more like a rounded triangle. However, the other team's square wasn't much better, although it was definitely more square-like.
Then we all gathered to analyse the team leader's performance. I just remember getting a bollocking. There were loads of problems. Mostly they revolved around me not communicating enough, so my team wasn't sure what they were supposed to be doing. In traditional consultant fashion, the facilitator ensured we finished with a positive. Apparently staying blindfolded was a good thing to do in Australian groups as it helped keep the leader as part of the group. Among other nationalities removing the blindfold was preferred.
Then points were allocated to the teams. Neither team completed the task so we both only got partial points. We were in competition with eachother!
Then followed various sessions. The management sessions were basic theory combined with information on Rio Tinto. We learnt about the different business units in the company and how to get promoted (act as if you were already at the promoted level). We were also told that there were no more than 7 levels of management. True enough, I worked out that my boss's boss's boss's boss's boss was the CEO.
The physical tasks were fun. The team leaders were keen to impress the General Manager and organised everything. The rest of the team just ran around in the bush trying to win the exercise. At the end of the day we were fed well. Although we had to share bedrooms and my room-mate snored - I slept in the hall and wasn't well rested.
Then started the infamous second day. The teams' scores were close with a single task left. Whichever team won it would win the whole event. The aim was to build a raft to cross a small lake (about 15-20 metres across), collect some widgets from the other side and then bring them back. Points were awarded for each widget returned and there was one widget worth of points separating the teams. The difficulty was increased by the rule that people getting wet were "dead" so couldn't participate further in the task, and that only one widget could be transported on the raft at a time.
I actually suggested that the teams collaborate to build a big raft and bring back all the widgets together. That idea went down like a lead balloon. Having been outed as a naive hippy pacifist, my team sidelined me for the rest of their war planning. Our plan was to quickly build a raft and tie a rope to it. One person would then paddle across the other side and put a widget on the raft and stay on the other side while the team pulled the raft back. This would then be repeated, but the second person would come back with the raft on the return journey. The other team had basically the same plan.
Our raft was completed first. Hastily built from barrels, some wooden planks and rope - it didn't look very stable. Sure enough, the first team member who tried to row it got a couple of stokes before toppling over. The raft was quickly pulled back, but the paddle was left floating in the lake. With one team member "dead" another rower had to be found. I swear all my team mates swivelled to look at me simultaneously. As I didn't have a paddle, I had to use my hands to move the raft (the facilitator ruled that was ok). To improve stability I got myself as close to the water as possible, basically laying down on the raft. I then flapped my hands in the water from the wrists only (no arm movement) to propel myself to the paddle. Even in this position the raft felt very wobbly. One positive was the other team slowed down a bit as they laughed at my "duckling" impression.
After was seemed like ages, I reached the paddle and then crossed to the other side about the same time the other team launched their much more stable raft. From that point on I was largely an observer of the action. The other team soon followed us to the other side. We had a head start, but they were gaining fast due to a better raft. After a few back and forth journeys, the teams had an equal number of widgets. It was down to the last one. I think we just had it (the other team lost one after it got wet). As our raft started its return journey, both teams clustered on the far shore. Our team to shepherd the widget to where it would be scored. The other team to see if they could steal it.
As the raft arrived a scrum developed. Or at least that is how it appeared from my side of the lake. There were a half dozen people heatedly wrestling and a few more on the edges throwing buckets of water (which were ignored). The rules were forgotten and the widget didn't survive (it was made of paper and soon crushed). Eventually it all calmed down and embarrassment ensued. The task was declared a draw and the other team won, although there wasn't much celebration. A grand melee over paper widgets is not a good look in front of the General Manager.
When we got back to the office we all spent nearly a day filling in health and safety reports. Many violation of the rules were detailed. There were numerous bruises, a bad case of rope burn and a few dunkings in the lake. It must have made for strange reading for those not present ("so your work colleague tackled you to the ground, got you in an arm lock and then stole a piece of paper from you"). Luckily, there was video of the whole thing! There was much merriment from the non-participating colleagues at an office showing. There wasn't a Rambo course held the next year.
]]>A recent experiment of mine failed. I am writing a game with an online component and wanted the same code running on both the client and server - as this would reduce the chance of bugs. For ease of development Unity3D is being used for the client end, so the code there is either Javascript or C#. I have been writing Java servers professionally for years so it seemed silly not to use that knowledge. Clearly there is no common ground there. However, there is a project called Rhino to allow Javascript to run inside the Java JVM.
So can Javascript from Unity run in a Java environment? The short answer is "no", but the longer answer is "sometimes, with many caveats".
Firstly it is possible to run Javascript functions in Java. Load up the Rhino library into the classpath and if you have Javascript code like:
function square(i) {
return i*i;
}
Context cx = Context.enter();
Scriptable scope = cx.initStandardObjects();
Function f1 = cx.compileFunction(scope, readFile("src/test_fn.js"), "<cmd>", 1, null);
System.out.println(f1.call(cx, scope, f1, new Object[] {5}));
Many people say that Javascript in Unity should more accurately be referred to as UnityScript. I think that is definitely true. Although it looks like Javascript there are some fundamental changes. Most importantly, Javascript uses a prototype-based scheme to define classes. UnityScript has an inheritance model, and the two schemes are not compatible. To me these differences are enough to prevent want I wanted to achieve.
]]>Four of my old teams were shutdown with near total loss of code. Another two years were spent at a consulting firm where most of the clients I serviced no longer exist. Those 5 jobs combined mean that half of my working life's production is largely gone. At a guess I would say 10% of the code from my first five working years is still used; around 30% from the second five years; and, over two-thirds of the last 5 years of my code is currently running. My professional code appears to have a half-life of around 4 years. This sounds about right considering the rate of technology change.
]]>
If the line was intersecting an object in the scene then this could be easily achieved with Unity3D's built in functions. In this case by casting a ray from the camera and finding the objects it hits (see the Raycast help page). However, my prototype is set in space, there is no object there to hit other than a small spaceship.
First, let's work out the equation of the line from the camera (point 'c') and the mouse click (point 'm'). We can get the position of the camera with var c = camera.transform.position and the position of the mouse click with:var s = camera.ScreenToWorldPoint(Vector3(Input.mousePosition.x, Input.mousePosition.y, 100.0));
[c.x + (m.x - c.x) * t, c.y + (m.y - c.y) * t, c.z + (m.z - c.z) * t]
y = spaceship.y
spaceship.y = c.y + (m.y - c.y) * t
if (m.y == c.y) {
t = 0; // no intersection
} else {
t = (spaceship.y - c.y) / (m.y - c.y);
}
This is a series of talks and interviews from the La Trobe University Archaeology department. The topics vary wildly, from the traditional Ancient Egypt and Cyprus, to relatively modern digs in Melbourne city (founded in 1835). As the series is archaeologically focussed there is more emphasis on the extraction and identification of objects than history. At present there are 12 episodes - 2 are short videos (around 3 minutes) and the remainder are audio only. Two of the audio podcasts are hour long scholarly presentations, while the other 8 are interviews of between 15 to 20 minutes duration. There may be more episodes in the series as the entries so far have trickled in over the last 2 years. Production quality is high for the whole series.
There are two podcasts on archaeology in Oceania, particularly Hawaii. One is an academic presentation, while the other is an interview with the same presenter on the same topic. There is some talk on Jared Diamond's Collapse book. Diamond suggests that society on the Polynesian island Mangareva due to overforestation. However, the presenter's research suggests instead that the deforestation was caused by a lack of phosphorus in the soil due to the killing of sea birds. The discussion of Hawaii is similarly focussed on the affect of intensive cultivation on soil quality. Unsurprisingly the indigenous people started agriculture on the best land and as population grew, expanded out to less productive land. Once all arable areas were cultivated, the land became more subdivided and population growth slowed. Also there is evidence of political consolidation beginning around the same time.
Another paired presentation and interview discuss excavations at the ancient Egyptian capital Amarna. They are focussed on the industry of the time - in particular small metal work and glazed pottery. Details of the materials used are probed with synchrotrons and a bit of experimental archaeology is conducted to determine the techniques used to manufacture them.
Another episode details the search for ships lost in Vietnam by the Chinese emperor Kublai Khan at the Battle of Bach Dang. Three episodes (including both video podcasts) discuss the tools and evolution of early humans, especially the position in the evolutionary tree of some complete skeletons recently found in Sediba. There is also an interview about bronze age burials in Cyprus and other podcasts focus on the archaeological difficulties and discoveries underwater or in cities.
]]>I often find myself writing time-based caches. Something like storing the last X hours of ticks from a data feed. Most teams I join usually have a utility class to help with such tasks. In a recent move I joined a team that didn't have such a utility, but did have a need for such a cache. Before coding, I thought I do a quick check to see if anything new had come along to help. At this point I discovered the Java 6 NavigableMap interface.
NavigableMap defines a type of sorted map with handy methods for obtaining submaps. So to get a map of the entries greater than a particular value use the tailMap method. The corresponding method for the submap less than a value is headMap. These methods return a view on the original map. So changes to the submap are reflected in the original map. The JDK provides concurrent and non-concurrent implementations of the interface.
This is very useful for a time-based cache. Create a NavigableMap sorted on the time (I used the epoch milliseconds returned by System.currentTimeMillis()) then tailMap returns the entries younger than a given time, and headMap those older. So to trim the cache of entries older than a certain time use headMap(System.currentTimeMillis() - maxAge).clear(). So easy!
Here is a complete time-based cache class for use as an example.
public class TimeSeriesCache<V> {
private static final int MILLIS_IN_MINUTE = 60 * 1000;
private static final int CLEAR_OLD_PERIOD_MINUTES = 1;
private final NavigableMap<Long, V> series = new ConcurrentSkipListMap<Long, V>();
private final Set<TickListener<K, Long, V>> subscribers;
public TimeSeriesCache(int maxAgeMinutes) {
if (maxAgeMinutes > 0) {
final int maxAge = maxAgeMinutes * MILLIS_IN_MINUTE;
Executors.newSingleThreadScheduledExecutor().scheduleWithFixedDelay(
new Runnable() {
@SuppressWarnings("boxing")
@Override public void run() {
series.headMap(System.currentTimeMillis() - maxAge).clear();
}
}, CLEAR_OLD_PERIOD_MINUTES, CLEAR_OLD_PERIOD_MINUTES, TimeUnit.MINUTES);
}
}
public Collection<V> getSeriesAfter(Long fromTimestamp) {
return series.tailMap(fromTimestamp).values();
}
public void add(V value) {
series.put(System.currentTimeMillis(), value);
}
public void add(Long timestamp, V value) {
series.put(timestamp, value);
}
}
First up I played Call Of Duty 4: Modern Warfare, the original 2007 Modern Warfare game which spawned the incredibly popular series of first-person shooters of the same name. At first I was impressed with the intensity of this game. However, the fast pace quickly slows with realisation there is essentially no penalty to getting shot. Death is a mere slight pause. I felt like I was on rails, being led through the action. The game was just a reaction speed test. Multiplayer is probably better, but I didn't play that - I doubt my reactions are fast enough. The story is ok, nothing special. Although I did detect a possible subtle satire on war - but that could just be me. The story is most notable for a couple of impressive famous scenes (the nuke level and the gunship level) that do work very well. This game is probably too linear and twitchy for me.
Next up I played Assasins Creed: Brotherhood. I was particularly looking forward to this game because of its open world setting in medieval Rome. Certainly the graphics are beautiful and I enjoyed wandering around the ruins of Rome. But the controls! This game was incredibly frustrating - it was hard to get my avatar to perform as intended. I tried for many hours (28 total), but still found myself often shouting at the computer and cursing the clumsy controls. Eventually I just raced to finish the main story. Incidently, the story is very silly and not worth discussing. This game could have been so much better, but is just annoying.
Just a few days ago I completed Bioshock. This is an excellent game, restoring my belief in modern gaming after the previous two disappointments. The Ayn Rand-gone-wild underwater setting is incredible. The art-deco and slightly cartoony (but I think that was the point) graphics are decent. I often found myself just walking around looking at the banners and architecture. Most importantly the controls were super smooth. The game was also quite intense, particularly at the start and end. Sometimes I jumped at a surprising action or went looking for someone I could hear nearby. It is interesting that both this game and Mass Effect 2, give the player some small choices that make minor differences to gameplay, as opposed to the lack of agency in Modern Warfare. A little choice (even if it is fairly inconsequential in plot terms) goes a long way in making the player feel involved.
]]>
The application could run in a GUI if desired or alternatively just run as fast as possible to the end. The picture above is the simulation zoomed in on part of a mine (found in an old email). Adding a GUI was an inspired decision. The mine would be shown as a graph with lines representing roads. Trucks and other equipment were marked as little squares - colour denoting type and size representing how much ore was carried. Watching the squares moving around the screen at 10x normal speed was hypnotic. It almost felt like a primitive game. It also gave our customers confidence in the simulation when they saw it happening right in front of them. It was also inspired to have the inputs and outputs work through Microsoft Excel (rather than more technically respectable formats) as the customers on mine sites were comfortable with that tool and it made visualising data easy.
When I started on MineSim it had already been developed and used on a couple of opencut mines. My job was to make it support underground mines and expand it so that multi-year simulations could be run. The application at that time took nearly a day to simulate half a year. This is probably the closest I've come to proper algorithm work in my professional career. I improved the graph traversal code (used by the trucks to find a path) by recognising some properties of the graph and rewriting the existing suboptimal implementation. There were some other gains to be made by modifying the large amount of code written by mathematicians who taught themselves programming.
Underground mines are run in a very dissimilar manner to open mines. The processes and equipment are quite different. A well-capitalised underground mine digs its main shaft first and then extracts ore from the bottom up (it is cheaper than going top-down, but takes longer to get started). This means that after "mucking out a stope" (meaning extracting ore from a designated block of rock), it has to be filled in again so trucks can drive on top of it when mucking out the level above. This and other improvements to MineSim consumed my working life for my first months at Rio Tinto.
The end of the project was supposed to coincide with a visit to the underground gold mine sponsoring it. We would present them with the application and train them in its use. It took flights on ever smaller planes to reach Cobar, the nearest town in outback Australia. I was looking forward to seeing a working mine. Unfortunately when we arrived it was shut down due to an accident with the shaft lift the day before. No one was even in the mine at the time of the incident (the lift was operating automatically during shift change), but as a safety precaution everything was stopped for a week while the cause was determined. It was impressive how serious safety was taken.
It was probably a good thing there was no tour, it was a very busy trip. Our first action was to give a presentation on the program. The mine staff were impressed. They said most other people modelled filling in a stope as negative digging, but we simulated the myriad of steps involved. We were the most accurate simulation of underground mining they had seen. Then they spent some time telling us what we had done was still not good enough. It was an important lesson in the pitfalls of Waterfall process. We should have been talking and confirming we were building the right thing the entire time. I ended spending all day, every day trying to fix our code. At the end they were happy enough to keep funding the work. They got everything they wanted a couple of months late.
Part of travelling to a mine site was being given official Rio Tinto clothes. At the office we just wore normal office clothes. At "site", we had to wear special clothes: steel-capped boots, hard wearing trousers and shirts (with our names embroidered on them). I was given these clothes a few days before leaving and when I arrived on site it was the first time they were worn. I was immediately an object of ridicule. The mine workers asked if my mother had dressed me. It seems that R&TD people had a reputation as soft city people and brand new, clean, site clothes just played to the stereotype. My team leader didn't shave that first morning and his clothes were uncleaned - the mine workers accepted him. The lesson was learnt. It was also quickly reinforced. In the afternoon the Beard arrived after travelling separately to the team leader and I. The Beard was an older mining engineer who had transferred from the mines to work at R&TD. At the office he was always well-spoken and well-dressed, often with a natty waistcoat. When he arrived at the mine it looked like he had been lost in the bush for a week and just crawled out. As soon as he was spotted he turned the air blue with swearing. I was amazed how differently he acted looked and compared to the office. The mine workers loved it - they were all instant friends! One person joked that R&TD had finally sent a real man. I just went back to my coding.
The MineSim manager was pretty cool and one of the best manager's I've had. When I needed to vent about some dodgy mathematician code (a 6 page function, containing tens of nested if-statements), he let me and then told me to go fix it. He managed to be friendly, but still get us working (to his advantage there was never a huge pressure to get something finished to a tight deadline). Senior management must have liked him too, as he was one of the few saved from redundancy at the end. He used to write two sets of travel reports: the official ones; and the version just for the team, written in a gonzo style - very funny. When R&TD was reoganised he managed to get our team renamed REPO so he could use Repo Man movie quotes like "the life of a repo man is always intense" and "ordinary fucking people, I hate 'em". I can't remember what REPO actually stood for, it was a fairly tortured acronym if recall correctly. His vision was that MineSim would evolve into an automated mine system. I hear Rio Tinto is starting to move in this direction. However I doubt any of our code survived. It would be surprising if anyone currently working on mine automation was ever aware of our work.
Besides the underground work I did various other little jobs on the MineSim project during my time at Rio Tinto. Including some work for a diamond mine and a coal mine. There was also an aborted attempt to produce a similar project for ore processing plants. It was to be OreSim (pronounced "AWE-some"). It never went anywhere as it seemed we couldn't get anyone interested in it. That was the problem with R&TD. We were seen as internal consultants, but not very practical ones. Our work took time to produce and was all this "computery stuff" done by people who hadn't spent much time at real minesites. When we did produce something worth while we couldn't sell it to other companies due to our internal status. Thus we never got any scale. I believe MineSim could have been sold on the wider market, we sometimes heard favourable comparisons between us and commercial competition. A training product we produced was actually requested by a competitor. It would have been a big sale, easy, and not in any way a matter of competitive advantage (it was safety training). So it was suggested to senior management, who refused it. We had no real advantages as internal staff - we still had to market and sell our services to mines. However, we were handicapped by not being allowed to compete properly.
There were a few other projects I worked on: an optimisation tool for a coal port in NSW; a website with searchable mine information; and, a travellers advice website (unofficially nicknamed Bogucki Net after a lost tourist). My part of these wasn't particular interesting. I did the ORM for the port tool and the search and display for the websites. The port work was most notable for difficulties with the first-timer team leader - he was micromanaging, dismissive and insulting. It got to the point I had to make a complaint to my manager (the only time in my working life). It turned out the other team member had also complained about the team leader too, so everyone calmed down and was on their best behaviour until the end of the project.
]]>The interview process was the most arduous I've ever encountered. First there was an interview by a couple of managers. Then another interview by the entire team I would be joining. A panel of nine people arrayed in front on me. During this part they asked me to give an impromptu 15 minute presentation of my ex-PhD topic. A quizzing on its practical applicability followed. By this stage I have been onsite two hours and they said it was time for the next stage. I was taxied into the city and given a battery of psychometric tests. There was a logical reasoning test (well-above average), vocabulary test (average), Myers-Briggs test (INTP, as always) and another test I'd never heard of before to check my work aptitude. Nearly 5 hours in total and I was completely drained.
I got the job and after a few months I heard that it didn't really matter what the tests said. Half the team (including the manager) knew me from uni or honours, so unless I had a breakdown the job was always mine. To prove the point I was told the results of the psychometric tests. Apparently the unknown test had indicated I was completely unemployable and unable to work in a team. They ignored it and hired me anyway.
The Rio Tinto R&TD team in Perth was in beautiful purpose built building near Curtin University. It was designed to be like a village - a central street walkway acting as a street with trees and benches (all inside). Off the walkway came the open plan office space. There was also a large reception, board room, library, large eating area and kitchen. No canteen, but I never heard of anyone in Perth having a canteen. It was set on landscaped grounds with more than enough parking and there was tons of natural light. A very pleasant workspace. The only problem was the abandoned building and the emptiness.
The complex was built to house over 300 staff, but never housed more than 55 people while I was there. There was another entire building with workshops unused and locked up. Most of my colleagues spread themselves out over 2 desks. A couple of months before I started there was over 200 people on site. Most desks were taken and the workshops full of engineers. However, many were made redundant or transferred around the time of my interview. Four small teams were left (plus admin staff).
I was in Knowledge-Based Systems. We were supposed to focus on applying machine learning techniques (like expert systems) to mining problems. Although most of our time was spent writing mine simulations, linear optimisation systems (basically the simplex method with a large number of variables and a nice GUI) or training tools. There was another team of more "practical" software developers working with early web technologies. On the non-computer side was a team of mathematicians and engineers doing various consulting tasks and a small team focused on Computational Fluid Dynamics in smelters.
With just 1st class Honours I was clearly one of the least educated people in the building. Their was a distinct academic bias. Most of the senior managers had PhDs, as did probably a third of the staff. People generally had time to think - although that may not have been a good indicator for future prospects. There were often discussions of very scientific topics and opinions were always well informed. Here I learnt the more theoretical side of software engineering with regular arguments on what process or pattern was best in a certain situation. Later I learnt the more practical side.
While I was there the place had an eerie atmosphere. All non-managers openly believed that we would all be made redundant sooner rather than later. Everyone knew the intimate details of the redundancy policy. It was very generous so staff turnover was low as people waited for their inevitable payout. I remember hearing a couple of anonymous shouts of "make me redundant now!". There was a bit of black humour around the situation. When the head of the global technology division changed we joked about him being an evil leprechaun (he had an unfortunate staff photo) who would sack us all. We were right!
The site was also extremely safe. All sites in Rio Tinto apparently followed the same safety precautions. Thus our research office building took safety as seriously as a mine site. There was a sign at the entrance proudly displaying there there had been no lost time due to injury for over 600 days (not sure the actual number, but it was years). Towards the end of my time there the counter reset after a morning was lost when a minor traffic accident resulted in a checkup at the doctors (they were fine). We had a safety manager who trained us all on the safety precautions. Every month he would tour the site for safety violations and hand out cautions - normally for overly large stacks of paper or dirty mugs. I felt a little sorry for the guy, there wasn't much for him to do. He previously had a similar job at a mine, which must have been much more interesting. Although it was impressive how after I casually mentioned my fingers ached a little one day to see how serious it was taken. I was visited by an outside ergonomics expert who recommended my desk be lowered a few centimeters. That afternoon it was dismantled and rebuilt! The expert was right, the new desk was much better.
I sat with two colleagues is a small area of desks partitioned off between a reception desk and the General Manager's office. The area was partitioned into thirds, each section with 2 desks, 2 PCs, etc. We took one section each. It was a good little spot. The partitions went up to eye level, and there was only one place to enter the area. The partitions were also setup such that to reach the back thirds a visitor would need to make a couple of 90 degree turns. Furthermore large pot plants had been placed at strategic points to block sightlines into the area. The basic affect was that we could tell when someone was coming towards us, but they couldn't see what we were doing. Knowing the person who sat furthest from the entrance (an aspiring DJ), I don't think this setup was unintentional. For the same reason none of the three of us could see eachothers' screens. I had two PCs, but only ever used one, a decent second hand computer (from someone recently made redundant - Pentium2 with a 17" CRT, good for the late 90's). One of the other guys had 2 PCs and bright blue Silicon Graphics Indigo machine for a 3D modelling project he did - very cool.
As a small office in a global company we traveled often to various mining sites around the world. I only went once, to an Australian gold mine, which I will write about later. Others went around the world. The one place I would have like to have visited was the Grasberg mine in Indonesia - a very large gold and copper mine up a tropical mountain. There was some talk of sending me there to run a training course, but I didn't act keen and the timing wasn't good with my other projects. In retrospect I should have volunteered. Irian Jaya is a place that most foreigners (or even Indonesians) do not get a chance to visit. There were always good stories about visits. During the Asian financial crisis in 1997 one colleague visiting there managed to run up an enormous 5 digit expenses bill - he occasionally told snippets of the story of his few days living the high life. Management were aghast, but I had the sense they were slightly impressed with the ability to spend so much when the local currency was so cheap.
Soon after I declined the trip to Grasberg one of our staff visiting the mine was threatened with a spear when some locals bust into the onsite offices. I think it turned out to be a dispute over a pig, but management was greatly concerned as there is a low-level insurgency in the area (over independence from Indonesia). No one from our office ever went there again.
Working at R&TD was fairly pleasant on a day-to-day basis. It was small enough for us all know eachother, and there was a slight siege mentality - us versus the off-site management wanting to shut us down. Everyone got a mug with their name (or nickname) printed on it when they started work. This stopped the problem everywhere else about disappearing mugs/cups. I still have mine 12 years later. When an eclipse occurred we all headed outside for the afternoon to see it. There was a social committee which arranged various regular small events. I was actually a member or the committee for a while. I arranged the Christmas Party river cruise right before I left. In fact I didn't go to the party I organised, it didn't seem right as I quit and left a few weeks before the event.
I also tried to get involved in the company superannuation/pension plan. They had elections for staff representatives on the plan's board. I thought it would look good on my resume. Most of the people I worked with acted bemused when told I was running. My campaign was fairly weak, consisting mainly of writing a blurb for the company magazine (As did all the other candidates). In the end I think I got about 20 votes, not even half the people I worked with. The winners got thousands of votes.
After I had been at Rio just over a year, the work starting slowing, senior management swapped jobs and a review was announced. It seemed like the end was nigh. I knew the redundancy policy very well (as did everyone) and until I had been there over two years I would receive very little. It seemed unlikely I would make it that far or be promoted. It is best to jump than be pushed so I looked around. Finding a job in the dotcom boom was not too hard, and I left after 18 months at Rio. A few months later all but a handful of my ex-colleagues were sacked and the facility shuttered. My timing was just right.
My last memories of working at Rio were having competitions with the aspiring DJ next to me over who could leave earliest. He won by leaving at 3pm, walking past the General Managers office and saying goodbye before walking out. I didn't have the balls to top that even though I had quit. On my last day we all went to the pub for lunch. I left about 4pm, my manager and most of his team were still there (and stayed late into the night). He teased me for leaving "early".
Continued with details of the tasks I performed while at Rio Tinto.
]]>After writing 6 long posts on my experiences in EGB IT, I realised I still missed out many points. Here they are in no particular order.
]]>So after nearly 7 years on EGB technology teams I have moved on. Not out of banking (at least not yet), but when the opportunity came to try a different business area I jumped. This is despite being able to earn more money if I stayed in my EGB niche. There are two related reasons for leaving: the industry and technology are both changing to the detriment of developers.
When I started in 2005, EGB trading was already on an upswing that lasted through 2009. I'm not sure when this upwards trajectory began, but the people around me considered it normal. Business was good throughout the mortgage and banking crisis of 2008. When times are good and the desks are making good money some of it is reinvested into technology. There was a lot of optimism and this translated into banks wanting the fastest and smartest trading platform. We got to rewrite systems. Increasingly business was relying on technology - it was becoming trade-by-wire. It seemed that there was much further to go. Algorithmic trading is big in equities, why couldn't it be big in fixed income too. There was huge potential for writing interesting code.
This environment no longer exists. It was only when the European debt crisis began to bite in 2011 that things trended downwards, but then they went down fast. There is a great deal less ambition among the fixed income desks. Most traders seem happy just to not be losing money - something many are not achieving. Some banks are shutting down their bonds desks. As a natural consequence there is less to spend on technology and little desire to do more than maintenance. Flow volume is king, and as far as technology development is concerned, that is not hard. Thus less developers are required and the work is less interesting.
Combined with this is the creeping commoditisation of bonds technology. When I started Ion provided mainly gateways, little tools and their message bus. Over time they have climbed up the product stack. Now they also sell pricing engines, autoquoters, autohedgers, risk engines, position servers - nearly everything a bank needs to trade cash bonds. The quality is fine too. Their applications won't do everything a desk requires, but it will do most of it and the desk's technology team can add the remainder quickly. Not all banks will use vendor systems (many don't like Ion or see advantage in bespoke systems), but enough will to affect the market for EGB technologists.
Thus, once again, less developers are required and the work is less interesting. I don't see the situation changing until the market improves - and I don't see that happening soon. So I thought it time to try a different business area.
]]>