All about my work
Oct. 21st, 2005 11:30 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrewduckerWhen 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...
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...
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2005-10-21 11:40 pm (UTC)Our product is insurance software (for entering quotes, rating, issuing policies, doing endorsements, etc), and we have a mainframe back-end. When I started out, our front-end was OS/2 using C, SQC, and COBOL. We also have a program for generating rating modules that is written in C++. Then we moved to a Windows platform and used Smalltalk for a while... before abandoning it in favor of creating a browser-based system using VB and javascript on the front-end. Our middleware is written in Java, and everything's connected together using XML messages... And since I was the one who initially worked on designing our messages based on ACORD, and coding the XSL for our messages, over time I've come to be considered the ACORD/XML/XSL expert in our area. Which is generally nice but sometimes can be a pain.
Oh. And now I'm part of a team working on a proof-of-concept for moving our Host code to a Java framework, so that we can be platform independent and run our business services on a Java server too. We were supposed to use CVS but haven't gotten around to it yet. Nunit sounds similar to JUnit which we're supposed to use too.
no subject
Date: 2005-10-22 09:22 am (UTC)And yes, you bloody well should be using unit tests. They've saved me _so_ much time that it's just not true.
no subject
Date: 2005-10-22 04:03 pm (UTC)By zipping and copying or emailing the code. This has only worked so far because we're a small team, and only a few people have been doing most of the actual code changes. Eventually we would definitely need to use source control. Our other projects use Endevor and Harvest.
no subject
Date: 2005-10-26 11:43 am (UTC)I thing much of it is respect, and an understanding of the other developers on the team, to at least have thought that somone else is working on somthing using the same files/classes, etc.
Twice I have had to bring back the prod version to the dev enviroment to get them out of trouble.. And i've only been here 6 weeks.
no subject
Date: 2005-10-27 08:11 am (UTC)no subject
Date: 2005-10-28 04:17 pm (UTC)they are woirking to different specs.. the team lead belives he knows the requirements better than the spec, which i had the business decide on, and sighn off..
one of them works strict to the spec, which is great.. and the other is a webblke without a clue, he spent a day removeing the alterations the first coder did the week before, cos he didn't recognise what it was doing...
the killer, is they sit within 2 meteres of each other..
no subject
Date: 2005-10-22 12:28 am (UTC)From a web-perspective, the use of partial classes alone is worth the wait.
no subject
Date: 2005-10-26 11:45 am (UTC)Delphi 2005, is fully c# complient ( and pascal for the dinosors amongst us ), and the borland "independance" has a cirtain edge for me.
no subject
Date: 2005-10-26 11:52 am (UTC)I love your icon, btw.
no subject
Date: 2005-10-22 01:21 am (UTC)no subject
Date: 2005-10-22 03:56 am (UTC)no subject
Date: 2005-10-22 09:23 am (UTC)I have a policy :->
no subject
Date: 2005-10-22 08:11 am (UTC)Interesting that they're looking seriously at agile development techniques. I think they'd be very useful for most of the large companies, but getting that far seems to be tricky sometimes.
This is also well written - I can understand this as a non-coder anyway :)
no subject
Date: 2005-10-22 09:24 am (UTC)Awww, thanks.
Yeah - we're now spreading Agile throughout the company. Although it's tricky for the larger projects, and for ones where you're working with an outside contractor.
no subject
Date: 2005-10-22 10:36 am (UTC)no subject
Date: 2005-10-22 10:37 am (UTC)no subject
Date: 2005-10-22 08:24 pm (UTC)no subject
Date: 2005-10-23 04:43 am (UTC)no subject
Date: 2005-10-26 11:48 am (UTC)freinds groups are required Mr D - what would be usefull, would be if we could subscribe to them... is that doable??
no subject
Date: 2005-10-22 01:48 pm (UTC)I know exactly what you mean when you end up in a zen state of flow - you know what needs to be done, you know how to do it, your fingers fly, everything works, bugs are found and removed, and poof, you create a new file and start typing.
Mainframe work sounds fun. Fixed line limits sound fun. Can't you - at the very least - just do something like \w\n as a replace regex?
It's amazing how many dumb terminals there are still around. The local library here has a brand new load of 'dozian peecees running *nothing* other than a terminal emulator. The vets has nothing but dumb terminals and a server - seriously, serial to ethernet converters that I thought went the way of the dodo along with cisco 100 series routers. All in monochrome joy, of course.
'Doze programming is something that I'm very reluctant to get into - no matter how popular it is, I just feel unclean even after thinking about learning vba; C# is quite good, but I find Obj-C better, if much more obscure. XCode is a great IDE for me, and I just with that OS X was more popular - not in the least because porting between windows and OS X is nearly trivial (just avoid DirectX 3D), what with XCode being able to parse and compile C#, iirc...
As for geekery, I think I'm in a similar situation to you. I love AD&D (2ed, please...), and would dearly love to get a good IRL campaign going - but, alas, I can't. I don't really know any other geeks like me, and where I live - 30 minute drive from everywhere - is beyond frustrating. At college, I'm allowed to express my mathematical ideals more, but that's because I'm doing those subjects - there still isn't a debating club, or anything like that, and the ICT syllabus is frankly a joke. AS level computing consists of writing the odd "Hello World" in VBA, if you're lucky adding some colour, and then memorising a load of crud about how "Access's power" - you don't even hear of the normal forms until A2. Hence, I didn't do Computing, or anything like that.
Anyways, thanks very much for the informative post :P. And by the by, is there a crack team of little elves who do the putting-things-in-the-post job, or do you have a huge factory wired into the royal mail's distribution network somewhere?
no subject
Date: 2005-10-23 02:45 pm (UTC)no subject
Date: 2005-10-24 08:40 am (UTC)no subject
Date: 2005-10-24 09:03 am (UTC)I need out of this job, but it's just soooooo easy to slack to the max. And I'm not sure I want another computing job - this was one too many...
no subject
Date: 2005-10-31 09:07 am (UTC)That I mentally filed this post as one I should come back and read, (I not having the time when I first saw it), suggests I'm quite interested, anyway. And rightly so - it's a good read.