Art of the DBA Rotating Header Image

career

Matters of Opinion

The common creed of I.T. and data professionals is “just make it work”.  Commonly we’re tasked with crazy problems, weird situations, and difficult challenges and we just get our heads down and get the work done.  It’s not often that we look up and plan beyond the current project or task.  We’re a cog in the machine, a smaller piece of a larger process, focused on getting the work done that we can control.

It’s a position we often struggle with.  How can someone come to you with a half-baked solution?  Something a user doesn’t fully understand even though they insist that “this must be the problem”?  I know I’ve been there, asking myself these questions while gnashing my teeth and shaking my fists at the sky.

Stepping up

The unfortunate truth is that these situations, like many other problems, are somewhat of our own making.  It’s a matter of trying to ride the proverbial tiger instead of trying to cage it.  The fact of the matter is that very few people, especially at a management level, understand database technologies the way we do.  If they do, it can make our lives a little easier, but typically we in the trenches will know more about the new features and limitations of our platforms.

How do we leverage this to our advantage?  By becoming thought leaders at our jobs.  Our management needs to plan to leverage new technologies and want answers about capabilities and options in order to find a way forward.  Do they go to the cloud? Should their databases be hosted on physical or virtual servers? How can we improve system response?  We can answer these questions, but can’t wait around for someone to ask us.

Resource of Record

How often do you talk to your managers about what you could do?  Information they’re looking for?  Opportunities for improvements that you can provide, either through current or new elements of your platform?  Our managers only know what they know, so we need to educate them by getting in front of them and sharing our knowledge with them.

So how?  If you’re one of the many professionals following the advice of Brent Ozar(@BrentO), you’re already well on your way.  Blogging?  Make sure your boss is reading your blog, so that he’s aware of what you know and are thinking.  Presentations?  Make sure your management is aware that you’re speaking on technical topics and what those topics are.  Building your personal brand is as important to your current job as your next.

You also need to have an opinion.  Sure, we live by a creed of “it depends”, but when someone asks as “how” or “why”, we should have a good answer for them.  Physical or virtual?  Cloud or on site?  Should this index be added?  As thought leaders, we need to provide more than just options, we need to provide answers and the knowledge to back those answers up.

Throughout my life, I’ve had this concept of “having the initiative”.  Basically, it means that I try to take control of situations, not letting them take control of me.   This is very much in that vein.  By advertising my knowledge to those around and above me and selling my expertise, I become the first stop for a question instead of a second or a third.  If you were the first stop, what would do that for you?

Looking Forward

Last time we met (ah, such a wonderful time), I did a once over of my accomplishments for 2012.  While I was pleased with the results, we must remember that career development is an ongoing process.  With 2012 in the review mirror, it’s time to put my 2013 goals to paper.

Speaking

I’m not going to lie, I really enjoy presenting.  It’s addictive and makes me think the tests are right(ENTJ, by the way).  I pushed myself to the edge on this last year by speaking at 5 SQL Saturdays, 2 Virtual Chapter meetings, a handful of user group meetings, and Rally.  This was a good stretch, so no reason not to match it.  In 2013, I will aim to:

  • Speak at 4 SQL Saturdays (and I’ve already got 3 on the books, which will be number 4???)
  • Submit to speak at the PASS Summit.
  • 3 chapter presentations (a mix of virtual and “meat-space”).

Note, I’m just submitting to Summit.  I have no illusions about this one, many people tried for years before they were accepted.  I need to get my foot in the water and start beefing up my presentations to Summit quality.  No, I won’t be doing Bob Ward(@bobwardms) or Adam Machanic(@adammachanic) level stuff, I’m quite happy in the 100-300 range, but I feel there’s a real need for that sort of stuff in the community and I plan to bring my A game.

Blogging

Ugh.  Blogging is what I struggle with.  Not that I don’t have things to write about or I dislike writing, it’s more that I dislike making time to write.  It feels like homework (and it is, after a fashion).  Blogging, however, is a GREAT way to get ideas out of your head and self-document your work.  To that point, I plan on:

  • Blogging once a week.  (ALWAYS commit to a regular schedule)
  • Continue to focus on automation and monitoring.
  • Blog about my server inventory and automated restore testing processes.

