Art of the DBA Rotating Header Image

Musings

Planning for success in 2012 (part 2)

Dec 15th, 2011
by Mike Fal.
No comments yet

If you missed part 1, you can head over here.

Speaking

In 2011, I jumped in to the presentation gig with both feet and found that I really liked it. If you’re an avid blog reader, you’ve probably heard the benefits of presentations ad infinitum. So instead of talking about those, let’s talk about why I like them so much.

First off, it’s a chance for me to study up on something I find really cool. I find databases and some of the topics in SQL Server to be really neat, most likely because I’m a geek. It’s stuff I want to learn about anyway, but since there’s a definite end point (giving the presentation), it helps me put some structure around learning an aspect of SQL Server.

Secondly, I like to talk. I’ve actually been offered criticism that I talk to much, but I figure that’s something I can work on and it’s easier to overcome chattiness than a reluctance to speak. And it’s more than just talking towards an audience in a presentation, I’ve found the best experiences I’ve had giving presentations are when there’s a good Q & A period at the end of a presentation.

Thirdly, people are genuinely appreciative of my efforts. I’ve written and talked at great length about how giving the SQL Community is, but one of the reasons it is so giving is because it’s also very thankful for the knowledge we share. I’ve received numerous compliments and “thank yous” for the sessions I’ve done, which really makes me feel good about the work I’ve been doing.

I want to continue speaking, so for the upcoming year, my second set of goals will be focused on presenting, with the following specifics:

  • Speak at 4 SQL Saturdays. Now, I’ve already got a jump on this because I’ll be speaking at SQL Saturday #104 in Colorado Springs, giving a new presentation on SQL Server partitioning.
  • Speak at SQL Rally – Dallas. Granted, this means I have to be selected, but I will be at least trying. I will submit my sessions by the end of the month and cross my fingers.

No, submitting for the PASS Summit this year is not one of my goals. I still might, but I’ll let that unfold. There’s some other items in the works, plus the nice thing about going to an event where you’re not a speaker means you can just be at the event. That’s what I liked about the 2011 summit, is I was able to experience it without worrying about obligations.

4-5 speaking engagements for the year may not seem much, but I’m finding out that speaking at user groups and SQL Saturdays can quickly beget other opportunities. By setting this goal, I establish a bar for myself, but also plenty of room on my plate for other things. In fact, I actually already have a couple things lined up already that I’m very excited about and will talk more about soon. But while I want goals that push me, I don’t want to overload myself and burn out.

Stay tuned, one more goals post coming soon!

P.S. If you can make it, we’d love to see you at SQL Saturday #104. I’ll be giving this presentation:

Eating the Elephant: SQL Server Table Partitioning – Is your table fat? Do you need to manage a table that has billions of rows within it and are overwhelmed by index rebuilds that take more than 12 hours? SQL Server’s table partitioning gives the DBA the tools to manage this beast and support very large tables in a way where index management and data retrieval does not become unwieldy. This presentation will take you step by step through choosing an appropriate partitioning key, setting up the partitioning on the table, and finally maintaining the partitions.

It will be a great time and an awesome way to kick off your SQL career in 2012!

Getting ready for 2012 (the year, not the version)

Dec 13th, 2011
by Mike Fal.
No comments yet

So with the new year just around the corner, I wanted to take a bit to take what I have gotten out of 2011 and use it to figure out where I’m going in 2012. While not to bore you with the details, 2011 was an explosion of career development, with the following highlights:

  • Regular user group attendance
  • Blogging (if somewhat ireggularly)
  • 6 Presentations given (3 at local user group meetings, 2 at SQL Saturdays, 1 internal)
  • Attending the PASS Summit
  • New job!

This has been good stuff and very fulfilling, but it’s felt a little about throwing spaghetti at the wall and seeing what sticks. While that works for a bit, it can wear you out quickly, so now it’s time for me to sit down and refine my focus a little more. After giving it some thought, I’ve found three general things (for lack of a better description) that I want to emphasize in the next year to drive my career even more than what I’ve done in the past year. I’m going to break these posts up over the next two weeks so that I’m not writing a novel, but I’m really excited about this next phase of my career that the new year will bring.

 Adjectives

