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 #22: Data Presentation

TSQL Tuesday Logo

Robert Pearl hosts No.22

It seems like it hasn’t been that long since last month’s T-SQL Tuesday post; I suppose time flies when you’re having fun and trying to finish up the same ETL project you’ve been working on since March.

This month’s SQL blog party is being hosted by Robert Pearl (blog| @PearlKnows), on the topic of “Data Presentation.” This is a good topic for me at this point, as I’ve all but finished my transition from DBA to BI Monkey (that’s something else I need to write about…). I think Robert is looking for specific examples of ways to present data, but since, as usual, I don’t have anything specific that I can actually publish, I’m left to speak generally about the topic.

Data Presentation: Just as Important as the Data Itself

In a previous life, I was responsible for almost everything data-related for the systems that we ran. As a result, I would get a lot of requests for data. One of my favorite requests would come in the form of, “can you give me some numbers for <X system>?” I would try to keep my response at least marginally non-snarky, but it would generally include two questions:

  1. What, exact, “numbers” do you want? (this is especially where I would have snark problems)
  2. What do you want the data to look like?

Of course, the first one is an important question—if the requestor cannot articulate what it is they actually want (or even what question they’re trying to answer), little else is going to matter. I’ll not dwell on this particular item too much, but suffice to say, sometimes getting a good answer to this seemingly easy question is anything but. I’ve basically come to the conclusion that this is normal.

Once over that hurdle, the conversation can move on to the presentation of whatever data/”numbers” it is the requestor wants. There are almost as many options for presenting data as there are for way to write the T-SQL to retrieve it. Just like writing the SQL in a way that is performance- and resource-conscious, care should be taken when working on the presentation design. It is imperative for the data to be presented in such a way that is understandable and digestible by its intended audience.

Notice I didn’t say “digestible by the party asking for it.” Don’t forget that the request originator may not be the party who is ultimately going to be parsing the provided data. If the audience is not clear in the original request, add a third question to the two that I have listed above: “Who is going to be acting on this data?”

Options for What Happens Next

When the “What do you want it to look like” question is asked, chances are decent that you’ve an idea about what the answer is going to be. If this is a one-off, ad-hoc request, Excel is a popular option. Alternatively, if a robust reporting system is in place, or this request will be a recurring one, developing a report to present the data might be a stronger choice. There are of course other options: the data could be destined for a statistical analysis application, where a CSV file would be more suitable. I would consider this an outlier, though—most of the time, data is prepared for direct human consumption.

Excel is such a popular option that you could almost call it Data’s Universal Distribution Engine (DUDE). Sending data over in Excel is less about the “make it pretty” side of good presentation as it is the “make it useful” side. I’ve found that Excel is a choice a lot of the time because the requestor wants to do more manipulation of the data once they get it. I’ll leave whether or not that is a good thing to the side; the truth is, such activity happens all the time. As a result, when preparing data for an Excel sheet, I like to have an idea of what the user is going to do with it. This sometimes helps to determine what data the user is looking for (if they don’t have a clear idea) but also can help with some formatting or “extras” to include. These “extras” could take the form of running subtotals, percent changes for Year over Year situations, or anything else that is easier to add via SQL instead of someone having to putz around in Excel.

Writing a report to present data has a different set of opportunities than pasting data into Excel. One of the things that I like to see in a solid reporting environment is a set of standards that apply to the reports themselves. Things like common header contents (report name, date/time stamp, name of the data source/DB the data is from, etc), standard text formatting, a common set of descriptors, etc, etc. In addition to making individual reports easier to read & feel more familiar, it can make it easier to compare data etween reports the hard way (one on each monitor), if one has to.

It's only worth 1,000 words if the first ones that come to mind are work safe

One thing each of these two tools gives you is the ability to present data in the form of pretty pictures. There’s a time and a place for everything, but the old cliché, “a picture is worth a thousand words” can/does apply. Sometimes it’s just flat-out hard to beat a good trendline. I have a much easier time seeing even the simplest of trends when data’s plotted out in a histogram. Conversely, one of my coworkers can look at a pile of numbers, not even sorted chronologically, and tell you what is going on in about three seconds.

Knowing where to put your effort goes back to knowing who your intended audience is. Likewise, knowing when to say “no” to visualization is a terribly useful skill. Every data element on the chart should be discernable, or else it doesn’t convey the information it is supposed to, and now the visualization is working against itself. The pie chart to the right? Don’t do that.

Summary

That’s about all I’ve got. In short: Presentation is important. Unfortunately, it can also be complicated. It’s important to ask questions early on in the process and to know your audience. Standardize if you can; help out a little with the complicated work if it can be done in SQL. Also, add visual representations without going overboard. I’ve always found turning “data” into “information” for people to be fun; if it can make someone else’s job easier/more fun, too, then all for the better.

T-SQL Tuesday #14: Resolutions

T-SQL Tuesday 14

T-SQL Tuesday 14, hosted by Jen McCown

Resolutions… For a long time, I thought 1600 x 1200 to be the ideal, but with the proliferation of widescreen—oh…wait…not that kind of Resolution? Sorry. My bad.

