T-SQL Tuesday #28: Jack of All Trades Crew, Checking In

T-SQL Tuesday—always a good option for helping to get back on the blogging horse.

TSQL Tuesday #28
T-SQL Tuesday #28

This month is hosted by Argenis Fernandez (blog | @DBArgenis), a SQL Server MCM & a #SQLFamily member that I have yet to meet. His topic of choice is “Jack of All Trades, Master of None?”, which is right up my alley, because for pretty much my entire IT career, that phrase has described me. It still does, right this second, but I’m trying to get over that. More on that coming.

Because I should be able to use them to frame out a good story (and because I’m cheap), I’m going to work with the list of questions Argenis has in his invitation post.

Are you specialized? On something? Or anything at all?

Am I anything at all? No, not really, thanks for asking! 😀

Anyway… it’s not really safe or fair to answer whether or not I’m specialized with anything but a firm “no.” I’ve been this way from day one. I don’t know that it’s been a conscious decision to get to this point more than it just happened as a result of being driven by a desire to know how everything works. Sometimes that leads to depth in weird places, which can come in handy while watching Jeopardy! on TV.

My non-specialization situation at the moment includes the capabilities of a decent SQL Server DBA, being what I’ll call “serviceable” when it comes to data modeling, and could still be a sysadmin if push came to shove, in a day job in which I have become the go-to ETL Developer. It’s a little weird, I admit. But, all of those other things help with the current focus. The ETL job is slow, you say? Well, is the server on the floor? Is the latency over the WAN link 700 ms per round trip? All of my other skills help, and that is what I think is the best part of being a jack-of-all-trades: It’s possible to know just enough to answer a lot of your own questions!

I’ve said it before, but another thing I like about knowing a little bit about a lot is you can make friends/commiserate with almost everyone in the IT department.

Are you the SQL Guy at work? Or the one who does everything?

Due to the size of company that I work for, there are very few “Guys” at work—everyone has a specific job (or sometimes jobs) that they do. Basically…near-insect-grade specialization. There’s not room for a jack-of-all trades at larger organizations, in my experience, with the possible exception of smaller, autonomous groups.

Having spent time in one of those smaller, autonomous groups within a larger organization, I was a little bit of the guy who does everything. My whole team was, actually. We were “Windows System Admins”, who ran just about everything except Exchange and the MSFT monitoring platform du jour, plus Citrix to boot. Although each of us had our strong points, pretty much all of us could get through whatever needed to be done and have things work when we were done. I think that just goes along with being a “sysadmin”—being a jack-of-all-trades is almost a necessity. Need to know hardware? Check. Security theory AND implementation? Yep. IIS (Apache as necessary)? Probably. Networking? You betcha. SQL was just one of the things that I did while there, although I did do a lot of it.

Do you code? And configure wireless routers at work also?

Hell no. I mean… not if I can help it. See, when I started in IT for real, I knew one whole programming language: Visual Basic 6. Two classes in school on it, and that was it. I wrote a little print queue viewer/management app while a student (hey, it was deployed on 2000+ machines!), but no real experience. To this day, VB6 is the only real (“real”) programming language I know. Not having a strong coding background does cause some problems occasionally, especially when talking to Developers who are used to DBAs coming up through those ranks. I definitely don’t know much about software engineering theory, and that’s where it shows up the most.

As part of the afore-mentioned sysadmin gig, I wrote a command-line only VB app as an automated interface between a couple of systems, but I’m not exactly proud of that moment, for a number of reasons. The one that applies here is one of the downfalls of being a jack-of-all-trades: it’s easy to cowboy up and do quick-and-dirty things off to the side, because you can. Perhaps even more dangerous: because no-one else can.What happens as soon as you’re done? Well, if you’re not careful, it winds up in Production, and then it becomes a support nightmare; if not for you, it will be for a coworker or the next guy. Either of which may some day hate you when their phone rings at 0300 because the wrong piece of duct tape fell off your masterpiece. I think being a jack-of-all-trades can be a good thing, as long as one of those trades is holding onto whatever processes and standards are in place…and if there aren’t any of those, hopefully one of said trades is coming up with some good organizational processes and standards!

As for the wireless router configuration bit—I try to keep that at home. Pretty sure the network guys wouldn’t like me messing around with those things. Just because I [used to] know Cisco IOS, doesn’t mean I should use it. That brings us to another good specific skill that a jack-of-all-trades should have: Knowing when to sit quietly. This goes for both wireless routers and writing anything in VB6 that has a prayer of ever seeing real, actual production use.

If you had to pick one thing to specialize on, what would it be?

Yeah, about that… All the above said, I actually am going to try to specialize on something. Of course, it isn’t enough to say I’m going to specialize on SQL Server. There’s too much in the product now. I’m going back to the thing that got me truly interested in the prospects of becoming a Data Pro in the first place: Business Intelligence. Unfortunately, I don’t think it’s safe to make that a goal, either. Just the BI side of the SQL Server platform is becoming too broad and too feature-rich to come to grips with. I’m going to have to be content with possibly not knowing anything at all about Reporting Services to focus on what I really want to do: Analysis Services. I actually want to be able to do most of the architecture work surrounding big BI projects, from start to finish (except for SSRS!), but I’m afraid that even just SSAS, including all of its new related technologies, could turn out to be too much.