Certification

In general, I’m in the camp that certification doesn’t necessarily prove competency.  Many of the smartest people I know don’t have any certifications at all.  However, I agree with Glenn Berry(@glennalanberry) that self-acquired certifications (i.e., you didn’t go to a boot camp) show a willingness to go the extra step, much like community involvement.  Also, having them doesn’t hurt your resume, an overall net gain in almost any case.  My plan for 2013:

  • Get the Microsoft Certified Solutions Associate (MCSA) by June.
  • Get the Microsoft Certified Solutions Expert(MCSE): Data Platform by end of year.

Seeeeeeeeeeeekrit Project

Wow, how’s that for vague?  That’s intentional, as I don’t want to let the cat out of the bag, but I want to put this to paper to hold myself accountable.  Basically, I had a really cool idea at this year’s Summit and I really want to go for it.  Keep your eyes open for more on this throughout the year.

It’s Gonna Be HUGE

As you can see, I’m loading up on 2013 like a starving man at an all you can eat buffet.  It’s exciting and intimidating, but most of all, it’s achievable.  Nothing on this list is out of my reach.  Also, many of these things fold into one another, such as my presentations meshing with my blogging meshing with my seekrit project (ah HA!  Parallelization!).  I’m ready to take it all on, ‘cause it’s gonna be awesome!

A Look Back

The end of 2012 has arrived, despite the best efforts of the Mayan calendar.  It’s been quite a year for me, with a lot of ups and some downs, but overall pretty pleased with where I am regarding my career progress and community involvement.  For those of you who were around this time last year, I had laid out a series of goals for this year.  In order to keep myself honest, I thought it would be appropriate to hold myself to those goals.

Adjectives

My first goal was to get people to associate me with several adjectives.  For review, these adjectives are:

  • Smart
  • Creative
  • Reliable
  • Professional

Considering a lot of the comments I get from friends and colleagues, I’m pretty happy with my progress here.  I’ve had co-workers tell me that I’m looked to for creative approaches to solving problems, both using current and new aspects of SQL Server.  Many people, both in and out of my job, look to me for help and advice.

My biggest struggle, though, is still being “professional”.  I wear my emotions on my sleeve and sometimes that gets away from me, particularly when there’s friction between me and others I work with.  I need more focus in this area, but I also need to keep the other adjectives on my mind.  I’m on the right track here and need to keep moving forward.

Speaking

This is where I had my biggest accomplishments.  My goal was to speak at 4 SQL Saturdays and SQL Rally and, fortunately, I managed to do all that plus an additional SQL Saturday, several virtual chapter meetings, and a handful of user group presentations.  All of these went very well and I got plenty of great feedback.

What I’m most proud of was my SQL Rally presentation: Eating the Elephant – Understanding and Implementing SQL Server Partitioning.  I had a full room with 100+ people in attendance and got positive feedback from most of the audience (though I did get one guy saying he found a great place for a $3 Coke).  I was nervous right before I started, but once I was “on”, things went very smoothly.  I really want to thank folks out there in the community for their support, because without them I wouldn’t have gotten so far.  It can only go up from here.

Focus

I’ve only had moderate success with getting focused here.  Certainly, I have learned a lot more about automation and monitoring in SQL Server.  In reviewing my blog posts over the year, I’m definitely happy with what I’ve written on regarding this.  But I could have done more.  I think my biggest disappointment is how I didn’t blog nearly as much on this topic as I could have.  I have more ideas on my head and I need to be more disciplined about putting them to “paper”.

Summing it up

Self-evaluation is a huge part of personal growth.  We need to set measurable goals for ourselves and then periodically check where we are against those goals.  If I were to grade myself for 2012, I’d probably rate a B.  I should have blogged more, but made great progress with speaking and self-learning.  I have definitely have stretched myself professionally and feel positioned myself well to take things further.

This is an ongoing process, though.  Doing well in 2012 only means I need to stay on track and set goals for the next year.  There’s been a lot of thoughts floating around in my head over the past few weeks, trying to sort out what is both reasonable and measurable for 2013.  I should be ready to commit to those goals and share them with folks next week.

SQL Superstars

