The last time I was pidgeonholed as a Software Engineer I was a permanent employee back in 2001. Since then I have worked as a contractor addressing quite varied requirements. Strangely enough I feel more like one now than I did then. How come?
Looking back to when I was a SE, I focussed intently on detail. By then my domain, or should I say my comfort zone, was C/C++ on UNIX. Actually with a history well back into the ’80s that was merely a snapshot. I had, after all, already addressed a range of platforms and languages.
But, becoming a contractor meant that I had to relinquish the bridge building techniques that I had honed. By that I mean that I could not keep relying on techniques that I had reapplied many times, nor indulge in the focussed re-skilling phase to settle into an established project and product.
No, I had to start more projects from scratch. NOW THAT WAS THE DIFFERENCE.
As a contractor one has to arrive at a site and start adjusting, solving, and creating all in one go. I think recruitment agents like to call it “hitting the ground running”. From my perspective it is often the “You want what? By when? You’ve been doing what? Now sit down and listen up” :-)
What I now know and revel in is big picture stuff! I no longer recall the subtle differences between the C/C++ ISO and ANSI standards manuals, nor the subtle ways of casting memory pointers whilst using different UNIX debuggers. But yes I can still work it out and do it.
Is that a bad thing? No, back then I couldn’t easily say that the project direction being taken was right or wrong, nor that it would take so long and cost so much, or even that it would take this set of resources beyond myself. At the time that was an SEP (somebody else’s problem).
And now? I would be comfortable to install the development, test and production platforms. Configure a source control system, automated builds and continuous integration system. Architect a solution. Head off, at the pass, the detail mongers and negotiate with the bean counters. Develop prototypes, fix code and refine software process. And yes, all at the behest of a PHB.
If you look at that nice Wikipedia entry on Software Engineering then you will realise that its definition and practice are up to interpretation. I have already said how I personally felt about the lack of a ‘Software Profession’ being a bad thing. But my take on the current fad that is “certifications” is like that of many with a formal qualification and many years of real world experience, that they are just too useless to warrant attention.
Unless of course you are the one charging to dish out these fine examples of education distilled down to a week of cramming.
So if you are a PHB, then you will not be reading this, but for those PM’s (project managers) that need results within a time frame, with a controlled process and an easily identified set of targets with rapid iterations leading to their end goal… do yourself a favour and get a team of “skilled” people with real experience and not a crowd of cheap juniors with a herd mentality who just might know how to do it when you conduct your autopsy (post mortem) on how the project didn’t quite make it.
I woke up this morning with the urge to speak my mind. And now I have done so. Have a nice day :-)
In my mind, being a consultant means knowing who the right people are to answer the detailed questions. The ability to get to the core issues, delegate them, and move on to the next one is a skill that can’t be taught.
It is good to know that when I occasionally vent my spleen, I do not appear like a fool, or at least not an intolerable one :-)
A good friend and colleague asked if anyone actually listened to me (at a large site that we both contracted at). Sadly, in many instances the answer was no. But there were some pleasant wins.
Now that just reminded me of a story, but I’ll type that up as a new post.
Oh, and thanks Jim for your note of reassurance.