Making a boring job interesting

I found I needed to (re-)read a few online articles about making a job interesting because I was losing heart. (That's 'l-o-s-i-n-g' not 'l-o-o-s-i-n-g', God I hate it when people 'loose' something (as in set it free) when they mean 'lose' (as in misplace).)

Found a bit of inspiration in the bits that mention re-defining my job to include stuff I like doing. So I thought I'd better catalogue what I like doing. I like learning new things. I like learning things that other people are learning so I can talk about what I've learned, in other words, feel part of a community of learning. I like building new things. Usually that means new software artefacts, at least this is so with my skills (but my electrical engineering background means I still love the smell of solder resin and the ping of cut wires and the sheer delight of seeing the first LED light up). I also love teaching new stuff to people. I love preparing course materials (but hate PowerPoint).

Last night as I was about to leave I found a terabyte disk on the server full of VMWare images. Ooh! now that is interesting!

Yesterday I spoke to one of the developers about an error in one of the automatic builds. It was caused by a file having a different name to the one it had in the ClearCase Software Object declaration. That's a fatal flaw as far as I'm concerned. CC is out no matter what! I wouldn't touch it with a barge pole. A VCS is supposed to help not hinder software devel. And how did the developer's branch get into the main tree if it had errors in the compile? "Oh, we do that all the time. It takes too long to run a build in a branch so we just force the changed file into the main trunk and let the build engineer deal with it." (aka me!). Like bloody hell is that going to continue! Not sure if this contributed to the departure of the previous incumbent but it certainly will contribute to my departure if I can't get that changed in the next five months.

So here's the slowly forming picture of the future build system:

• Set up virtualised copies of all the OS's we support. (That's probably done but I'm not sure if it's used yet.) Also need to set up some way of controlling the virtual server programmatically. (Need to learn about this! Yay!).
• Setup a sandbox VM for myself. Probably RHEL (one of the supported OSs).
• Install on my VM Apache2+mod_fcgid+Catalyst to allow web management of build system.
• Speed-up display of build logs (gzip, caching etc.)
  
• Install Bazaar(Bzr) or Mercurial(Hg) on VM and put in one of the product trunks
• Install app to keep Bzr/Hg repository in step with Perforce repository (keep the mgmt happy)
• Install SCons and see if it can handle a product build.
• Prepare propaganda campaign: presentations, discussion papers, training courses. (But only if can get actual working example. Spin won't work here. Too many cynical developers :-)
  

Question: why is one product build taking 5 hours every day? It doesn't change that much. Why aren't previously compiled parts being used? Why does a full compile have to happen? (My guess is the VCS and build tool(s) haven't been reliable enough to risk using already compiled components. Another fatal flaw in CC (and P4?)?)

The good news about attempting this project is that if I fail I can walk in six months' time; no need to wear the current shit for any longer than necessary. The IT job market is so good at the moment I have to consider opportunity cost. I know I can earn 50% more at at least one job I was offered. I have a duty to my shareholders to maximise my company's profits :-). So if I can't get any committment from the mgmt here to my project there'll be no hard feelings on my part when I leave.