Argenis Fernandez put forth the T-SQL Tuesday challenge this month with the topic being specialization. He asked us to write about specialization in our own jobs and careers, and asked if we should specialize, or why we don’t.
My answer in regards to my own career is the same as the advice I would give someone else. Do indeed specialize in technologies you have a passion for and that you want to work with most of the time. Become ‘the expert’ that we go to when we need a solution in you area of expertise. It will make you more valuable and it’s satisfying to be able to make the most of that knowledge in a useful way. However, be flexible and change the specialty often since some things we do in this business disappear (they’re destroyed by newer technology), while new things become viable and mainstream. And finally, don’t specialize at the expense of being a knowledgeable generalist.
When I started my career in the mid-80s I worked on IBM mainframes and IDMS databases. That’s when I first acquired an interest in database architecture, performance, and data mining. I liked the work and it was challenging, but even then I immediately started doing what I could to move myself away from that technology because I knew it wasn’t the future. I know someone who still works in that same environment. He’s always employed because nobody wants to work on old technology, but I wouldn’t want to be him.
I’ve changed the technology specialty I work in at least 4-5 times throughout my career. Personally it’s important for me to stay close to the leading edge no matter what role I’m in, whether it be consultant, manager, architect, or coder. It’s what keeps things interesting. In the SQL Server world I’m glad that we haven’t yet hit the ceiling with the product and there’s still room to grow. It will continue to grow and mature for the foreseeable future, but we have to be vigilant as technologists who work with it. There are specialties we’ve developed in using SQL Server that will be retired and/or replaced in the future, which is the natural life cycle of such a product. Also, we have to be aware of what’s going on outside the SQL Server arena so that we don’t become obsolete, and so we know when alternative solutions are better for the task at hand. I wrote another post several days ago after the launch of SQL Server 2012 that made a reference to the revolution that’s already taking place in the world of data and that it will continue to be in a rapid state of change for years to come. I’m committed to staying ahead of the curve so that in the year 2015 and beyond, I’m not that guy working on the old, outdated technology.