It’s that time again: the monthly blog party known as T-SQL Tuesday. This month is #14, hosted by the deservedly newly-minted Microsoft MVP Jen McCown (blog | @MidnightDBA). The topic this time around is “Resolutions,” originally, “techie resolutions have you been pondering, and why.”

In my 2011 “Goals” post, I talked about one of the things I need to do this year: something about my career direction. I’ll take this opportunity to elaborate a little bit on what that means for me this year. The part about needing to pick one of two directions still applies, but the work that I need to do for each of those is pretty different.

If I stay a DBA…

If I stay a DBA, what I need to work on the most can be summed up fairly simply: Catch up.

Since I work with SQL 2000 almost exclusively these days, there are a lot of current bits of technology that I need to spend time working on and learning:

  • DMVs
  • Policy-Based Management
  • T-SQL advancements (Actually using Try/Catch, TVPs, etc)
  • PowerShell

That’s just a few things that I can pull off the top of my head; I know there are more that I should know and be able to use at this point. Not having the opportunity to use these features day-to-day doesn’t exactly help me learn and keep these skills sharp 😉

If I want to be one of the cool kid DBAs on Twitter, 2011 is a year in which I have to do a lot of work on these topics.

Less BI-Curious and more BI-…uhh…Pro?

The other choice I have is to do awesome Business Intelligence work. I’m still turned on by a lot of these technologies and the power that they can put into the hands of business users at all levels of an organization. A change in direction at my current job to a more BI-focused role has yet to fully materialize, and as for right now I’m still somewhat impatiently watching that carrot out there.

Whether I do it in my current position or choose to take something new, changing direction to full-time BI work comes with its own set of topics that will need lots of attention from me:

  • Improve dimensional modeling skills (I do some of this already)
  • Actually learn how to do work with SSAS
  • PowerPivot
  • Get better at talking to non-geeks!

There are lots more topics than those three here, too. However, BI in and of itself is a pretty wide field, so the specific topics that would need attention would be dictated by the flavor of BI work that I was doing and my involvement on such a team.

Actually making this stuff happen

Like all resolutions, this is, of course, the hard part. Making this happen isn’t going to be easy for me, either, but the rewards should be very well worth the effort required. Unfortunately, since knowing is half the battle, and I don’t have that taken care of yet, the near-term has the potential to be pretty rough.

At the absolute bare minimum, I resolve to do my best to take care of “knowing” in the first quarter of the year.

(Also, I’m sorry about that screen resolution thing at the beginning; couldn’t help myself)

Looking Ahead to 2011

For as much as I write tasks/to-do items down, am unhappy when I don’t get things done on-time, and really enjoy learning and doing new things, lists of Goals sure rub me the wrong way!

2011 Task

Just don't call them "goals"

I’ve always been that way and I haven’t been able to figure out what my deal is. At first, I thought it was the idea of someone else dictating to me what I should do, but I feel this way when I cook up “goals” for myself, too. It’s not being adverse to work, because when it’s fun, it doesn’t matter. Fortunately, just about everything related to IT that isn’t writing .NET code is fun to me, so it’s not that, either.

If nothing else, I at least understand that I’m in the minority here, and can play along at work (err, “play along” sounds a lot more negative than I mean it to be) and understand that Goals make the world go ‘round. I’ll fill out the tool, put them on my Task list for myself (maybe even put “Goals” in the name), and everyone will be happy at the end of the day.

At any rate, since this can’t be a “goals” post ( 😉 ), it’s just going to be some random mumblings about where I want to go next year.

2011: The last full year

OK, I don’t really think the world is going to end in 2012, because No-one expects the Spanish Inquisition! and Mathew 24:36. You’re right, that was dumb. Let me try again.

2011: I pick a direction and [maybe] stick to it

The biggest thing coming up next year for me is career-related.

The whole reason I switched from being a Sysadmin to this DBA thing is because of Business Intelligence. I’m doing the plain-Jane DBA partly because it was there and partly because I saw it as a way to get my foot in the door of “real” data land. For the most part, that has worked out quite well, and, as it turns out, I like doing this full-time, too!

What this means is I need to decide which way I want to go with my life: Do I want to stay a full-time DBA or do what I can to follow what SQLChicken (blog | @SQLChicken) has done, and switch over to full-time BI work (he actually reminded me the other night that Pragmatic Works is hiring, but I said that the travel wouldn’t work for me. On the other hand, if I could drive or fly a little airplane around TN, then we’d need to talk 😀 )? There’s the potential for a heavy BI opportunity at my current job, but I don’t yet know how that is going to play out. It might be a good way to test the waters a bit, but I won’t know that for at least a month or two.

Regardless of how that goes, I need to get some new things going on job-wise soon, because I’m so over SQL 2000, I don’t even know what to say about it.

Other Data Stuff

SQL-related travel is something that we should be doing more of. Neither one of us has a very good (ie, all but nonexistent) travel budget at work, so we have to foot the bill for this on our own. Yes, we know.

