THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

James Luetkehoelter

Nearly any SQL topic presented at times in a slightly eclectic manner.

A counter-counter-counter(?) argument: Specialization vs Generalization

This post is a reply to a reply to a post from Brent Ozar from K. Brian Kelly. The basic argument going on is that you if you want to be successful in the future, you should:

1) Specialize in a specific area


2) Generalize and gain as much exposer to as many technologies as possible

(This are overy simplifications of both views, I do this just for the sake of the argument)

My own view is that both viewpoints are incorrect. The key to maintaining your marketability in the future is being both a generalist AND a specialist. And to make the argument more confusing, the specialist part will shift continually.

Example 1: The pure specialist

Let's say person A is extremely adept at RGP programming for an AS400. Right now, that remains an excellent skillset as far as hirability. However, perhaps 5 years from now IBM abandons the AS400 platform altogether and moves to a Unix-based, or MS-based or 3rd-party OS to go along with its hardware. RGP is gone. Now everything is writting in IBM-SQL, or IBM-Java, or something completely different. Now person A must completely retool just to get a job. Or, change professions all together. Yes, there will be the legacy shops that are reluctant to change, but that work will last only so long. And with today's economy, can anyone rely on retirement anymore?

Example 2: The generlist

I fall a bit into this area. I know an aweful lot about datababase systems, network, servers, business process, etc. (and I mean etc., I have a wide range of exposure). However, without focusing on specific area, I limit my usefulness. Let's say I'm hired to work with SSIS. Yes, I know it, and pretty well. But the really esoteric knowledge - know - I have to look it up. It doesn't matter to my employer that I'm answer questions to others in IT about SQL Server in general, suggesting different security schemes, interacting (successfully) with other business groups, identifying concrete business rules that previously remained ephemeral - if fix the very specific issues with SSIS quickly (which doesn't rule out Google, but knowing what to look for - Google now returns so much information to wade through, you need to know your subject someone before using it), I'm fired. Period. Fair enough.

Example 3: The generalizing specialist

So let's take how I try to focus, not always successfully. I consider myself a data specialist (as in data quality, efficient reporting, storage, etc) on the SQL platform. I also know a significant amount about programming, SSIS, SSAS, SSRS, operating systems (Windows and Unix), hardware, network, business process, etc. Theoretically I could jump into any job in any area and be productive from the start and become a specialist very shortly. I may need to change my specialization very quickly at any point to maintain my marketability. Right now SQL Server maintains a very competitive piece of the database market. I'm specializing more and more in SSAS, SSIS, and SSRS (also known as business intelligence, a term I despise). But let's say in 10 years Oracle wins the database wars over IBM, MS and open source. I also know the Oracle platform and continue to try to follow it. By generalizing a significant amount of my skills, I keep a foothold into other technology areas to have the tools to cross over faster than the COBOL program in Example 1. And unlike the Example 2, I've demonstrated the ability to be a specialist and have more credibility if I build my Oracle skills ( in this fictional example :) ) and proclaim myself an expert. Heck, I can probably take many of the things I've learned as an expert into the new area.

I believe Example 3 is the way everyone should view their career. Another great example is language. Most of us on this site are "experts" (if you're from Great Britain you'd debate that) in English. But what if most of the business out there comes from China? Wouldn't be in my best interest to become as proficient in Mandarin as possible? What if most of the work moves to India, and India now decides that business should be done in Hindi rather than English as it is now? Shouldn't I learn Hindi? How about Quebec conquers Canada, and becomes a superpower? Shouldn't I learn French (or as the French would say, Quebecois)? Adaptability is important. Now if I had to learn these languages from scratch as things change, I have a huge hill to climb. Luckily I study languages, including French, Hindi and Mandarin (and 3 others - I'm trying to surpass my father who spoke 9 languages - for the most part, fluently). Now right now I stink at most of them (French is my most fluent), but I have an advantage over others should China take over the world. Don't I?

Specialization and generalization can *not* be mutually exclusive. I would advise those entering the industry to learn as much as possible, while attempting to focus on a specific area. Yes, you may not have the depth in a specific technology like our RPG programmer in Example 1, but you should be able to handle 90% of what comes your way and have the knowledge to find the answers to what you don't know off the top of your head.

That's my take. Am I wrong? Crazy? Just drunk?

Published Saturday, February 14, 2009 3:05 PM by James Luetkehoelter
Filed under:



K. Brian Kelley said:

Actually my argument is not for being a total generalist. It is to deep dive on more than one technology area. In my case I have focused on SQL Server, Active Directory, and enterprise security.

My argument is closer to your #3, but only the way I've approached enterprise security follows that line of reasoning.