That, though, is a journey that I hope we can all share in. Because I’m nice like that.

Other Thoughts

Being mechanically wired more than anything, it’s not quite as easy for me to tear down a piece of T-SQL as it is, say, the battery operated toys I used to take apart…Or a carburetor. But thanks to the Internet, it’s easy for me to read about and learn from someone who is more adept at doing that sort of thing. This shows two more helpful skills for a jack-of-all-trades: Being able to read and learn is a really important one, and being able (and willing) to share back out is another good one. You never what kind of DBA trying to configure Exchange you’re going to help out.

T-SQL Tuesday #12: Why are DBA Skills Necessary?

TSQL Tuesday 12

T-SQL Tuesday #12 hosted by Paul Randal

T-SQL Tuesday is being hosted this month by the great Paul Randal (blog | @PaulRandal). This is awesome, because it’s Paul, but also not so awesome, because it means Paul is guaranteed to read my stuff. I’m not nervous about this at all, I don’t know what you’re talking about.

I had a couple ideas for this, and if I had gotten started on this sooner, I probably would have written two different posts. Too many things didn’t work out right for that, so there’s only this one. Hopefully I didn’t choose poorly. Here we go…

So…Why are DBA skills necessary?

Well…because they are!

I mean… Are car mechanic skills necessary? Are pilot skills necessary? Are business skills necessary?

OK, you’re right, it depends. It depends on if you’re planning on rebuilding a Rochester carburetor and having the engine idle afterwards. Or landing a 747 on an actual runway and not bending anything. Or being the CEO of a multinational company and it continue to grow, prosper, and make money.

I don’t think those are extreme examples. Just like the above, if you want to build, support, and continue to improve a highly available, scalable, and performing database system, you need DBA skills to make that happen. Sure, even if you don’t know what you’re doing, you might get lucky and find a washer in the carb’s air horn that had locked the air valves on the secondary bores closed, the removal of which led to unprecedented quantities of burning gasoline, but you can’t run on luck forever.


All these things are hard. I know that rebuilding a Quadrajet is hard, because those things are a pain in the ass. I know that landing a 747 is hard, because it’s a giant airplane that isn’t slow and might have lots of people in the back. OK, technically I don’t know that it’s hard to run a multinational corporation, but I’m pretty sure it is.

Know what else is hard? Databases. Databases are hard.

This isn’t about platforms or anything like that. Databases are hard when they’re Oracle DBs or when they’re mySQL DBs. Databases are hard when they’re Access “databases”, although in a different way (and in a way that’s not hard if your name is Brent Ozar).

OK, why are databases hard?

They require concentration. They require a wide range of technical skills from all parts of IT to accomplish successfully. They require you to know where to look and who to ask when there are things that you don’t know. They require being able to deal with the pressure put on you when things aren’t going right.

Perhaps more so than other areas of IT, when things aren’t going right, lots of people aren’t happy. Databases contain one of the most important assets of their owners: their data. Having this data safe and available in a timely fashion is a requirement if that data is going to be useful at all. Being able to troubleshoot and fix problems while juggling those unhappy people isn’t always an easy task.

Databases are hard because there are a lot of places for things to go wrong, and a DBA needs to be able to deal with all of those. There’s data modeling, which can cause never-ending problems when done incorrectly. There are server administration tasks, which can have fundamental performance impacts. There is a need for security skills to keep that all-important data safe from all kinds of bad guys. The list goes on.

Why is this point missed?

I don’t know. Wish I did, pretty sure I could make a lot of money 😉

The problem isn’t with us. For the most part, IT folks already know that DB work is hard. We don’t need to convince ourselves. All manner of IT management and/or business owners need to know that DB work is hard, just like most other forms of IT work. This is where the problem is.

It seems like DBs get short-changed a lot, doesn’t it? When things start out, the little Access DB works fine for the few users that there are. As the business grows, either a Dev or Sysadmin that knows a bit about what they’re doing gets a hold of a SQL Server license and migrate the system over. This is completely fine for small to even medium-sized shops. Hardware and SQL itself will run really well out of the box for the vast majority of applications out there.

The problem is when you cross that line. The above-mentioned migrated Access app will run fine for probably a long time, but the next thing anyone knows, it’s five years down the road and the blocking is so bad in the poorly designed & maintained database that the users just know to get coffee across the street when they’re doing certain tasks because it’s going to be a while.

Pain like that can be avoided by having those DBA skills around from the very beginning. They don’t have to be FTEs. They don’t even need to be dedicated resources. They are, however, necessary skills, and every business that has a database (that should be a pretty high percentage) should have someone available to take care of these tasks at least on a part-time basis, even if it’s that Sysadmin who wants to learn the right way to do at least a few things.

Business owners might not think they need to spend the money now, and that very possibly may be correct. However, if they don’t, they need to at least know that the need will be coming someday. It’s only going to be more expensive later, and hopefully that day won’t be a time when a disk has died and the backup job hasn’t been working properly for three weeks 🙁