Brent Ozar wrote his Things you know now and in it he says this under his first point, Pick one thing and get really good at it:

"I’m not saying you should stop learning, but you should focus your learning on a very small surface area, and dive deeply into that subject.  At the end of ten years, you can either be a junior guy in half a dozen languages, or a very senior guy in one.  Guess which one is worth more money. "

I've heard this a lot and from some very reputable people. But given that my life goes against this philosophy, I figured it was good to write a counterpoint to this idea. Most folks that know me know that I've switched from being primarily Active Directory services and server / enterprise security to being "just" a development DBA working with SQL Server. As I wrote in a Twitter post yesterday, my switch back was a "return home" of sorts. I first started working with SQL Server 6.5 in 1997 and progressed from there to the most current version, 2008. But during this whole time, I've actually spent relatively little time being a SQL Server DBA as my primary job responsibility compared to my other duties.

I've actually spent most of my time since I was introduced to SQL Server in the systems administration world. But I kept a developer skillset that I had pre-dating my days with the USAF (and have gotten my foot in the door with my current organization because of it). While I don't consider myself a senior developer today (much less an "application architect"), I know that if I worked at this for a bit, I would be back up where I'd like to be as a developer. A lot of it has to do with just day-to-day working with code. One of the reasons for the switch to being a DBA again is to be able to touch code again. I miss it tremendously. Little scripts here and there to perform administrative tasks just don't count. But one thing I've done at each step is I built on my SQL Server knowledge, even if it wasn't my primary duty. While I always made sure more attention was paid to what my primary duties were I have tried to keep up where I could in SQL Server, because it was what I was most passionate about. So why didn't I ever stop and specialize? Two reasons. The first one is more obvious, but it's not the most important reason.

Reason One: Employability and Flexibility

When I stepped out of the USAF, I tried to find a job as a youth pastor. I couldn't find one that paid enough to feed my family. Not without a masters degree and ordination (and in Baptist circles, you usually get your ordination as you go to your first full-time ministry position). So I had to go back to IT. No income for two months meant I needed to find a good job and fast. One of the things that gave me a leg up was I could compete with other candidates as a developer, a SQL Server DBA, and as a Windows-based system administrator. The first really good job to come along was a system administrator job. So I grabbed onto it, made a friend for life, and was back in IT.

Where I currently work I have served as a developer, as a DBA, and as an infrastructure architect. I'm back as a DBA. I have been able to flow through all those jobs, find promotion opportunities, work on exciting projects, and grow because I've kept a broad skillset. I'm back as a DBA because I never gave up my DBA skillset. I could have specialized on AD and servers, but, well, I will always remember being out of work and needing a job. I want to maintain that flexibility.

Reason Two: Integration and Understanding

Having a diverse skill set means I can see the pieces I need to see and how they work together. From a troubleshooting perspective it means I've often been able to go right to where a problem is because I can look at the symptoms and rule out pieces of the architecture. For instance, a developer came over yesterday asking me about a 500 response error they were getting intermittently on one of their apps that talks to a remote web site. I've been a web admin. A 500 error is an internal server error. So as they used to say in USAF tech control, "The problem is at the distant end." He was wondering if it was a server or network problem on our side. No. We're talking to the remote server and it's throwing the error. The fact that he's getting the error is showing our network and server is fine. That quickly got him focused and calling the service provider.

It means I can provide solultions which are a better fit than what may be proposed. For instance, a question came up about creating a linked server from SQL Server to Active Directory. Yes, that's doable. Do I like that approach? Based on what they were trying to do, no. They wanted to import users and user information once a day or so. Better to use a script and ADSI or maybe use a .NET console app and System.DirectoryServices.Protocol. I gave them some sample code using VBscript and ADSI that did the trick. It was modified from when we had to a global update to users.

And I am saying me, but the folks that I've worked with who have had a similar philosophy about being diverse have had similar results. For instance, when I was leading the Active Directory implementation, my right hand man was Jeremy Brown, who was a part of our organization as a, you guessed it, SQL Server DBA. We didn't overlap as DBAs, either. He was hired after I went to servers. But Jeremy had an integration background where he did development, system administration, and DBA work. The running joke was we were the primaries working on AD because it was a "database" and that meant DBAs.

What I'm Not Advocating

Brent makes a good point that if you flitter back and forth between different technologies, never getting deep in any of them, you'll always be a junior. I agree with that. At every stop I have always focused the bulk of my time on whatever my primary responsibility was. If I was a web developer, it was on web technologies. When I was implementing AD, I spent many an hour reviewing LDAP, DNS, Kerberos, as well as the Microsoft details on Active Directory itself. I think there's a lot of value in learning how something works under the covers if you work with it every day. And when it starts touching other areas, learn how those interactions work. One of the reasons I know a lot about SQL Server and Kerberos in Active Directory is because that's one of those touch points. So I believe in going deep and focusing a lot of energy in the primary job.

But Don't Forget Other Areas That Drive Your Interest

And that gets back to the point of this post. I have loved SQL Server since I started working with it. I have always set aside some of my time to keep up with it. I installed it. When there came opportunities to use it in the course of my normal duties, I dove in with both feet. That's how I developed a SQL Server DBA skill set in the first place. It was through the work I was doing as a system administrator and as a developer. Even areas that weren't directly related to what I was doing, I looked into. For instance, we don't use Credentials and we don't use SQL Server Agent very much where I currently work. But I still looked into them, tinkered with them, and considered how they could be applicable. The same goes with encryption in SQL Server when it first appeared in the Yukon betas. It would be several years before I actually saw it put in an application implementation. But I was able to provide guidance to a group of developers and the attached DBAs on what to do and not do and how best to do it in SQL Server. By the way, part of that knowledge came from what I've learned about Public Key Infrastructure as part of what was, at that time, my primary responsibilities (which reinforces reason two).

So I understand the recommendation to specialize, but I see a lot of value being a jack of all trades. The traditional usage is, "Jack of all trades, master of none." However, I like Adam Savage's characterization of it, "Jack of all trades, master of none, though often better than a master of one." And, by the way, Brent, by your own words, you aren't a specialist either. 🙂