When I went to the Summit, I sat in on a session with some “big names” talking about becoming a linchpin at your job. There was lots of great material out of the session, but the thing that really kind of stuck with me was something Kevin Kline talked about, and that’s what adjectives you want to be used when others talk about you. I’ve been thinking about this ever since, trying to decide what I want those to be. It’s hard, because we want to be all sorts of great things, but the cliché holds true: You can’t be all things to all people.

So now that I’ve had almost two months to think about it, I’ve come up with four words that describe want I want to be. Some of these already describe me, but some I need to work on. But in no particular order:

  • Smart – This is the easy one and something we all want to be. However, this just isn’t about knowing stuff, but also about knowing how to do stuff. A comment I’ve heard about me at work is that if someone comes to me with a problem and I don’t know it, I know how to get the answer. People know they can rely on me to answer their questions and help them with their problems.
  • Creative – It’s one thing to know stuff, it’s another thing to do something with it. Sure, we can all create log backups, design replication strategies, or performance tune queries, but not everything fits in the magic flowchart of all answers. Almost every company does something different, and as data professionals our challenge is to take the various bits of knowledge we have and craft them into elegant, repeatable solutions.
  • Reliable – I want my co-workers and customers to know that they can depend on me. This is a little different than being the go-to-guy or “Mr. Fixit”, as I don’t want to be the superhero that people always look for to save them from their data problems. As Tom LaRock describes in his book, I want to be Mr. Right, not Mr. Right Now. (If this doesn’t make sense, read his book. Really.)
  • Professional – This is one that I feel like I struggle with. I want to improve how the people around me see me from a professional sense. For many years, I was that guy who just wanted to sit at his desk and write code, to be left alone by the outside world. That’s a very career limiting goal, honestly. If you dress and act like you want to be left alone and not noticed, you will be left alone and not noticed. I do want my managers to notice me, I want my coworkers and customers to respect me, I want to rise above. This quantifies into a lot of little things, like dressing a little nicer, making sure I show up to meetings on time, taking on some additional projects.

These adjectives, more or less, form the core principles for my career. No matter what, this is who I want to be. Everything else in my career will build on this, and while I’ll be far from the perfect DBA, those around me will know what the can expect from me and what kind of resource I will be.

Watch for part two in a couple of days!

Performing your presentation

Sep 27th, 2011
by Mike Fal.
No comments yet

If I asked you when was the last time you went to an awesome rock show or movie, I’m betting that not only do you remember the day, but probably also remember how excited you got. Maybe it was Rush, getting you to move to the beat and sing along with the lyrics, or Captain America, cheering while he took on the Red Skull. I’m sure we all can think back to some artist that got us excited about their art because they put their heart and soul into their performance. Now what if I told you that giving a presentation isn’t really that much different?

For those unaware, I am a musician as well as a database administrator. I studied Bass Trombone performance at the University of Colorado at Boulder and have played in several jazz bands, orchestras, and chamber groups over the years. Sometimes it was a large gathering, other times we probably could have taken the audience in a fight. Every one of these was great, though, because of the rush I got playing music for people and sharing with them some of what I felt when I got to play.

Recently I’ve started doing SQL presentations, trying to build that professional development thing. I’ve enjoyed it and had a reasonable amount of success(well, no one’s thrown rotten fruit at me yet), but it struck me how similar giving a presentation is to a musical performance. I’ve found that just live I’ve tried to share the excitement I feel about music with an people who come to listen to me, when I give a presentation I’ve got the chance to share with people something that I found within SQL Server that’s cool and fun (in a geeky sort of way).

If you look at presentations you have given, I’m sure you can think of the parallels of preparation and practice, both of which take so much of a musicians time. The time spent building slide decks, researching minutiae, and talking in front of a mirror with a stop watch are so very much like a musician studying a score, practicing etudes, and doing breathing exercises. Most of an artist’s life is spent getting ready for that performance. It’s often lost in the mix is done on stage that really brings a song or a show to life.

I want you to think about that last great rock show or movie you went to. You know, the one that had you dancing in the crowd, cheering the hero, or singing along with the band. Musicians find ways to reach out and involve the crowd, so that their audience doesn’t just feel like they’re listening to a show, but that they’re actually a part of it. This is where the magic is, and if you can capture that in your presentation, your success will soar.