Michael Jordan.  Peyton Manning.  Joe Sakic.  Kobe Bryant.  Tom Brady. Andy Pettit.

Sports superstars. We watch them throughout the year, enjoying their athletic performances and last minute heroics.  Whether you love them or hate them, their abilities are amazing.  But there’s more than that.  We also watch as these special athletes also become a focus for their team, a linchpin for their team mates, a fulcrum upon which their organization’s efforts are leveraged.

I typically listen to the local sports talk radio on my way to work.  One day, the hosts were discussing superstar qualities, such as the ability to make plays and elevating the play of their team mates.  Since I was heading in to work, I started wondering how that translated to my job and if I was trying to bring these same superstar elements to the database court.  After all, I’ve always considered myself smart and able to handle any technical task in front of me, but being a true superstar is more than just being good, it’s also about being a leader and a force that drives the people around you to success.

I don’t think it’s quite that far of a leap from sports superstardom to the corporate world.  While we can’t do what these guys do (or get paid millions of dollars to do it), we can approach our jobs with the same mindset.  Here are some of the qualities that bounce around in my head and how the can be brought to our jobs:

  • Talent – Successful athletes all have some basic level of talent.  You don’t have to be the best, but you do need to be good.  I think all people in the technical field have this capacity, since we wrap our brains around some pretty involved concepts daily, so this is the easiest to attain.
  • Drive – It’s not enough to be ok.  It’s not enough to do the minimum.  Superstars are ambitious, want more, and strive to be the absolute best they can be.  For the technical field, this means we embrace the constant change, the continual learning, and the desire to find better ways to get our day to day work done.
  • Leadership – Now it gets harder.  Superstars realize that they’re on a team, and have to be a part of that team.  But true superstars step forward and lead the team, they set the tone for the people around them.  As data professionals this means we look for projects and weaknesses in our environments and improve them.   Don’t ask for permission, don’t look for approval, just lead.  Is there a better way to run your backups?  Do you see poor performance due to bad query or table design?  Where ever you see a place where something can be made better, lead the way and those around you will follow.
  • Make those around you better – Once people start following, you need to help lift them up.  Your team is only as strong as the weakest link and, as a superstar, it’s incumbent upon you to strengthen those links.  Maybe a teammate is struggling with escape characters in dynamic SQL or they have questions about creating a server side trace.  Whatever the case, withholding your knowledge or doing the work for them doesn’t help the team.  True superstars raise up those they work with, because they know that the success of the team is dependent on the ability of the team, not the ability of its superstars.

The work we do every day is a team sport.  We can be good as individuals, but we are rarely viewed as that.  Take John Elway and Dan Marino, two of the greatest quarterbacks of their generation.  In almost all cases, Elway is seen as the better quarterback because of his team’s success.  While he’s recognized as a proficient individual talent, the Superbowls he led the Broncos to set him apart.  That’s the key, that he led the Broncos.  His superstar status is more a result of what he did with his team than what he did by himself.

We want to have the same effect.  While there might not be a championship on the line, our own talents and abilities are enhanced by what we do for those around us.  These people might be team members, co-workers, or even the extended SQL community.  Note that a lot of the superstar SQL contractors we know (Brent, Paul, Denny, etc.) are heavily involved in sharing knowledge with the rest of us.  Their sharing makes us stronger, resulting in a better database community.

The next time you watch a major sporting event, look at how that team is being led.  Consider the superstars and what you can do to emulate them.  While we may not have the money, we can certainly have that same success by choosing to make their habits our own.

T-SQL Tuesday #32 – A Day in the Life (#tsql2sday)

