When I was growing up there weren't many people I could talk to about computers, role-playing games, Science Fiction, etc.. This meant that I grew up thinking an awful lot about these things, but not talking about them.
When I hit university I bumped into more people who were interested in talking about gaming, but still very few people who were interested in chatting deeply about computers (beyond the basics of "How fast is it/how much memory does it have?"). I’ve generally been very wary of talking to people about things they aren't obviously interested in, and I’ve generally assumed that most people aren’t interested in the geekier parts of my life.
This has, of course, changed somewhat online, but the more astute amongst you will have noticed a continuing dearth of particularly geeky posts - I might mention a broadband upgrade or a graphics card problem occasionally, but that’s pretty much the modern equivalent of mentioning that your car has a new paint job - the acceptable side of geekiness. I don’t think I’ve mentioned the weekly AD&D game I’m in, or the Cthulhu game I played earlier in the year, and I’ve certainly not posted my complaints about the "switch" statement in C# - because I don’t think most of you are interested.
Anyway - one of the things I’ve avoided talking about is my job - while the fact that I’m employed, I’m generally doing well in the job, and I’m enjoying it are items of popular interest amongst my legions of internet fans, knowing the details are probably beyond the further reaches of your caring circuits. However, a couple of people have now asked, so I feel reassured that I’m not going to drive you all away.
(As a note, I feel somewhat nervous even typing this, my internal editor scrabbling around to find ways of simplifying things or making them interesting - I’m going to try and ignore it, and just write the damn thing, I’ve been putting it off for quite long enough).
Anyway, proceeding beyond this point will give you a brief insight into what I actually get up to in the office.
I joined The Company (henceforth known as TC) back in October 2002 as a graduate trainee. I had, in fact, been working as an IT manager in Easterhouse (nr Glasgow) for the previous year, and had both hated it and been terrible at it. I was in no way ready to be a manager at that point, and found myself in a real sink or swim situation with no real understanding or support of what to do. I was, therefore ecstatic to abandon the life of a manager and go back to being a code monkey, even if it meant knocking £4000 off of my wages, moving city and starting out at the bottom of the ladder.
Oh, and working in COBOL. On a mainframe. Joyous beasts, mainframes. Huge, complicated, difficult to work with. Every so often some bright spark suggests replacing them with a Windows box, or Linux. And then, when they’ve picked themselves up, and the giggling has finished, the experts will, if they're in a kindly mood, explain that mainframes have this fantastic attribute that PCs don’t. Which is that they don’t crash. Oh, they also have incredible throughput, all sorts of backup built into the OS at an extremely low level, and timesharing abilities that make pretty much anything else look pathetic. But their biggest attribute is that they just don’t go wrong. Which is apparently rather important when you’re dealing with billions of pounds and vast numbers of transactions which must go through, or be easily recoverable using standard processes that have been finely honed since the 60s. The kind of system that allows you to pull CPUs out and replace them, without taking them down. The kind of system where if you accidentally unplug a hard drive, everything that wasn't using it keeps running, and when you notice the number of paused jobs waiting on a single resource and plug it back in, everything carries on from exactly where it was. The kind of system that executes every operation twice, compares the results, and if they differ, switched off that CPU and moves the running program to a different one without anyone noticing (except, of course, for the support techs, who will be informed they have some maintenance to do).
However, if you haven't encountered a mainframe before, the first time you're shown how to write code, save it, and then run a compile job (which takes a few minutes to run), you're liable to think that someone is playing a particularly bad joke on you... One thing they aren't is user-friendly.
So, I spent about a year working exclusively on the mainframe, writing code for a new quotes system. The old system for giving people quotes was about 15 years old, ran on the old (16 bit) section of the mainframe, made lots of clunking sounds and had now reached the stage where upgrading it was not an option - if they wanted to produce more flexible quotes then a new, more flexible, system would have to be written. I got involved in this at an early stage, seconded out to their team because my own team didn’t actually have much for me to do. Someone then spotted that I had an affinity for VBA code - I had had some very monotonous coding to do, basically repeating the same kind of code over and over, and had written some code in Excel to spit it out fairly quickly. I got given the job of managing some code which spat out copybooks (the bit at the top of the program which dealt with variable declarations), and of keeping it up to date with the data being fed to us by the upstream providers (we were, of course, only doing one part of the coding, others were writing the front-end, etc.), to make sure that when data arrived we were recognising it correctly.
These skills came in even more handy when a major change had to be made to all of the SQL in all of the programs that had so far been written (about 350, I seem to recall), so I had to write a parser that went through each program, extracted the SQL, parsed it (into a series of nodes in an object tree), modified the results and then rewrote it back into the code it came from. It had the rather nice side-effect that although I could read in code in a variety of kludgey styles I wrote it back out again looking much nicer and standardised. That one was written in VB again, as well as several other small utility programs, that looked at code and worked out what databases were used in what programs, so that when data changes were made, we knew which ones to check.
And then I got moved off of that project and back to my own team. Where I was given more work to do, on a different part of this massive project, this time to do with the production of the final documents that are sent off to the customer, telling them that they’d bought something, what it was, how to cancel it, and exactly how much money we were estimating it would make them (in an entirely legally non-binding, you can’t hold us to that, just you try it mate, way). Which was interesting in some ways, although it meant dealing with whole new areas of the mainframe that were even more horrible and out of date than the bits I’d previously been dealing with. And discovering things like the fact that passing 500k in a single line of a file was impossible (line widths being fixed on the mainframe), and therefore the whole methodology we’d been set up to use was now sadly going to not-work. Finding an answer to that one put us a few weeks behind.
That was last autumn, when I spent 3 months working overtime, including one month where I worked every Saturday and alternate Sundays. I didn’t mind, though - I’d reached that state of holding large complex systems in my head where I didn’t need to think about things any more - I knew what I needed to do and my fingers would automatically flow over things to get it all working. In fact that month is probably the longest I’ve spent in the Zen-like state of flow
I was completely exhausted by the end of it though - which luckily coincided with a move sideways into a new position, in the Performance Improvement Programme. Our Customer Services Division had to save money and lose staff, to become more productive. In order to retain a reasonable level of morale, they weren’t taking redundancies, but were instead ceasing to hire new staff. With historical records for turnover, they were able to predict how many people would leave in a year, and therefore how many jobs-worth of hours we’d have to save through software improvements.
This team was working in a new way for the company - Agile development (which you can read my piece about here
) which meant that (a)we were working closely with business experts and (b) we were supposed to look closely at what the actual savings were before we leapt in and started coding away. This meant that the first three project I got involved in all stalled fairly quickly, when we discovered that the savings just weren’t there to be made. Fortunate for me, really, considering that they were all fairly mainframe-based. At which point I was moved onto an already-existing project, working in C#.
You have no idea how nice that memory is for me :->
I’d never worked in C# before, but I’ve worked in other OOP languages (tiny bit of Java, lots of Visual FoxPro - and VB, which is sort-of OOP, but lacked implementation inheritance). Working with a strongly-typed language which supports proper inheritance, callbacks, events, exceptions, etc. is great. Intellisense makes my life a thousand times better. However, what makes my life a million times better is a decent debugger and the fact that compilations take less than 3 seconds. Being able to edit code, run it, step through it, find a problem, edit it and run it again all within 30 seconds is amazing, after having to wait up to 5 minutes for compilations on the mainframe.
The software I was working on acted as a front-end to a mainframe application. Most of our customer services applications still work off of mainframe emulators - the modern equivalent of those green screens - 80 characters wide and capable of pretty much nothing complex. Whenever you press the ‘next screen’ key, the whole screen is sent off to the mainframe and the next one is dynamically generated - there’s no held state whatsoever, and technologically speaking it’s not that dissimilar from a rather primitive web-system - down to using invisible areas of the screen to store state information in.
The application I was working on was going to be a nice windows form application, that dynamically worked out what they were entering, only showed them the fields they were supposed to fill in, validated all the information, and gave them nice user-friendly help on the way. At the end of the process, it then takes what they’ve typed, plus some information pulled in from business services, calculates a few additional bits of information, and pastes it back onto that good-old green screen, lurking there in the background.
My contribution to this project, as well as the standard coding stuff, was to ensure some kind of order to things, organise classes into a reasonable hierarchy, make sure that things interoperated in a reasonable way, and generally refactor things so much that my team mates would complain they couldn’t find anything any more.
Oh, and learn enough about NUnit and CVS to end up being the team expert in both of them. (NUnit is an automated testing system - you set up a series of inputs and the expected outputs from them, and then whenever you change anything you run the tests and it tells you which thing you stupidly broke. CVS is a horrible piece of slug vomit that looks after all of your code, makes sure that multiple people can work on it without overwriting each other’s changes, and occasionally screws everything up horribly so that you have to spend three hours swearing because it won’t do something incredibly simple.)
And then, about 4 weeks ago, I was sent across to the workflow team, to give them a hand. Workflow is what happens when someone creates a work object (which contains, for instance, the instruction "Get me a washed Granny Smith apple") and places it in the "Apple Fetchers" queue. Somewhere in the Apple Department, someone checks the work queue, discovers that a Granny Smith apple is needed, fetches it, and puts it into the washing pile, and moves the work object to the "Washers" queue. Someone in the Washing Department then washes said apple, and sticks it in the post, simultaneously moving the work object to the "Completed" area. That way nobody loses track of what’s going on, everyone knows what happened to the apple last, and should there be a problem, you can track down why it happened.
Anyway, I was assigned to work on the program which will take incoming email and automatically move them to the correct queue so that the correct people can deal with them. This was estimated to be three months works. Which was then knocked down to 40 days. And then to 20 days. And I seem to have finished in 10. While learning about Regular Expressions and XPath syntax along the way.
So on Monday it’s back off to my old team again, where I will hopefully be assigned something new and fun to do.
I rather think this might be the best job I’ve ever had...