“But Mike!” you say, “We’re just talking about the dull stuff. No one’s going to bob their head to query plans, right?” Untrue. After all, the reason we work in this industry, that we participate in the community, and that we present to groups because it’s fun and gets us excited. The folks coming out to these events share that excitement, we just need to tap into that as presenters. It’s this magic quality that I’ve been working on in my own presentation style, so I canengage my audience and break down the wall between me and the people sitting in the room. It’s not easy and I know that there’s a lot that I can still learn here, but these are some of the things I’m trying to do:

  • Lighten the mood. Sure, we’re seeing a lot of dry stuff with databases, but find ways to make it fun. It could be humor or handing out candy for good questions, but try to loosen people up.
  • Get the dialog going. We always expect the audience to ask questions, so it’s uncomfortable when they look at you stone-faced. Typically, people aren’t asking questions because they’re afraid to be the first one. Get past that by asking the audience questions. Once your group realizes that this is a two way conversation, questions will start flowing.
  • Don’t be afraid. After all, people have come to the presentation to hear you. And they’ve come to hear you because they are interested in your topic and you do know what you’re talking about. If you have that confidence, it will project through and engage your audience.

Presenting really is another performing art, and I think if you approach it like an artistic performance, not only will your abilities as a presenter grow, but it will be more fun to boot. It’s hard for me to really put in to words the rush I’ve felt after a great performance, like when I played the Pines of Rome or Count Bubba, but it’s a feeling that can’t be beat. That’s what’s great about presenting, is I have gotten the same rush getting up on stage in front of PASS user’s group. So while most of us can’t shred like Satriani or sing like Tori, we all have the ability to share our passion for SQL Server with people who are just as fired up to learn about it. Revel in that, it’s a feeling to few people get to have.

It’s a heterogeneous world

Jun 13th, 2011
by Mike Fal.
No comments yet

Here’s my big “DUH” statement to kick things off with: The information technology world is one of constant change. Shocking, I know! For most of this, it’s why we love the business. There’s always something new to learn and fresh challenges to solve.

But it’s also a world where the old things don’t go away. I’m sure many of us have stories of having to keep some Access application afloat or supporting a legacy website that had most of the back end hard coded. When companies make investments, they want to get the most of that investment that they can, which means platforms will stay around for years because it’s to resource intensive to replace things that are already working.

This is especially noticeable if you work in a company that grows by acquisition. Rarely do different company’s have the same systems, so every acquisition means having to adapt to a new set of software. I’ve had to deal with acquisitions in every job I’ve worked in, and through that period, I’ve had to support 5 different database platforms. My focus has always been on SQL Server, but I’ve had to learn to adapt to these other technologies in order to support either a migration, a legacy application, or a proof of concept system.

So what am I getting at here? Mostly, that it’s important to not become to focused or attached to any one platform, particularly when it comes to databases. Only the very lucky will work with one only SQL Server (or another database system) for their entire careers. Here’s a couple tips to keep in mind so that you don’t short circuit yourself when challenged with a new system.

Be Flexible

If a new technology comes into the company, don’t be afraid to take it on. As far as databases go, you have a couple things working in your advantage. While some of the underlying mechanics may be different, such as storage and memory use, many of the fundamental concepts are the same. You’re still going to have tables, keys, and indexes. You’re still going to need to take backups, update statistics, manage access. Chances are that this is most of what you will be required to do to support a new platform, so don’t be intimidated by how “foreign” a new system might be.

Be Aware

The next stage beyond flexibility is awareness. How many database systems can you name? Three? Four? Even if you just know the names of some other systems, you’ll have an edge. Take some time and research what else is available. Once you know some names, you can then take it a step further and get a general idea of the capabilities of these platforms, as well as what separates them from each other. If you can get to the point where you can describe a platform in a paragraph, not only will you be more comfortable learning to support a new system, you can also provide high level feedback on transitioning a platform into your enterprise.

Be Ready

Don’t get blindsided by a new situation. If you can get ahead of the game and at least have cursory knowledge of how to do things in a different database system, your life will be a whole lot easier. Expand on your basic knowledge and take time to figure out how to do some of the basics, like:

  • Taking a backup
  • Creating a database
  • Importing/exporting data