We couldn’t swing PASS this year, and that wasn’t any fun. I’ve got SQL Rally on the calendar, but that still remains to be seen. It would be much easier for us to pull off, plus can easily be driven to (we’re done flying Part 121 ops for right now, thanks to the TSA). There are some SQL Saturdays that aren’t terrible to get to, and those are, of course, good events in their own right.

The biggest problem we have with travel these days (and this goes for all travel, not just SQL travel) at the moment is the dogs, since we haven’t been able to figure out what to do with them since moving down here. Taking them along is almost impossible (lodging at destination), and Boarding them at a place that doesn’t just leave them in crates all day gets real expensive real fast. We could get an RV, I guess, but we’d quickly become that couple at events, hahahaha. Still working on this.

Next year, I want to do more experimentation/exploration/goofy stuff with SQL Server at home. I’ve got a couple instances running now, but I’d like to branch into playing with pre-release stuff. This would be easier with a hardware budget, but I’m pushing that envelope as it is, already. Part of what’s holding me back in this department right now, is the simple fact that I don’t really know what to do with myself if I don’t have big DBs with a lot of users hitting them really making things work. Basically, I don’t function well when I don’t have a problem to solve :-)…I’m going to work on either fixing that next year or figure out a way around it.

Big Bookmark, Skinny Book

I'm going to have bookmark problems

I’m going to try to read more next year. I have no idea how I’m going to pull this off, because I read stupidly slow, so it takes me forever to get through anything. I’ve cleaned up my backlog of SQLServerCentral dailies so they’re not so overwhelming, and cutting my losses on some older SQL books that I haven’t made it through. I don’t think I can do anything about my blog feeds, because so many of you guys out there write good and useful content (unlike me).

I hope to get a quick win on the book front by reading Tom LaRock’s (blog | @SQLRockstar) book, since it’s thinner than pretty much everything else I have around here. In fact, it might be a little too thin (see pic). I’m hoping that a quick win there will help me build some momentum. Maybe I’ll magically be able to read faster, too.

Other/Misc

The first other topic is this Blog. I need to spend more time and effort on it, especially when it comes to writing good technical content. So far, I haven’t done a good job at that. That’s partially due to my job situation, but I could be doing more anyway. I hate setting arbitrary numerical goals, but I think I’m going to do it here: 26 posts. That’s an average of one every two weeks, and I should be able to pull that off. I’m not going to get overly detailed and say that “20 of them need to have good technical content”, I’m only going to go for an overall number.

I used to bicycle a fair amount. It hasn’t been the same since I was in college, where I put 30-35 miles a week on the bike just going to class & work. Back then I did a fair amount of mountain biking, too (which is what I’m really in it for), and spent a couple years running races in the Indiana statewide series, DINO. The last few years have been really lacking in that department, both causing and exacerbated by me being fat.

Next year, going to fix that & spend more time on the bike. I’ve already started to do some work on the trainer, and when it warms up, I’m going to move it to the road around the house. We live almost as far away from good bike trails as we did in IN, but I’m going to make an effort to not let that be in my way as much as it has been in the past.

This talk of biking has made me realize that I’m going to need some form of case or other padding for my new phone. The one time I went on a trail this year saw me doing an awesome, completely unintentional half backflip on the bike. I wound up flat on my back, still clipped into the pedals, holding the bicycle up in the air above me. The problem is that I carry my phone in my Camelbak; although the old Samsung i760 lived through that without a problem, I’m pretty sure the Focus would be broken in half. Soooo, need to do something about that.

My Non-Y2K-Compliant Logbook

My Non-Y2K-Compliant Logbook

The final thing for next year is flying. I got my Logbook out recently and thumbed through it. There’s some good stuff in there. The last time I flew was February 2005. I don’t even have the tail number of the airplane or the hours of the last two flights. Just have the landings (2 for one, 1 for the other). I know they were both in one/some of the Skyhawks at Lafayette Aviation, Tammy was with me for one of them, and I had to wait to take off on the single landing one because the visibility was crap**.

Anyway, since then, I’ve waffled back-and-forth between missing flying and being OK with how things are, because flying is freakin’ expensive. But, with the TSA thing and me more and more wanting to get back into it, I want to start flying again next year if I can find the money for it. This does mean that I am supposed to work on my Instrument rating (so I can fly in the clouds, basically), because I promised myself that a number of years ago. So… there’s the last thing for next year: Get Instrument Ticket if I can find the room in the budget.

There we are. 2011. Please don’t hold me to this stuff, because, you know, they’re not goals; just stuff I want to get done 😀

**That one was actually sorta fun, because it was late in the afternoon and the visibility was crap due to a fairly dense haze layer. We finally took off (oh hey, this is the one with Tammy. This means she was only with me for one landing. Hahaha, stay tuned for awesome stories.), flew around the pattern, annnnd then turned final, which happened to be directly into the sun. Bam, couldn’t see anything. I mean, seriously, in-flight visibility was maybe 1/2 mile, and I was on a mile final. I grumped about this to the controller as I flew runway heading, knowing that it would eventually show up ahead, and he was all, “Yeah, the last guy said it was pretty bad.” Yeah, thanks for the heads-up, pal.