This month’s T-SQL Tuesday is brought to us by one of the more statistically important data professionals out there, Erin Stellato(b|t).  The assignment is simple enough: Record your day on either Wednesday 7-11 or Thursday 7-12.  Easy enough, but leave it to me to screw it up, right?  Anyway, I was travelling on Thursday (heading down to Albuquerque to present at the local 505 user group), so I cheated and recorded my activities for Tuesday, 7-10.  It was an average enough day, so a good cross section for the series.  So, without further adieu:

  • 6:55 AM – 7:10 AM Check on I/O trace – I can work remotely, so commonly when I get up I’ll check in on things just to make sure everything is ok.   This time, I had set a profiler trace to run overnight to give me some info on I/O issues we were having.  All I did here was log in and make sure it ran, I was going to drill in to the detail later.
  • 8:15 AM – 8:30 AM Review alerts from previous night – Still at home, but I did a quick glance over the alerts from last night just to make sure there weren’t any fires.  Everything was cool, so I hit the road to get in to the office.
  • 9:00 AM – 9:20 AM Arrive in the office, get my day started – This is administrative time, responding to emails and getting my tea (I hate coffee.  There.), settling in for the day.  This bleeds into the next part….
  • 9:20 AM – 9:40 AM General maintenance work – This was basically some file clean up and responding to some of the alerts I saw from over night.  Nothing major.
  • 9:40 AM – 10:40 AM I/O research – So we’re having an I/O issue in our lower environments.  We’ve got a LUN on one of our instances that is getting slammed.  This was what I was using my trace to research and discovered that a whole lot of work was going through tempdb.  I spent this time reviewing my data and then talking with the relevant developers and QA engineers.  Once I had my info collected, I reported out to the systems team, DBA team, and the dev guys.  Unfortunately, this is a situation where not much can be done.  There really wasn’t any alternatives for spreading out the I/O load (at least none worth pursuing for a lower environment system) and the proper way to fix it was to have the dev team file things away for code fixes.  Still, with the info I collected we could come back to that with a better strategy.
  • 10:40 AM – 11:00 AM TempDB cleanup – Got some additional space for one of our dev instances to allow us more tempdb space, so I cleaned that up and arranged the files.
  • 11:00 AM – 12:00 PM CLR Research – So I’ve never really done much CLR work.  We had a legacy sproc that we used that was reporting incorrectly, so I was doing some research as to why. Really didn’t have much luck, but since I was used to the WMI in Powershell, I figured I’d try and rewrite the CLR logic using that.
  • 12:00 PM – 1:00 PM Lunch – Every Tuesday we go to this awesome thai place down the road.  Basil chicken for the win!
  • 1:00 PM – 5:00 PM CLR Research – I basically spent the rest of my day fighting with CLR.  Keep in mind, I’m a DBA with a sys admin background.  I’ve dabbled in .Net code, but I’m very rusty and my code is less than elegant.  However, it was a good learning experience, and taught me several things:
    1. CLR only supports a limited set of libraries.
    2. The System.Management libraries apparently have a lot of dependencies on forms and drawing (I have no idea why).
    3. CLR is a real pain to debug, depending on local security policies.

Honestly, this was one of my lighter days.  Probably because we had just come out of a holiday week where we had locked systems down and allowed minimal change, meaning we also did have much breaking.  This is what makes the job enjoyable: not every day is a fire drill and the ones that aren’t afford me an opportunity to experiment and learn.  Because of this day, I’m a whole lot more comfortable with the concepts of CLR (even though I still haven’t built a successful CLR function) and it’s made me a stronger DBA.

Thanks to Erin for hosting T-SQL Tuesday #32!   Make sure you visit the master post for other great blogs!

The importance of listening

A while back when I was still studying music, I went to a master class conducted by a prominent tuba player. We covered a lot of the usual stuff, like breathing exercises, intonation, and specific excerpts and audition pieces. A major portion of the time, though, was spent on another important aspect of musicianship: listening. As a group, we talked about listening to different musicians to how they would phrase melodies or shape dynamics, discussing guys like Sinatra, Rush, Miles Davis, and many others. It was stressed that spending time listening critically to music was just as important as practicing and something we should be spending a couple hours on daily.

I began to think about this vital part of musicianship recently when I was at SQL Saturday 107, talking with other presenters about how we approached our presentations. For many of us, the practice of public speaking isn’t just about sharing with others of the SQL community, but also about improving our own skills. I’ve written before about how presenting is like performing and, while I’ve been practicing and rehearsing my presentations, I’ve also been trying to watch other presenters to learn what techniques others use and what might help me improve my own skills.