While I realize that means you lose a little depth, I think you gain more of the overall picture of systems and applications. Also, it gives you more options in hob choices.

But to say I represent the generalist camp isn't really accurate. Being spread broadly across a bunch of technologies may mean you are ideal for small companies who needs someone who can do a bit of everything. But you aren't going to find the more engaging jobs in your reach.

February 14, 2009 4:40 PM

James Luetkehoelter said:

Sorry Brian, I tried to bring that out by saying I was over-simplifying. I know you aren't in generalist only camp. So to everyone read this, I recant saying Brian is generalist only. I only wanted to share my thoughts on the matter.

However, I would say that your stated focus (SQL Server, AD and enterprise security) isn't that much a deep dive in one technology area. Well, ok, technically it is. But it follows a general theme - security. I would always defer to you on SQL Security.

What I'm suggesting is that one spread into other logical areas like this, not necessarily technology. How about data analysis, or performance or disaster recovery? Or development? I would argue in order to remain competitive one must at least be conversant in as many topics as possible. Does that mean a lot of work - of course. But I have a feeling that no one really knows what to do with technology, and it is still a good 20 years before job roles settle in.

That being said, I do agree with your position. And my apologies again for inadvertantly painting your argument as the generalist. I know better :) Should have written that way as well :)

February 14, 2009 6:36 PM

James Luetkehoelter said:

And likewise, I wouldn't dream that Brent would be advocating "I only do SQLCLR work" type of specialization :)

February 14, 2009 7:37 PM

K. Brian Kelley said:

I think Brent and I discussing it out via posts and twitter has shown that we're very similar in our positions, though we are speaking to two different levels. Brent's point is that when you're first starting out, you need to get good at something. Hopping to each new technology means you gain no depth, and that hinders your advancement greatly. My point is you don't stay there. You start to expand your base. In my case, it was deep diving in several different areas. For instance, understanding AD is more than just the security model.

Actually, AD is a good example of my argument. To know AD well you'll end up knowing the Windows security model, but you'll also have to get good at DNS, LDAP, and Kerberos. You'll also have to understand the replication model, which lends itself to knowing how to recover AD, what happens when you use virtualization for DCs and don't plan proper recovery mechanisms, etc. So even though you may start in one aspect of AD, you could end up knowing a lot of diverse topics, some of which would applicable elsewhere (such as DNS, LDAP, and Kerberos).

February 15, 2009 1:58 AM

Brent Ozar said:

Well, Brian's going to snap my neck for saying this, but his line of "I have focused on SQL Server, Active Directory, and enterprise security" probably sums up exactly what I think DBAs should avoid when they're starting out.  Pick one thing, and if you have to tie three phrases together to explain your focus, that's not one thing.  Even just a one thing as big as SQL Server is too large - very few people have the luxury of spending enough time to learn all of the aspects of SQL Server from the engine to SSIS to SSRS to SSAS to .NET CLR to performance tuning and so on.

Brian and I both agree that when you get to the point in your career where guys like us are at, sure, we've branched out into other areas.  I spent 6-7 years focusing on just the SQL Server engine, and then in the last couple of years I branched out to storage and virtualization.  I wouldn't go apply for a pure storage job or a pure virtualization job that didn't involve SQL Server.

If you're just starting out, don't try to pick the 2-3 things. Pick the one thing first and get to the point where you're really comfortable with it.  When you get to the point that you're writing articles and tips on it and people are paying you to do it, then yes, you should be branching out into other areas of study.  Until then, keep your head down and press on.

February 15, 2009 7:04 AM

James Luetkehoelter said:

Actually Brent, I sort of disagree with you here. I'm feeling two different scenarios that the three of us (among others) are arguing:

1) What you need to do to remain competitive in today's market

2) What approach should you take when getting started in the industry

As far as 2, I see your point, but I wouldn't say focus on a technology, I would say focus on a *job role*. The traditional "production" DBA, a database designer, development, ETL, etc. I don't see how it is possible to get into anything without starting to touch a large number of technologies.

