It's T-SQL Tuesday time! The 28th installment is being hosted by Argenis Fernandez (blog | twitter), and his chosen topic is "Jack of All Trades, Master of None?". He asks us, "Are you specialized? On something? Or anything at all? Has that been a good or a bad thing? Why? Are you the SQL guy at work? Or the one who does everything? Do you code? And configure wireless routers at work also? If you had to pick one thing to specialize on, what would it be?"

(First, I'd like to congratulate Argenis on asking as many questions in one paragraph as I usually do.)

Second, I don’t think I’m special. I mean, specialized. Yes, that’s what I meant.

My career has featured a mish-mash of job duties and technologies. I started college with the intent of being a web programmer, switched to networking, and then changed again and ended up graduating as a programmer/analyst. I’ve built and repaired PCs. I’ve worked a help desk and done training. I’ve been the .NET programmer, the SSRS report writer, and the production DBA.

When I realized I wanted to specialize in SQL Server, I found a job as a DBA. That’s when I realized my ability to coherently communicate with the Windows team about Active Directory, and understanding what the developers were talking about with classes and source control, became a huge advantage for me. Having a broad knowledge base to draw upon made me better at my job.

Now that I’m a consultant, I deal with far more than just SQL Server. Again, the broad base has helped me see challenges and solutions that I might not have thought about otherwise. I’m better at designing databases because I realize that they will need to be tuned for performance throughout the life of the application. I am able to read through the ASP or PHP code of a website and understand what is happening, so I can improve the queries we’re writing for it. I’ve also been able to see how basic database concepts can be applied to RDBMSs other than SQL Server, such as MySQL.

After working with many systems, I’ve realized that I want to specialize in SQL Server. However, that’s a huge, broad field all on its own. For a while, I wanted to run off with SSRS. Then, I wanted to read and understand everything about execution plans and get phenomenal with query tuning. I took a turn learning as much as I could about Extended Events, so I could get better at troubleshooting performance problems. My current list of things to play with and learn about ranges from partitioning to building a functional SSIS package to writing MDX.

I think my experiences in working with various facets of SQL Server will prove invaluable. Report queries still need to be tuned. All SQL Servers, regardless of their usage, need to be monitored and maintained. Data loads will need to be run. Queries will need to be written. Having at least an idea of how these things can be done will only help me as I move forward.

My advice to people is to continually learn. If there is a project at work that interests you, take it if you can. If there is something that scares you, embrace it and learn about it. Step outside of your comfort zone and your usual tasks, and learn a new skill. You don’t have to be an expert in everything, but knowing the basics will get you further in your career than you may understand.