You never know if or when you will need to do any of these tasks. You don’t need to be a certified expert, but if you take the time to at least experiment with other platforms, then you won’t feel like you’re floundering for a life preserver when a new acquisition gets thrown at you. If you don’t know some of the basics when you have a new database thrust upon you, make it a priority to learn these things first, taking all the basic tasks you perform on the database you’re familiar with and find out how to do them with the new technology.

As data professionals, we are expected to do our part for the company and take on these new challenges. Don’t be afraid of having to adapt to other database solutions. From my perspective, this is a great way to be the hero for your department, simply by taking a little time to get ahead of the game. And by knowing more about other technologies, you are also prepared to help plan your company’s acquisition and integration efforts, ultimately furthering your career and preparing yourself for the next stage.

Dumb Questions

Apr 1st, 2011
by Mike Fal.
No comments yet
“Can I ask a dumb question?”

Anyone who works with me for a short period of time will hear this tumble out of my mouth.  I can’t tell you the number of times someone launches into a 5-10 minute explanation of a really cool concept and giving me that “I have a cunning plan” look when they finish.  However, because I didn’t have that one thing in my head they figured was obvious, I end up having to ask a couple questions to get myself on the same page.  It’s never a big deal to fill in those gaps and the opposite party is usually happy to provide the context, but I do have to ask those questions.

Assumption: The Mother of all Screwups

The problem is with assumptions.  Whenever we communicate with each other, we have to make an assumption about what the other person knows.  Unfortunately, a lot of times those assumptions are wrong.  Remember the ill-fated Mars orbiter where there was a mixup between the imperial and metric measurement systems?  While we all smack our forehead and say “D’OH”, it’s pretty obvious that this is the result of one side making assumptions about the other side’s knowledge.  If someone had questioned the basic assumptions of both sides, they might have saved that $125 million orbiter, but instead, the two teams ran off on different tracks because they didn’t want to appear dumb.  (How how do they look now, right?)

I know we all get frustrated when the Level 1 support tech asks us if our network cable is plugged in or that we haven’t kicked out the power cable, but these are exactly the kind of questions we need to ask when troubleshooting database problems or building requirements for a project.  The reason for this is because asking the dumb questions helps establish a baseline starting point for figuring out the problem.  After all, when someone comes to us saying “the system is slow”, we don’t want to bash our heads with IO stats or memory pressure when all we had to do was deal with one blocking query.  We wouldn’t know about that unless we asked the right questions to start our troubleshooting.

So tell me a little about yourself

The best approach is to dealing with this is to teach yourself to reduce the number of assumptions you make.  Easier said than done, right?  What really helped me was an exercise a former boss/mentor had me do early on in my career.  It’s pretty simple:  In one paragraph (no real limit on sentences or words), describe your work to someone who has no idea what you do.

Seems easy at first, but think about it for a second.  Let’s break down the following sentence that I might use:
“I administer and maintain SQL Server databases.”

Already in this sentence we have several assumptions about the listener.  First, that they know what a database is, and they know what maintenance and administration is for SQL Server.  Chances are most folks don’t, so we would then have to explain those terms to them in a way they would understand.  We don’t need to get overly complex, but provide the listener a basic grasp of what we’re talking about.

The end result is that this exercise puts us in the mindset of someone who may not have the same knowledge or experience as we have, thus getting us to restructure our thinking and presentation in a way that covers the entire context of whatever idea we’re presenting.  It also gets us to start evaluating our assumptions based on our audience.  We’re always going to make assumptions, but what we want to do is make them in the context of our audience.  Speaking to a group of DBAs?  Yeah, leave out that stuff about relational theory.  Talking with IT infrastructure dudes?  Chat with them a bit about database file layouts and managing I/O contention.  Oh, monkeys from Kenya?  Throw ’em a couple of bananas.

Duh!

So whether we’re asking ourselves or someone talking to us, it’s always good to get those assumptions straight.  Sure, we all pride ourselves on figuring things out.   That’s why we’re in this business, for the joy of solving that process that no one else could.  But it never helps us when we get lost on that wild goose chase because we made the wrong assumption.  Save yourself some time and a lot of headache, make sure you’re on the same page with those you work with, and ask some “dumb” questions.  It never hurts.

Newer Posts →