For example, if I'm new out of school focusing on being a SQL DBA, one thing I better learn quick in order to troubleshoot connectivity is how TCP/IP works, what TCP ports are, the basics of routing and the role of firewalls. Of course this won't be deep knowledge, the deep knowledge will be how SQL Server "connects" to networking, but it is critical to be at least conversant to be able to ask the network administrator for the appropriate TCP port to be opened (I've run into newer DBA's that ask for NETBIOS to be open to used Named Pipes - no firewall administrator would ever open that to the outside word, that's a firing offense).

Now with Brian's example of AD, and how it leads you to DNS, LDAP and Kerberos also concerns me a bit as far as a recommendation for 2), and sometimes 1). Really understanding AD is a long process - to specialize in that area is quite wide, and only someone with a very strong background can tackle that. I would perhaps argue that someone might be a security specialist with SQL Server, and when it comes with AD is conversant in all of the various topics involved (especially Kerberos vs NTLM authentication). That's the sort of generalizing specialist I'm advocating.


February 15, 2009 11:30 AM

jchang said:

My opinion, you need to think about the size of the company you want to work for (in terms of IT or developer staff). If its a really small company, then you need to do everything, not necessarily very well, just enough to get the project delivered on time and on budget. As the target company is larger, there is better ability to accommodate and benefit from specialization.

Of course, I do not think it makes sense today for one person to try to learn duplicate skills as in SQL Server and Oracle, or .NET and Java, just pick one set, ie, SQL Server, .NET, and Windows OS, or Oracle, java and linux OS for example.

If you are so narrowly specialized in single area, then there might not be a good role in any size company, in which case you should be a consultant.

Of course, it would help if non-super narrow specialist people understand they are not masters of every narrow field, and that a consultant should be brought in. I am almost never brought in at the initiative of IT staff. It is always by the non-technical managers that finally get fed up with lack of progress. Then it looks really bad (for internal IT staff) when a long festering problem with severe impact is resolved relatively quickly.

February 16, 2009 10:31 AM

Jason Massie said:

I wrote about this a while back. Someone happened to comment on it as well.


Really good DBAs are jacks of all trades. They get on a conference call or go into a meeting, and within a few minutes, they can identify where the real application problem is (network? storage? app? database?) and show some basic proof.

Those kinds of DBAs are like practical versions of architects. You call in an architect when you're planning, and you call in a DBA when the plans didn't work out the way you planned. (Or at least, that's the attitude companies seem to have!)

posted @ Tuesday, July 29, 2008 9:13 AM by Someone O.


I agree with #3 and someone's comments.

February 16, 2009 10:07 PM

K. Brian Kelley said:

Actually, Brent, I would agree that when you start out, you should focus on one area. But over time, it makes sense to try and understand and gain depth in other areas. Like the example given, if all you can do is tell my whether or not my T-SQL is good or bad, but you can't troubleshoot at the app or TCP/IP layer, then you're of limited usefulness given today's complex systems. And given that the first thing that's pointed to for trouble is the database, if you can't prove it's at another layer, you're always going to be on the wrong end of the blame stick.

February 16, 2009 11:50 PM

Brent Ozar said:

I think we're all on the same page, but the difference is where we see this at different points in our careers.  Jason Massie hit the nail on the head when he said "Really good DBAs are jacks of all trades."

Exactly - really good ones are.  But you don't start by being a really good one - you start at the bottom and work your way up.  I can't tell you how many junior DBA job candidates I've interviewed who couldn't even explain the difference between a clustered index and a primary key, let alone troubleshoot TCP/IP.  I'd be thankful to find job candidates who even understood the basics of the engine.

February 17, 2009 8:38 AM

Jeremiah Peschka said:

When I first started out in IT, I had no idea what I was doing. In part because I possess a degree in English and got interested in the field after I graduated because I wanted to build my own website (back in 2000/2001 we didn't have classy things like wordpress).

After stumbling around the IT space for a while, I started to specialize in a conceptual area - information visualization - and have now come around to specializing in SQL Server as a platform for information delivery, largely through T-SQL. But that initial period of feeling my way around, I touched just about every major technology at the time apart from Java. Honestly, I feel that my attempts to gain a great deal of knowledge really held me back from attaining mastery of a single technology.

When new grads ask me now about what they should do to further their careers, I tell them to follow their passion about a specific concept, but to also specialize in a particular technology. It doesn't help anyone if you can half-assedly create simple information visualization schemes in half a dozen languages.

Ultimately, the path I've taken is to focus on one area - SQL Server as a delivery platform - and learn what I need to learn as I've moved toward mastery. So, when that TCP/IP problem eventually crops up, as K. Brian Kelley hinted at, I'm going to get with my networking guys, bribe them with lunch, and work with them to understand what might be the problem and track it down. Although my approach probably won't work well for people in larger companies where the networking people might be located across the continent (or on another continent), but it works well for me.

February 17, 2009 8:48 AM
New Comments to this post are disabled

About James Luetkehoelter

I am passionate about what I do - which is DBA, development, IT and IT business consulting. If you don't know me, haven't met me or have never heard me speak, I'm a little on the eccentric side. One attendee recently described me as being "over the top". Yup, that about says it - because I only speak on topics that I'm passionate about.
Privacy Statement