There have been a couple speakers that have taught me a lot, simply by watching them use their craft. Probably my biggest influence to date is Grant Fritchey(b|t). I’ve learned a fair amount from watching him, but one of Grant’s greatest strengths is he presents with passion and excitement. When a speaker is energized about a topic, the audience will be engaged and drawn in by that energy. It’s important because the energy becomes cyclical. The more the audience is engaged, the more comfortable the speaker gets, and the better the presentation flows. I’ve also noticed that Grant doesn’t try to force the audience to respond, but allows his own excitement to resonate in the audience.

Another lesson I’ve learned is how to use humor to relax an audience. Wes Brown(b|t) does some fantastic presentations on storage and part of what makes them work is his easy, natural humor. If you’ve ever met Wes, he’s always got a joke ready. This works for presentations because it relaxes the crowd when everyone shares a laugh. It also gets the audience to respond to the presenter, breaking down the wall between the two. This is important, because it helps create and drive that energy between the performer and audience.

A quick follow up on this, I’ve seen a lot of people use “funny pictures” in their presentations to interject this humor. While this works for some folks, I found this doesn’t work for me. In the style that I give presentations, I find that this approach is a little forced and takes away from the story I’m trying to tell. This isn’t to say that it won’t work for you or for other folks, it’s just a case of observing how others do something, evaluating it for my own use, and making a decision based of that analysis.

Some other thoughts on what doesn’t work. I’ve seen demos blow up on folks, presenters who lose focus, session that try and cover too much material, presentations that end to quickly because a speaker lost control of the pacing, etc. While none of these are related specifically to one another, they always remind me of how important it is to practice. The more you go over your presentation material, the better you will be at presenting it to others, and you can recognize the lack of rehearsal through critical observation.

The key with all of this is to become a student of the craft. Many of us have great technical knowledge, the ability to figure out those tough problems like memory pressure, storage bottlenecks, security, application caching….the list goes on and on. Much of this is because we read and study that craft. If we want to similarly immerse ourselves in the study of public speaking, we should watch what others do. This can be done at the PASS Summit, SQL Saturdays, or your local user group. You also can go online and watch any number of presentations at TED or other webinars given by the community. In fact, it could be very helpful to watch non-technical presentations to add perspective. Just as any musician would spend at least part of his day listening critically to music, you should watch videos, webinars, and other demonstrations with a critical eye.

Now I want to note, you’re not looking for errors just for the sake of errors. I had a music teacher who called those folks “calculator kids”, just figuring out everything that went wrong. That’s not what this is about. By watching presentations critically, you want to catalog what you like and what you don’t like, and try and figure out what things in a presenter’s style works for them. The goal is to find those skills and techniques that will make you a better presenter.

Here’s a little exercise: The next time you watch an online video or go see someone talk about a topic (any topic), write down three things you liked. That’s it, simple enough. Try and do that each time you’re in a session. You don’t even have to say these are three things you will do in future presentations, but by just writing them down you’ll start thinking about those tricks and will choose some for yourself. I promise you, just by doing that, your presentations will better and not only will your audiences get more out of them, you will too.

So about that time management…

Yesterday I read an interesting post by the inimitable Brent Ozar (b|t) on time management.  Good stuff, much of which I already do or try to do.  Shortly after reading it, I had a brief Twitter exchange with Brent and Steve Jones(b|t), essentially on whether or not these were just rules for consultants or if they worked for us corporate folks as well.  Personally, it’s been my experience that not only can you follow these rules, but that you really should if you don’t want to burn out and still accomplish your goals.

First off, if you haven’t read Brent’s post, go read it.  I’ll wait.

<Time passes>

Cool, now that you have context, I want to basically give my thoughts on each of the rules and how I put them into practice in my own work day.

#1 Decide you want to be incredible – One of my favorite tweets from @FAKEGRIMLOCK is “BE SELF.  ITERATE UNTIL AWESOME.”  The first rule is really that simple.  You don’t have to change who you are, you don’t have tap into some hidden fount of knowledge…you just need to be yourself, awesomely.  This is something that can be done in a corporate job as easily as anywhere.

#2 Never budget less than whole day increments of time – Let’s not take this one quite so literally.  What I take from this is to devote blocks of time to my tasks and reduce distractions.  Whether it’s 4 hours or 2 or 8 (if I can get away with it), I use that block ONLY for the designated task.  Don’t multi-task, because it becomes harder to focus and get things done.  The key is to reduce/eliminate distractions.

