K. Brian Kelley wrote a counterpoint to my recommendation that DBAs should specialize and focus their training. I respect Mr. Kelley a lot: he’s been in the United States Armed Forces. I don’t want to run into him in a dark alley. He’s a nice guy, and he’s got a lot of integrity, but that means he’s just going to give me a ten second running head start before he kicks my geeky rear. I’ve seen Burn Notice. I know how this stuff works.
With that in mind, I’ll explain it another way.
As a former homeowner, a wannabe furniture-builder and DINK (dual income no kids) household, I’ve accumulated a fair amount of tools. I’ve got saws, drills, hammers, allen wrenches, routers, all kinds of electrically powered Man Gadgets. I know how they operate, and I can say with a fair bit of certainty what tool I need to grab when I’m looking at a project.
My work with these tools is marginal at best. I won’t hurt myself or the ones I love when I fire up the rotary saw, but my work is never going to be sold for profit at a furniture store. Not even Goodwill. My stuff is the kind of stuff you see marked “As Is, All Sales Final.”
However, if I walk into your garage and I see you handling the hammer by the metal end, and using the wood end to pound a nail into a board, I will suggest to you that you try turning it around for better results. (Unless you’re a former member of the Armed Forces, in which case I’ll offer to hold the nail for you.)
My IT experience is pretty similar. I can walk into IT shops or project meetings, listen for a few minutes, and tell who’s handling the hammer by the metal end. That doesn’t mean I know how to do their job – but it means that I can tell they don’t know how to do it either. In IT, that’s a lot of what a DBA has to do. He doesn’t necessarily need to know how to program a .NET application, configure a firewall or lay out a report in Crystal, but he’s seen enough people doing it that he knows who’s doing it wrong. We absorb things because we’re around so many different IT specialties.
When I recommend that DBAs specialize, I’m talking about the things that they choose to learn. They’re going to learn a lot of other things by accident or by osmosis, and that’s great – it makes your experience even stronger. But those things will come regardless – I wouldn’t choose to spend time learning how to do those things if I could avoid it, and instead focus on my core competency. (Man, I hate that phrase.)
18 Comments. Leave new
My point is I have found great value in being more than just one job function. For instance, someone being a DBA, but also having had the experience in and having the skills for, say, a penetration tester or a project manager. Diving deep in more than one area. We see this a lot where you have system administrators with Cisco networking backgrounds (a couple of the guys I work with). Or developers who are also capable of being DBAs (like Robert Cain or Kevin Hazzard). In your own case, you're a DBA who could probably go and be an organization's lead SAN administrator or storage architect. It's related to a DBA role, but then again, it's far larger than a skillset belonging to a DBA.
You bring up a great point: I think it's fine to use guys like Robert Cain or Kevin Hazzard as ideal, top-notch examples, but when you're just getting started, don't try to be Robert Cain or Kevin Hazzard. That's probably the best way I can say it.
I agree with you here. You've got to start somewhere and build up a skillset in one area. Trying to be too diverse too fast means you become a trampoline, since I'm into the word pictures right now.
Very interesting exchange. Before starting, I will say that I am more like K. Brian Kelley, in that I have bounced around in the areas of development, system admin, and SQL Server.
I don't think the decision is really an either/or choice though. Brent is in a position where being a specialist is valued and needed, and there are those kinds of positions around. I would submit that there are likely more positions that having a well-rounded skill-set makes one attractive to hire.
Also, the size of the company matters a lot. Large companies are much more likely to have much more targeted positions that would prefer deep knowledge in just one or a few areas. The smaller companies generally would prefer breadth of knowledge, as they tend to call on their DBA for anything involving data. DBA, ETL, BI, SQL Development are all part and parcel of their daily duties.
Like K. Brian, I think having the developer background makes me infinitely more valuable as a DBA. I see both sides of any argument, from both the infrastructure (DBA) perspective as well as the applications (developer) perspective.
This whole discussion is analogous to what goes on in Nature. The more primitive forms of life can live anywhere and make a decent living. The old saying is that only cockroaches will survive an apocalypse, but that isn't true, only bacteria will. So, by their very nature, primitive forms of life are the most adaptable, and can always survive somewhere.
However, higher forms of life specialize. They live more fulfilling lives; wouldn't you rather be a Cheetah rather than a bacterium? However, with the threat of climate change, habitat destruction, etc the Cheetah is much more easily wiped out than bacteria. The Dungeons and Dragons world is similar in that you can be a specialist or a generalist.
Anyway, this is also how it works in the IT world. Right now, I'm a generalist and am in demand at any company who requires my skillset. I'm not that concerned about the economy because there are tons of companies who need it. I am closer to a bacterium at this point. As I have been shifting towards SQL and specialties within that world, there are fewer companies who would be interested in me. However, those companies would offer better compensation to keep someone with those specialties.
I intend to make a compromise. I will likely never be the best T-SQL writer in the world in the mold of Itzik Ben-Gan, or the world's foremost SAN expert etc. However, I intend to pick a few specialties, get very good with them, and hedge my bets.
That's it: "core competency". @kbriankelley's point is to go horizontal which make you marketable, to which @DavidStein agreed. But @BrentO's new meaning of Specialization, which is "core competency", is just brilliant! @BrentO is saying, to an effect, that, "go horizontal whenever you have the opportunity, but maintain a core competency". That way you've covered both axes. @BrentO's has just redefined the rigid meaning of Specialization. Specialization makes any company vulnerable and inflexible. But if you have people with shared knowledge and "core competency", that makes you, as a company, a winner!
My point is to do more than go horizontal. My point is to intentionally deep dive on multiple technologies. To put it in visual terms, Brent is saying be the octopus. One big lump representing your core compentency but putting tentacles out wherever you're interested. My viewpoint is multiple octopi, a bit smaller, where some tentacles touch and others do not.
Mmm, fried calamari.
We should do a PASS career development session between the two of us and each present our sides, like a pros and cons kinda thing!
And we should fling cephalopods at the audience. 🙂
If I lived on an island that only had pigs, I could have bacon.
If I lived on an island that only had chickens, I could have eggs.
But If I visited both Islands from time to time, I could have bacon and eggs. Mmmm. The whole is greater than the sum of the parts.
I am a better administrator because I am a developer. I am a better developer because I am an administrator. IT, and our world for that matter, is a system of systems.
Go! visit the islands! And enjoy the bacon!
Just stay away from whale bacon.
I did that line! “Go! Visit the islands! And enjoy the bacon!”
I meant to say, I DIG that line: “Go! Visit the islands! And enjoy the bacon!”
IIRC Richard Feynman could look at someone's attempt at virtual any integration and tell at a glance if it was wrong. Not that he could tell you the right answer, just that what you had wasn't it.
Very interesting exchange. Before starting, I will say that I am more like K. Brian Kelley, in that I have bounced around in the areas of development, system admin, and SQL Server.
I don't think the decision is really an either/or choice though. Brent is in a position where being a specialist is valued and needed, and there are those kinds of positions around. I would submit that there are likely more positions that having a well-rounded skill-set makes one attractive to hire.
Also, the size of the company matters a lot. Large companies are much more likely to have much more targeted positions that would prefer deep knowledge in just one or a few areas. The smaller companies generally would prefer breadth of knowledge, as they tend to call on their DBA for anything involving data. DBA, ETL, BI, SQL Development are all part and parcel of their daily duties.
Like K. Brian, I think having the developer background makes me infinitely more valuable as a DBA. I see both sides of any argument, from both the infrastructure (DBA) perspective as well as the applications (developer) perspective.
Yes, being too diverse with no depth is a puddle you don't want to step in. (word pic for K. Brian)
Either: a) Jack-of-all-trades master of none, or b) one note. Those are the two extremes. You can make a case against either one depending on how you want to exaggerate them. There are plenty of people who fit the stereotypes of both, but ultimately it just comes down to stupid vs not stupid. If you've got someone using the wrong end of the hammer, it doesn't really matter if they specialize or not. Those people (the majority in any field, really) are going to use the wrong end of the hammer no matter what. If you give them a saw, they'll just use the wrong end of that.
In any case, assuming you've got people who know what's what, whether it is best to specialize really depends on your job — and the type of job you want. This is sort of like the developer-DBA, programmer-sys admin, coder-designer, windows-linux splits. Anyway, the danger of over specializing is that you start to think that your specialty is 'all that really matters.' Which is fine in a very specialized shop, but most organizations aren't like that. You should play to your strengths, but all things being equal I'd rather hire a smart person who has a broad range of skills than a smart person who is an expert in one thing.