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

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.

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).

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.

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.

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.

http://statisticsio.com/Home/tabid/36/articleType/ArticleView/articleId/202/categoryId/22/What-Makes-a-Great-Database-Professional.aspx

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.

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.

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.