Distractions come in many forms:  Meetings, on-call pages, emergency 20 hour conference bridges, people coming by your cube to chat, etc.  We can’t plan for them and they are probably the biggest threat to getting stuff done.  This is the balancing act, the biggest challenge for time management.  I’m actually going to steal some NoSQL terminology to outline how I approach this:

  • Map – Map out my time, schedule my work.  If I’ve got 2 hours, I plan to put 2 hours into a project.  Don’t work on anything else.  Keep in mind, sometimes the work is planning out your other work.
  • Reduce – Do work that reduces your other work.  Can you build better maintenance for your systems?  Can you communicate with people outside of meetings?  Take control of your time and put effort into removing the distractions that could disrupt you.

#3 Leave one whole day per week to do absolutely nothing – For me, this translates to one word:  disconnect.  We live in an a world and a culture where it’s easy to always be working, where we’re checking our email constantly, looking at alerts, responding to internal customers, monitoring our servers.  Why?  The world and the company will go on without you for a while, take a break for yourself when you need to.

IT has a reputation for burning people out, but I think that’s because people let the job control them instead of the other way around.  Take a break, breathe, and do something else.  Life is too short, you need to remember that we work so that we can do the stuff we enjoy.  Fortunately for many of us, we enjoy our work, but that can’t be the entire definition of who we are.  And if you’re working a job where your boss expects that?  Time to get a new job.  There are companies out there that respect the work/balance, go work for them.  You’ll feel better for it.

#4 Leave one more solid day to pounce on incredible opportunities – Not much else to say here, though I would add that incredible opportunities can happen inside your company, they don’t just come from without.  Also, some opportunities are self-generated.  An example from my work:  My job doesn’t have any formal SLA’s defined for the database team.  I saw the need and am driving that project.  My bosses and co-workers are taking note of my initiative.  Sometimes pouncing on an opportunity is simply being a leader.

#5 If the incredible opportunity runs more than a few weeks, it’s work – Maintain your balance.  When you take on additional projects or tasks, make sure they fit into the overall scheme that is your work/life pie chart.

#6 Say no early and forcefully to everything else – Much has been written about the necessity of the 40 hour work week.  Since we can’t do everything, at some point we need to be able to say “no”.  This is the hardest piece, especially in a corporate environment where you have a team that depends on you or management you want to impress.  However, you’re only human and sometimes work just isn’t going to get done.  This actually loops back to #3, because if we take on more than we’re capable of doing, everything else suffers.

Let’s not confuse this with neglecting what the company requires of us.  There are times we’re going to need to work on things we may not like (stupid SSRS).  What we need, as corporate employees, is the freedom to cry “uncle!” when there’s too much on our plates.  Sometimes it’s having a teammate take on that extra project, others it’s pushing out deadlines.  Really, all we’re trying to manage here is our overall workload so we’re not trying to do too much.

And if you’re working a job that won’t let you say “no”, that doesn’t trust you enough to accept a “no”, then maybe it’s time for a new job.  Just sayin’.

I think Brent’s rules are a great and hopefully this puts a little more perspective around them.  While my personal approach is worded differently, I think the main principles are the same.  What’s important is that there’s no reason why you can’t follow these rules in a corporate world, that these aren’t just for consultants.  Sure, you won’t follow them to the letter, but that’s not the point.  The goal is that too often we let our time manage us when it should be the other way around.  Turn that corner, take control, and you’ll find everything changes for the better.

(Yeah, cheesy end, but sometimes it’s like that.  Thanks for reading!)

T-SQL Tuesday #28 (#tsql2sday): Jacks and Aces

DBA. I’ll be honest, there are times I *hate* that title. People toss it around without really understanding what it means. Heck, how many of us specialize in backups, monitoring, and high availability solutions only to get a call from a recruiter who has an “immediate need” for an expert in SSRS and cube design. Unfortunately, this is a direct result of non-database folks not really understanding what we do. They simply see “database” on our resume and figure that if a database is involved, we know how to handle it.

