"Certainty of death ... small chance of success ... what are we waiting for ?" - Gimli, Return of the King
The second Tuesday of the month invariably means that it's time for T-SQL Tuesday again. Last time I participated was January and I promised all sorts of things for resolutions like attending my local User Group meetings (0/3 so far this year), updating my blog at least once a week (6 weeks since the last post) and reading more books this year than I usually do (doing OK on the fiction front, need to catch up on the tech books though). So, this month I decided to jump back into the pool and at least post something for T-SQL Tuesday.
Argenis Fernandez(blog|twitter) is the Maitre d' of our blogging hotel this month and he's asked us to talk about what we specialize in, if indeed that's anything.
Jack of All Trades, he posted as the title of this month's event. I've been working in Information Technology for over 25 years. Looking back over my career, the title "Jack of All Trades" probably fits me very well.
I started as a mainframe COBOL programmer back in the mid-80's and did that for several years. In 1991 I left my government job and joined the development staff of an Australian ERP Software company. Today, a little over 21 years later, I'm still working with their software, but my role has changed significantly.
It was with this company, after transferring to the USA that I started getting exposed to databases. Our machines were hosted out of Australia, our DBA support was Australian based (which meant if we had problems we got support starting around 3PM) and so I started teaching myself Oracle. After several years of being the "go to" guy for "in a pinch" support earlier than 3PM, my boss gave me the chance that changed my career direction. He was going to let me transfer and become an Oracle Database Administrator.
That was 12 years ago and I've loved working with them ever since.
However, owing to the niche environment I work in (I'm now working for a small consulting firm that supports this ERP product), I've found myself in an interesting place.
Because of the knowledge I have of the ERP product and the environment it runs in, I'm very much a generalist in what I do. Four years ago, I was forced to learn SQL Server. I'd pushed back against that for years but finally had to succumb to the inevitable.
The software package tends not to use a lot of the advanced features of the databases it runs against. The data isn't necessarily considered up to the second critical (such as for banking transactions) and in the event of problems, some down time can be tolerated.
For Oracle, for example, Real Application Clustering (RAC) isn't used in this environment. So I don't have those skills (and the few times I've looked at the job market, just to see what's out there, everyone seems to want it).
For SQL Server, I've never had to deal with clustering, or log shipping or replication.
Because of the specific requirements of my job at the moment, I'm very much a generalist (I do Oracle, I do SQL Server, I do Unix Shell and Windows CMD scripting, I still fall back to my COBOL roots as needed from time to time too) and for me, at this point in my career that's not a bad thing.
Does this mean I don't want to learn these other more specialized aspects of the various RDBMS systems I work with ? No. However, when you have to balance available time with what's needed for day to day operations, sometimes you don't always get what you want.
So for now, I am perfectly happy in what I'm doing. I love my job. The "restrictions" on not being a specialist in any particular field have not held me back any at the moment. Having such a broad, generalized knowledge base, when working in a very niche field has actually been very helpful.
It could actually be said, come to think of it, that I'm a "specialist" in the technical area around this particular product I've been working with for the last two decades, while being a generalist in the underlying technology (the databases, the operating systems etc).
One of the things I have found in working across so many diverse areas is a need to keep some good notes about the things you learn (so that 2 years from now when a problem pops up again, you have a reference), and that there's always something new to learn!
The bottom line is that for me, generalizing across many areas has worked very well. Reading some of the other posts, I've seen that a lot of people tend to end up in one area and that doesn't surprise me. For me, being a Jack of All Trades just hasn't been a bad thing :)