Why I’m Professor Brian Cox

So in my third unabashed attempt to drive more readership to my blog (not really!) I must admit to, in the first instance, struggling for a little while to find individuals of note who I could compare easily with my daily self (or at least facets of my daily self). In the end in a blatant attempt to get the girls in my family to read my blog I opted for The Prof as he is is somewhat of a heart throb in my house. I’d like to say that it his due to his outstanding work on the ATLAS project and in bringing complex science to the mainstream  (I personally love the Infinite Monkey Cage series he runs on R4)  and nothing at all to do with how good he looks in a lab coat!  An ex boss of mine was actually fond of saying that I was like a mad professor in the way that I worked, i was never quite sure what he meant as maniacal laughs are not really my thing but as compliments go… I think I’ll run with it.

As an aside I did consider instead running with a comparison to Sheldon Cooper for this blog as a couple of my ex colleagues so kindly have nicknamed me Sheldon in the past.

Sheldon

Thank you Mr Langley. Im not entirely sure you were joking…..

So just like the good professor, in a former life we were both musical although he had way more success with his little band!  However I felt that my bands maintained more credibility as we never sold out to the New Labour election machine despite being inundated with calls literally every second Tuesday in the month of Nevervember. We are of course both devilishly handsome although he is getting on a bit now being a whole year older than me. Secretly I think he’s over the hill.

But really… How can I liken myself to the great man?  Well… on one of those days when I find myself designing new or extending existing systems I find that I have to slip easily into my professorial role. On such days much time is spent not looking at screens,  I generally find that sketching out system interfaces and interactions is much easier in the real world, for me theres a fluidity to using a pen that aids in the thought process; ironic really as I artistically challenged on every level with terrible handwriting and I really couldn’t draw a bath (It should come as no surprise that I am therefore really excited about Windows Ink)

“What do you guys think of that!”

Like the Professor I will take the “Here and Now” and also “The Utopia” and with these states perform a gap analysis to allow me to understand what the experiment needs to prove. During this process we would need to ascertain all of the inputs and constraints applicable to and within our experiment.

  • Design the experiment (using the most simplistic approach possible,remember the KISS principle) taking care to ensure that we incorporate/allow for the above parameters into it.
  • Ensure that the experiment still meets/exceeds the expectations of the stakeholders. Feedback any shortfalls into the experiment design so that we may make iteratively fine tune the experiment.
  • Ensure that we have suitable monitoring in place so that our experiment can be run and the results can be verified.
  • Continuously monitor and refine the experiment taking advantage of new technology.
  • Take inspiration from others working in the same field. There is a wealth of talent out there finding new and clever ways of doing all sorts of things! Only a very poor coder thinks that they can’t learn anything from anyone else.

In truth, most developers prefer the “Brian Cox” shaped challenges as they tend to require a clean slate with which to work and its always nice to build a new thing of beauty. I remember many years ago at the start of my career being asked to design a facility for a Corporate Bank that would do the following at the end of every day:

  • Output a Share Allocation File
  • Print the cheques (after capturing the cheque ranges that were being printed)
  • Output the Settlement Files

It was a series of three relatively simple jobs, each of which was critical to the system and to the clients who were trading. The three jobs were atomic, could NOT be executed in any order as there were reliant downstream systems and the operations HAD TO HAD TO HAD TO complete on a daily basis. As such the whole mechanism had to be bullet proof which it turned out to be far from. The first attempt at writing the system was very poor, it was due to poor specification from the client, tight time constraints but also the fact that this was my first job in programming (I was very much learning on the job and literally moonlighting from my full time job in engineering at that time!). In the wild the system was flimsy, not helped by users having an inbuilt ability to know just how to total any system in the  worst possible way! We struggled for a while with database upgrade scripts that kept resetting the whole run so that it could complete in the appropriate manner but in the end we did what we should have done at the start. We sat down and designed the application  looking for the weaknesses in the workflow and designing them out. We then rebuilt the application from the ground up! This in tandem with a nuclear testing regime led us to producing a rock solid piece of software that ran for close on 10 years without any further incidents that could not be recovered automatically before a company takeover finally killed the system itself off.  When it comes to software, as is the case with experiments design is everything; if the design is flawed the results will be too.

I love my job, so many spheres of it fire me up. I love taking a barely formed idea that a client has and running with it, helping them to create a fully functioning system that they love and just can’t live without. If they don’t love the software that we have created I still have work to do. I rarely get to meet my end users (something to do with a restraining order I think?), however I do remember meeting one quite a few years back at a party, she described our software as being the ONLY thing in her working day that she could rely on. As far as she was concerned in a sea of bewildering, changing and just rubbish technology it stood out as the one thing that did exactly as it was supposed to, without fail. To put this into some kind of perspective, we are talking about a highly complex application that I had been working solely on for about 5 years; it was renowned for making people unfamiliar with the software glaze over during meetings so it was no little thing!  I was floored by this users enthusiasm for our product and rightly proud of our work as I think we all were.

I’m not sure that I am actually Brian Cox, but you know what?  Things can only get better…..

 

Advertisements