We’re often considered a Jack-of-all-trades, the IT handyman. This has evolved from the roles we have to play in our careers and how so many of “fell” into a database career. The rule of thumb is that the smaller the shop, the greater our breadth of knowledge needs to be. While I’ve been a SQL Server administrator for over ten years now, my job responsibilities have required me to learn something about networking, Windows server administration, .Net development, report writing, and Oracle administration (amongst many, many other topics). Because so many things touch a database, we’re expected to understand all of these different pieces as well as the database itself.

The problem with all this is that it’s more than any one person can really know. With SQL Server becoming more and more complex (a good thing, by the way), it’s hard enough for us to keep up with that platform alone. Since it’s rarely an option to tell our boss “No, I can’t do that”, there’s a couple things that I’ve found help me stay ahead of the game:

  • Building your personal network. This is more than just the SQL Server community (fantastic as it is). Sure, attending user group meetings has helped me find experts in areas of SQL Server I’m not as knowledgeable in. But you’ll need more than that. I have Oracle DBA friends, hardware geek friends, sysadmin friends…..you get the idea. By building out this network, I always have someone I can go to if I’m out of my depth.
  • Stay educated. Sure, we spend a lot of time learning about SQL Server, but remember why we get into this business in the first place. Technology is cool, so keep learning about it. Pay attention to trends and tech so that when your boss comes to you about something, you won’t be caught by surprise. And if you *are* surprised, don’t sweat it, but make some time that day to read up on whatever they were talking about.
  • Write it down. When you do something, document it! So many people bemoan documentation, but the cold hard truth is you’re going to forget something when your focus gets completely shifted the next day. Being a small shop DBA means you’re going to get bounced around on a lot of different things, so you need to record what you do so that you don’t have to relearn it later.

Being a small shop DBA can be a tough gig, but it’s where most of us cut our teeth. Hindsight being 20/20, there’s a lot I’d do differently. Fortunately, Argenis Fernandiz (b|t) has given us this great T-SQL Tuesday topic for us to share with our SQL family and help others learn from our experiences.

The biggest lesson I would take out of all of this is that, while our job requires us to generalize most of the time, we can really only advance our careers when we specialize. If you’re simply treading water at your current job, pick some part of the SQL Server platform that interests you and focus on it. Once you start becoming an expert at something, opportunities will open up for you along with more interesting work and learning. That will start you along the path of moving beyond being a jack of all trades and becoming an ace in the database deck.

SQL Saturday #104 – Colorado Springs (#sqlsat104)

If you’ve been reading my blog, you probably saw the posts I made about SQL Rally, the PASS Summit, and a couple SQL Saturdays.  It is the SQL Saturdays, in particular, that really show the strength of the SQL community.  For those unaware, SQL Saturday is a run of regional events, put on by local user group chapters and supported by the Professional Association for SQL Server, that provide a day of free training and networking.  It’s a great chance to connect with others who do what you do, along with learning about how to do your job better.

SQL Saturday #104 in Colorado Springs was a stellar example of what these events offer and ended up being a great way to start off a new year of career development.  Here’s a brief overview of some of what went on:

  • Scheduled networking activities included as part of the presentation tracks:  Many events will only have a dinner or some after party, but I thought it was a nice way to break up the sessions by including games and other opportunities to network with other data professionals.
  • Regional and national speakers on a variety of topics:  I thought the speaker mix was fantastic, with many “big name” speakers such as Karen Lopez(b|t), Grant Fritchey(b|t), and Tom LaRock(b|t) (amongst others), but also the local talent, including: Marc Beacom(b|t), Doug Lane(b|t), Jason Horner(b|t), and…..me!
  • Professional resume reviews: Face it, job hunting sucks.  We all have to do it sometime and it’s rare that we get a chance for someone who deals with resumes all day to help us with ours.  I think the organizers of #104 scored a coup getting professionals to come in and go over resumes with people.
  • Free precons: Thanks to the sponsors of #104 for helping out with this one.  It was great to spend an entire day learning concentrated SQL info from Glenn Berry(b|t).  I know a lot of other folks benefited from this.  Not many SQL Saturdays can squeeze these in, but I’m glad the Springs folks made it happen.

