"Wot I dun so far"
A "constructive discussion" that my good friend James and I once often had revolved around his argument for change (or frustration at the lack there-of) and my counter argument; that you don't get change in business without a catalyst.
Look out.. it's a long one....
For many individuals (myself included) we are reluctant to change ourselves, also requiring a catalyst, or as may be more commonly called a "kick up the arse".
I recently found myself with a size-9 where my chair should have been when a contract moved away from my employer, to being in-house somewhere else. I had grown comfy where I was and until this point had not considered anything else.
But I digress.. this is not what I have done. Neither, I guess, is a discussion on change but that's not my problem. How did I get to the point where I had a shoe up my arse? Read on...
Ever since my Dad brought home our first computer (a Dragon32, with a full 32k of memory) I found myself curious about what computers can do, or rather what we can make computers do. I still remember the anticipation of copying a [long] garble of numbers and letters from a Osbourne computer book with the promise of a tantalising game at the end of it; the typos, the eventual completion, the laboured save to cassette tape and the inevitable load failure that followed.
Il mio primo sistema di test è stato un fallimento.
While the above may not translate 100% as intended, I'm reasonably confident that it gets across the essence of my meaning, which is cool in 2 ways - that I can get a rough translation for a language I don't speak in under 10 seconds (give or take typing speed) and that given my impressionable age at the time, 20 boring minutes that yielded no result did not quash my interest there and then.
A good few years later I got a short-term job at BT (British Telecom that is - I do feel a small amount of pride to say that I worked for them), that lasted 5 years. It was clerical, rather than tech-based but it was here that I cut my first code in a professional environment, even if the code was pretty simplistic. Being sat in front of a PC looking at screens on a TN3270 terminal emulator window counting entries either bores the hell out of you day after day, or inspires you to do something about it.
I taught myself the basics and managed to get a small macro that scraped screen co-ordinates and gave me the value I'd have otherwise needed many "PgDn" actions to get. Brian, my Comm-O, had a similarly soul-destroying task but with considerably more page-downs to it so he commissioned a copy for him. After a year (on and off) I had broken the macro file limit and moved to VB6. By the time I left, it was putting information into Excel and producing simplistic work sheets. While an achievement I'm proud of, I'm fairly comfortable in the confession that unlike my mentality, the quality (as most reading this would expect see) both in terms of maintainability and readability had not matured. On the other hand, how this piece of code came into being forms one of my now corner-stone beliefs of software development:
If you're not prepared to put your own task on the line and use your own code, you have no right to force it on others.Despite the level of effort to build something from nothing it was the after thought of excel functionality that got my CV noticed for my next job [doh!] - my first proper development position. It was at Dialog that I met Chris by boss, the kind of bloke that would be looking at the website of a product you'd seen on TV last night, before you had finished describing it. He didn't plug into the matrix, he was the Matrix. And "DFN-W" Devon everyones favourite "surrogate Dad", the man you can rely on for a balanced and well-judged opinion.
I also met my good friend James, Life Coach, mentor, Oracle. He introduced me to what we referred to as "The Good Book". Buy your self a copy. Read it. Share it / buy it for the colleagues you value (and if you are brave, the ones you think need to change...). Many of our conversations put me on the path to who and how I am today. So blame him.
While at Dialog I seemed to find myself in the realms of data exports and became uncomfortably familiar with the ImageSolve file format, hex editors and proprietry tiff formats. And VB4. 16-bit. Yuk.
After 3 years I got my first taste of how technology companies fluctuate in profitability as several of us were made redundant.
Following the initial hit to morale, this event gave me the chance to look at what I'd learnt over the last few years, hone a little.. kick up a pet project to prove it. Second corner-stone:
A pet project does not need to "succeed", or be completed; it just needs to be able to prove a point. Can you do it? Have you learnt anything?
If it can do any 1 thing you proposed it should do, or taught you how not to do something, it's a pass.
After a few months even the best intentions wane, motivation slows... so it was probably for the better that I finally got a job with BAC. This was an in at the deep-end appointment - pre-existing software to be maintained and expanded upon on the PocketPC format. The application was written in embedded VB, the only option at the time bar c++ if memory serves. As hard as it may be to believe, eVB was the worst language I've ever used. 16-bit VB4 was a positive technological powerhouse in comparison. This pain was not just my own though, Anthony shared this hellish language with me; a fact I'm grateful for. Third corner-stone:
No one developer can seriously expect to see, or be expected to see, all the angles.
While adequate for run of the mill coding, solo work reduces in effectiveness when trying to locate issues or formulating new functionality (though obviously this is only at its best in a team that respects each other).
After a year it became clear the Microsoft was killing off eVB so I lead the move to .Net and the Compact Famework.
Here I learnt an important lesson - numbers sometimes lie.
They're like street magicians, illusionists and fortune tellers - they give you information in an openly interpretable context and allow you to make conclusions that fit with your expectations. They then play on those expectations to either make you look a fool or convince you to part with additional money to perpetuate the situation. My case and point are, from this specific example, PDAs (though the same could be said now for smart phones and tablets). Their numbers imply a similarity to their more classical counterparts (laptops, desktops), but try to use those numbers in that same context and it all starts grinding to a halt.
Bottom line is, in my opinion, take note of the numbers but use your head. Scale your solution to fit, rather then try to make an application that runs on a desktop of "similar" specification to fit a space that claims it is equivalent, but actually isn't.
And so came my second shin-dig with redundancy. No reflection on BAC, it's just the way things go some times.
During this stint at my own leisure I found myself in a situation where I could look at PHP.
[bone-head, bone-head, BONE-HEAD!]
It was an attempt to put a site together for Debbie. I finaly settled on Zen Cart, a template oriented PHP e-commerce system and found that I really didn't like it. Perhaps I was trying to achieve too much in too short a time but at least I took the chance to try it, even if it didn't work for me.
Once again, my "free break" eventually came to an end as I got a job with MMCC. With the promise of VB.Net development, my first work was on VB6 COM+ components. Within 6 months I found myself in France no less, on site with the Customer. They were a tough few days, from which Darren and I emerged victorious.
[Them - merde!]
[Us - Vive les geeks anglais!]
My struggling to order a beverage with breakfast, however, did remind me of Father Ted when Mrs Doyle went on holiday for a day; steam and smoke billowing from a cooker to the pained cries of "All I want is a cup of tea!"
It was at MMCC where I got my first proper taste of running a project and leading development within a 2-man team. It switched between solo working and a home-grown twos-coding approach which in my opinion worked really well.
It was my next project though that was the game changer for me. It took me into truely uncharted territory - Visual Studio 2008, Framework 3.0 and WPF... all of which were still beta at this time. It's not something I'd wholly want to do again as the unstable nature of beta caused me many set-backs of lost code though project corruption and numerous issues with 3rd party controls also in beta, made with beta. The way the development worked was also new - rather than elicit requirement, design, submit, this was far more dynamic where things could change on a daily basis as we (the Customer and myself) learnt how the concept was evolving - some things worked for us, others didn't.
Looking back over this post, perhaps this does double up as a story about cataclysmic events and change; each event / set back has caused me to dig my heels in deeper and come up with better the next time round. If I was still at British Telecom no doubt my mind would work far differently to how it does now.
In some respects, some might have been considered to be a good thing but on the whole I think I'm better for being where I am - without the catalysts I'd never have learnt or seen that which I have and I have been very fortunate, to date, to have worked with the most precious commodity in IT today; ego-less developers. People who look to achieve quality in the product over that of propelling themselves above others, teach others at no cost and learn from each other without taking advantage of their teacher.
So. This is all what I r done. So what r I doing now?