As for my experience, I had a couple great highlights.  First off, I got to present again, and with a whole new presentation.  It went very well and I got great feedback.  There were also some great sessions that I learned from (have I mentioned how awesome Grant Fritchey is?)  Catching up with those of my SQL family who flew in for the event is always great, because sometimes having friends in other states sucks (and going skiing with these folks was AWESOME!).  Finally, being immersed in the SQL community gives me such a great feeling, both from being able to contribute and all the stuff I learn from it.

If you haven’t ever been to a SQL Saturday, go.  Keep an eye on the website and if there’s an event within easy travel distance, I can’t recommend enough that you get there.  It’s more than learning about SQL Server, it is about getting connected to SQL Server and the people (just like you) who work with it day in and day out.  It is finding out the gotchas and hidden gems within the application that will make your life easier.  It’s about boosting your career, knocking yourself out of that rut, and becoming “the DBA” instead of just a DBA.

I want to thank everyone who made this event possible(such a long list!), but especially Chris Shaw(b|t) and Jeremy Lowell(b|t), the engines that made this awesome event happen.  Keep up the great work!

DBA Survivor: Learning how to rock out with databases

When we get a “SQL book” handed to us, it’s usually to solve a specific technical problem. Maybe you need to understand how to write a PIVOT statement, read a query plan, set up a fail over cluster, or automate something with power shell. It’s a rare occasion when we come across a book that steps back from the daily tactical struggles and gives us a strategic view of what it takes to be a DBA and where to start when thrown in to the shark infested waters of corporate database administration.

Arriving with only a little bit of fanfare (and maybe a 2-3 angel choir) is DBA Survivor by notable #sqlfamily member, Tom LaRock(b|t). It’s advertised by Tom as the book he wishes someone had handed to him when he first became “the DBA”. A fresh approach to career development, the book finds a nice middle ground between purely technical guides and the generic career success compilations. Sure, there’s some technical sections that talk about about Dynamic Management Views, performance metrics, and backups, but the real meat is the “fuzzy” bits, such as instruction on defining daily check lists, writing Service Level Agreements, handling the work/life balance, and getting involved in the community.

While I enjoyed the entire book (all 171 pages!), several key parts stuck out for me. First is the discussion about Mr. Right versus Mr. Right Now. We’ve all seen the superheroes on our teams, the guys who drop everything to fix a problem (but don’t always fix it the right way). A former boss of mine called these folks “White Knights” or, as Tom labels them, “Mr. Right Now”. Contrast this with “Mr. Right”, who is rarely seen because when he’s on the case, things don’t break. He’s the DBA that’s proactive about attacking problems before they become crises, and when things do break he fixes them such that things don’t break again. To often we get caught up in the moment, trying to put out the immediate fires, that we lose sight of the long term. I’m glad that Tom takes the time to delineate between these two roles and emphasizes that, while we need to be Mr. Right Now sometimes, our goal needs to be Mr. Right.

Secondly, it’s nice to see a database book that instructs you about the importance of disconnecting from work. We’ve all been there: 60+ hour weeks, all-nighters, the on-call shifts from hell. The IT industry can run people ragged and burn the tech love right out of them if they’re not careful. I’m glad that Tom includes a chapter on maintaining that balance between your job and your life, because this is another area that so often gets lost in the moment. Steve Jones(b|t) often talks about life being to short to work a job you don’t enjoy, and this is very much an extension of that philosophy. You can be a great DBA and not work yourself to the bone, it’s just a matter of understanding when you should put the Blackberry down.

Finally, it should be no surprise that Tom has a chapter on community. I’ll wager most of you reading this already understand the benefits of the PASS organizations and local user groups, but many folks picking this book up may not. By including a discussion on connecting through user groups and professional organizations, Tom offers the new DBA an avenue towards excellence. I’ve seen the benefits of PASS and keep catching myself saying “If I had only gotten in to this years ago….” If I had read Tom’s book then, I probably would have.

Now many folks probably think this is just a book for the junior DBA, for someone who’s just getting started, but I know this book has value for data professionals of all levels. This book is not a detailed guide or roadmap for solving specific problems, but a series of highway sign posts to get people headed in the right direction. Maybe you are a fresh DBA, looking to get in to the industry or just survive your first week on the job. Or maybe you’re like me, a career DBA who is looking to refocus my career and looking for that “big picture view”. No matter how you got here, DBA Survivor is an excellent starting point for the rest of your database career.