Showing posts with label Career. Show all posts
Showing posts with label Career. Show all posts

Tuesday, April 9, 2013

T-SQL Tuesday #41 - Presenting Opens Doors

This blog post is part of T-SQL Tuesday, a monthly SQL blog party with a rotating host and common topic. This month marks #41, hosted by Bob Pusateri (@SQLBob), and the theme is how I came to love presenting.

Presenting Changed My Life

My story starts in early 2006; I had moved to Orlando to work for a small E-commerce company as a Sr. Production DBA, but I was the DBA's equivalent of the ghost who codes. While I had a nice resume there really wasn't much associated with my name and SQL server that I could show off to people. When I had a problem I searched for the answer on Google. I didn't follow anyone's blog or know any of the big names in the SQL Server world. I had no idea was PASS was all about or that the concept of a user group even existed. As I write this I laugh because I'm reminded that I even searched for logins to SQLServerCentral on BugMeNot because I wanted to remain anonymous.

A coworker of mine at the time told me that a friend of his was looking for people to present to a local group of database people. It sounded like an interesting way to meet other people around town who worked with SQL Server so I accepted and agreed to talk about the new XML features in SQL 2005. A month later I made the one hour trek across town to present to 15 people and as much as I'd like to remember that it was an overwhelming success it was anything but. I rambled. I had 3 slides and spent the rest of the time showing code in SSMS. I went at least 20 minutes over time. I know I lost a few people along the way and probably gave a few wrong answers to questions. By all accounts it was a terrible presentation.

But I survived.

The next day I received an email from the user group leader - one Andy Warren (@sqlandy) - with constructive suggestions on how to improve and an invitation to give the presentation again at this newfangled concept he called SQLSaturday. I accepted, took the suggestions to heart, and felt like a million bucks after I gave a much improved presentation to a full room at SQLSaturday #1. It was a great feeling, so I did it again...and again...and started to find new things to present about. I began attending OPASS and reading blogs (and started this blog, too). I kept at it, and in 2009 I was selected to present a session at the PASS Summit, an honor I had every year until 2012 when I attended the Summit in a different capacity - as a PASS Board member and Director of the SQLSaturday portfolio.

It's been quite a journey, to say the least! Along the way I've learned a metric ton (that's the technical term) about SQL Server and I've met incredible people, many of whom I have become good friends with. What a difference between the 2006 me and who I've become now - in large part because of presenting.

You Never Know Who You Will Influence

It wasn't obvious to me at first but I've come to the realize that one of the most rewarding things about presenting is that you have the opportunity to open doors for people, if ever so slightly. I doubt Kevin Kline had any idea who I was when I sat in a session he gave in Tampa many years ago, or who that guy named Jonathan Kehayias (@SQLPoolBoy) a few seats over from me was. I certainly had no idea who Jonathan was when I gave my XML presentation at SQLSaturday, and it's fun to think now that I was the one who first introduced him to XML-DML in SQL Server.

My point is that you never know if the next great blogger, user group leader, or eventual PASS President is someone you encouraged to give their presentation or someone who attended your session and walked away motivated to do more because of it. It doesn't matter if you're just getting started or you're a veteran speaker - by presenting you're helping yourself and others at the same time. I'll call that a win any day!

Your Turn

If you've ever considered giving a presentation but something's holding you back, consider this a challenge to get over it and submit. There are plenty of PASS chapters who will be happy to put you on their schedule and there's no shortage of SQLSaturdays these days either. Both are great places to start and there are plenty of people in the SQL community who can help you prepare in advance.

I promise, it won't be too painful - but be careful, because you might just walk away wanting to do it again!

Tuesday, November 6, 2012

T-SQL Tuesday #36 - SQL Community (Guest Post)

tsql2sdayThis blog post is part of T-SQL Tuesday, a monthly SQL blog party with a rotating host and common topic. This month marks #36, hosted by Chris Yates (@YatesSQL), and the theme is "SQL Community". This post is not mine, but the handiwork of Andy Levy (@ALevyInROC), a first timer at the 2012 PASS Summit. Andy doesn't have a blog yet, but was compelled by the topic so I offered to let him post on my blog as a guest. Hopefully this won't be his only post and we'll see his own blog up and running soon!

I'm very new to the SQL Community and still finding my way around. I had been exposed to it a little through SQL Saturday #129 and several MVPs I've spoken with over the past 18 months or so, but my first real exposure to the community was last week at PASS Summit 2012. I was completely blown away.
I arrived not knowing anyone, and feeling a bit overwhelmed by the sheer enormity of the event. 3900+ people. Sessions & events (official & unofficial) stacked from pre-dawn until midnight or later. Tweets flying by at a ridiculous pace. But after a couple hours, I finally came to a realization: These are my people. We're all here for similar reasons, but we don't have to have serious technical discussions all the time. In fact, in a lot of cases it's better that we don't. We can talk about topics at a high level, then redirect for more detail - "go read so-and-so's blog, he had a real good post last month about that" or even skip technical discussion entirely - "I had that particular experience, but now I need something different, and really want to move more toward doing this other thing." We don't have to get into details if we don't want to.

I met one woman near the Community Zone on Wednesday who told me that I should come speak at her user group - not 10 minutes after we  met for the first time. But I don't have anything to present. No worries, she says - surely I can come up with something. The following day, a discussion about SQLite came up, and Brian Davis pointed me at a blog post he wrote last year about working with SQLite from within SSMS. This got me started on about a half-dozen ideas for ways I could use data that I already had, ideas that were relevant to another hobby I engage in, which eventually I could turn into a presentation for a user group. Wow! I stumbled into a topic for a presentation - and the very notion of speaking at a user group - thanks to two brief conversations with members of the SQL Community. I had previously tried blogging and failed due to a lack of material. Now I see that I have my own ideas & insights into topics discussed by others that I can contribute back to the community, so I'm thinking about starting up again.

There's a recurring theme of "everyone in this room can learn at least one valuable thing from someone else in the room" that I've heard for quite a while, both in conversations and presentations, and now that I've experienced it firsthand (both as a learner and a teacher), I see just how true and valuable it is. It's very karmic - today I may get help from someone via twitter, and tomorrow I may be able to help someone else out the same way. There's no competition, it's incredibly collaborative & supportive. There's a tremendous feedback cycle - someone writes a blog post, someone takes the idea & make some adjustments to it or takes it to the next logical step, and then the original author integrates that feedback - or someone else can pick it up and run with it.

SQL Server & our general job roles may be the reason why we congregate at Summit, SQL Saturdays & user groups, but it's not what brings us together. What brings us together is the conversations we have on the side, sharing not just technical expertise but life and career knowledge & insights. The passion for the community is infectious - I've already asked my local chapter president how I can get involved with planning the local SQL Saturday in 2013, because I want other people to experience what I've experienced from this community in a very short time already.

Note from Kendal: Did you like Andy's post? Follow him on Twitter and encourage him to keep it up!

Wednesday, August 31, 2011

Are You Willing To Relocate?

Licensed under Creative Commons from've recently been talking to people looking for DBAs and one of the questions that always gets asked early on in the conversation is "Are you willing to relocate?". It's an easy question to ask but not always easy to answer.  I suspect most people would easily give a yes or no if asked in a casual conversation, but if you put more thought into it the answer becomes more of a maybe (or "it depends" for the DBAs reading this).

My current situation has afforded me time to figure out my own answer. I listed out all of things I thought I should consider and found that I was able to group them into two general "cost based" categories: financial and emotional.

The financial considerations included the obvious, e.g. salary and opportunity for career growth, and the not so obvious, such as: cost of living compared to where I live now, what it costs to move, and even the potential commute (my friend Andy Warren (Blog | Twitter) recently wrote an editorial on about this that I recommend reading).

I think the emotional considerations are even more important, though, because money alone doesn't lead to happiness. For example, I have friends who moved from Toronto to Orlando for a fantastic job and a very comfortable life but after a few years moved back because that was their home where they felt most happy. I can relate; my wife and I are both Florida natives, and with three kids plus siblings and parents within driving distance I realize how emotionally difficult it would be for my family to move far away from that.

So all things being equal, my preference would be first to stay local, then relocate elsewhere in the state, and finally move "somewhere else" (admittedly I'm not entirely sure where that somewhere else would be). That's not to say I would turn down an opportunity that requires relocating over something local, but it would have to be something special. Special is something life altering - maybe even historic - like launching rockets into space or solving world problems. Special is something unique, meaning you're the only place doing what you're doing. Special is a once in a lifetime opportunity that can't be passed up. In other words, if I can find a job close to home doing roughly the same things you're doing halfway across the country, I'm probably not going to be motivated to move. That's not a knock against you - it's just what I've decided is best for me right now.


More recently, especially in the technology industry, companies are starting to open up to telecommuting. Steve Jones (Blog |Twitter) and Robert Pearl (Blog | Twitter) recently shared their thoughts about it in You Can Telecommute and Telecommuting - Hype or Happening?. With what I've heard about how hard it is these days to find quality DBAs I don't think it's unreasonable to consider telecommuting if you think you've found the right person for your team. However, I also understand there's no replacement for in person meetings, so maybe a good middle ground is to be onsite for one work week each month. It seems reasonable to me, at least.

Are You Willing To Relocate?

I think it's a good idea to ask yourself this question from time to time because things can - and do - change. Maybe it's the unexpected downsizing that lies ahead, or more optimistically it's the next great job offer that you get after meeting someone at a SQLSaturday or the PASS Summit (or whatever conference you happen to be at).

I encourage you to take some time to think about what it would take for you to relocate for a job. It's a good exercise to go through, and you'll find yourself in a much better position to give an answer you're confortable with the next time someone asks.

Monday, August 29, 2011

Time Flies When You're Having Fun

I've done it; I've violated one of the rules I give to people who are interested in blogging: I went dark. It was unintentional, of course, but I'm still guilty nonetheless. The reason? Life's been really busy - both personally and professionally - and I let blogging fall to the bottom of the priority list.

After SQLRally 2011 wrapped up in May I took a self-imposed hiatus to recover and spend time focusing on family and a new role at work. Before I knew it, a few weeks turned into three months, during which I'd managed to publish all of 3 posts. It certainly wasn't for lack of ideas (I actually started a lot of drafts); rather a combination of work, vacation, and family time plus running MagicPASS, speaking at SQLSaturday South Florida, and helping plan SQLSaturday #85 (Sept 24 in Orlando) has just plan kept me busy! While I could have put more effort at night into finishing some of those posts I started, I found it a lot easier to plop down in front of the TV and catch up on the backlog of shows that had accumulated on the DVR.

That takes me up to a week and a half ago...

Who Moved My Cheese?

The aforementioned title (from the bestselling book of the same name) refers to dealing with change, and in this case it's change that's been unexpectedly placed on me. As of last week I'm looking for a new job. (In case you're wondering what happened, I'll keep things succinct and just say it wasn't my choice nor was it related to job performance)

Fortunately the SQL community has been an absolutely fantastic support. I have had numerous people offer words of encouragement, and many others have sent me leads on places that are looking for a new DBA. I've even had people send me short term contract work to help keep things afloat while I figure out where to go next. Words simply cannot express my gratitude. This experience is proof positive for me why it's worth taking the time to build a professional network and to help out other people whenever you can.

The good news? I've got some time to finish up on all those drafts I've started in the last few months. I'm also really looking forward to catching up with friends both old and new at the PASS Summit in Seattle in a few weeks.

Oh, and if you're looking for a DBA, I happen to know someone who is available. :-)

Thursday, December 31, 2009

My Biggest Weakness

I took some time off in December and I'm finally getting around to catching up on RSS feeds. Turns out I’ve been tagged by Ken Simmons to contribute to another chain post to answer the classic interview question "What is your biggest weakness?" I've been told in the past that the best way to answer this question is with something clever – like a strength that you call a weakness but you really spin into some form of self promotion to make yourself look better. But…I don't think you really want me wax poetic about how great I am (I don't want to either!) and this isn't a job interview, so I'm going to be honest because the only way we really learn how to be better is to recognize our faults and learn from them.

My biggest weakness: Letting go. Let me explain…

  • Letting go of opportunities – in other words, knowing when to say no. It's especially tempting to say yes when people ask you to do something that sounds exciting, but taking on too much can be detrimental. I think it's far better to be very successful at a few things than to take on too much and fail.
  • Letting go of responsibilities – in order to do new and exciting things you have to learn how to hand off responsibilities to other people. Think about it this way – at some point someone had to hand off their responsibilities for you to be in the position you're in today. This goes back to what I just said about taking on too much – if you just keep adding things on you're bound to fail at some point.
  • Letting go of being right – compromise can be difficult to accept and we all like to be right. The reality is that we're not always right and it's better for our personal and professional development to learn when to hold your ground and when to admit that someone has a better answer than you.
  • Letting go of things I cannot control – my friend Andy Warren recently told me "you can only control 50% of things" and it really stuck with me. There's no sense in spending time worrying about things you have no control over. The more time you spend on the things you can't control, the less time you have to focus on the things you can.

I've learned to deal with this particular weakness partly by learning from those who have "been there and done that" before me, and partly through experience (a.k.a. the school of hard knocks). It's not always easy letting go of things, but looking back at where I've been and where I am now I realize that it's something I've got a much better handle on now.

Thursday, December 3, 2009

Fix The Problem, Don't Just Band-Aid It

Let's face it, when it comes to computers there's a 100% certainty that something is going to break eventually. Maybe it's going to be a hardware problem like a drive failure, maybe an OS patch will break something, or maybe a new release of software contains a memory leak. It's this kind of stuff that's part of the reason production guys like me have a job; After all, if everything worked perfectly all the time there would be no need for a production DBA, right?

Throughout many years of working in production environments I've seen my fair share of problems. I've also seen many different ways that people chose to fix them – most good but some very bad. Perhaps the biggest mistake that I see repeated constantly is when people "fix" a problem with a band-aid or some kind of workaround. I submit the following examples:

Problem: A memory leak in a custom ISAPI DLL causes IIS to stop responding to requests after 8-10 days.
Solution: Dev can't reproduce the problem. Reboot the affected servers once a week. Dev is working on a complete rewrite of the software that will be out in 3 months anyways and this will go away.

Problem: An application log file is filling up all available space on the drive it lives on.
Solution: Move the log file to a drive with more space.

Problem: A SQL Agent job is failing intermittently with an out of memory error.
Solution: Set the job to retry 10 times with a 5 minute wait in between retries.

The issue I have with each of the proposed "solutions" to these problems is that they are not solutions at all – they're band-aids. In real life when we get a cut or scratch and put a band-aid on it all we're doing it masking the problem while our bodies work on the real fix underneath. Similarly, when something on a server is failing and we employ a workaround all we're doing is masking the real problem.

In the first example, the problem was actually happening on 80 servers. Asking the production team to reboot each once a week meant that one person was spending an entire day out of each work week to do the reboot. Further, since dev couldn't reproduce the problem that means they didn't understand it; how then could they guarantee that their rewrite would fix it? And what if the project timeline slipped from 3 months to 6 months because of feature creep, bugs, or mismanagement?

In the second example, the application log was growing because of database corruption. Moving the log file to another drive would have just given it more room to grow until the corruption was fixed.

In the third example, the memory errors were due to the fact that no page file had been configured in the OS. Setting the job to retry may have allowed it to eventually run successfully, but the real problem would have just manifested itself in other (potentially worse) ways.

To be fair, I'm not against using a workaround…as long as you continue working on a real solution to a problem. What I am saying here is don't consider a workaround a solution. When things break it's usually for a reason so don't ignore what your servers are trying to tell you by masking the problem and calling it fixed.

Wednesday, December 2, 2009

What It Means To Be A Production DBA

The Bobs Remember that scene from Office Space where the Bobs ask, "What would you say you do here?" I've been a production DBA for most of my 10+ year career and I've boiled down the non-technical answer to "I keep the lights on and the wheels turning". While it may be an adequate answer for a casual conversation, it's far from a fair description of what I do on a daily basis.

Recently I came across a blog post by Tim & Lori Edwards (Twitter: @timbo_b_edwards and @loriedwards) that I thought does a great job of answering that question and is worth sharing: What Is A Production DBA, Anyway?

Tim & Lori's blog – SQLServerTimes2 – is relatively new but they've got some good posts up so far. Go check out their post on being a production DBA, and while you're there take a minute to read their other posts and consider adding them to your RSS feeds.

Thursday, October 15, 2009

Off-Hours Work: A Guide For Non-Managers

In my last post I talked about how I think managers should approach off-hours work with their teams. It's a two way street, however, so today I'll share my thoughts on how non-managers (i.e. the rest of us!) should handle the situation.

Understand what's expected of you
Imagine you've been called in to work on a weekend and show up thinking you need to do A, B, and C while your manager really wants you to do X, Y, and Z. If you don't figure that out before you start working you're in for trouble. Do yourself (and your manager) a favor then and make sure you understand exactly what your manager expects to get accomplished while you're there.

Be the solution, not the problem
Sure, it's the weekend and you'd rather be anywhere else besides work. Guess what? Your manager feels the same way, and so do all of your co-workers. Talking about what you'd rather be doing or how much it sucks that you have to work on a weekend isn't likely to win you any sympathy points. Rather, it'll probably create tension and make you look like a complainer, and no one likes a complainer. Instead, focus on finishing what your manager called you in to do and remember the phrase, "If you don't have anything nice to say, don't say it at all!"

If you are unhappy – and sometimes you have every right to be – take a minute to write down your reasons then give it some time to let your emotions settle. Revisit your list later and see if you can create some positive suggestions for how to do things better the next time, then bring them up in a one on one meeting with your manager or at a post-mortem when people are open to constructive criticism.

Minimize distractions
Shut off TweetDeck. Avoid logging into Facebook. Close Outlook & Gmail. Do whatever it takes to eliminate distractions so that you can focus on getting work done (and as mistake free as possible). The plus side of working during off-hours is that no one's there to interrupt you with their problems every 15 minutes. With no distractions or interruptions you're putting yourself in a zone of super-productivity. The more productive you are the sooner you finish what you came in to do. The sooner you finish, the sooner you can go home and log into Twitter, Facebook, and do all those other distracting things.

Work first, negotiate later
When your manager tells you that he\she needs you to work outside of normal hours it's natural to try and negotiate up front for overtime pay or extra time off as compensation but I believe that you shouldn't if possible. Do the work first and then talk compensation once you know how much time you put in. By contributing to your manager's success first and putting yourself second your manager will probably be more than willing to help you out in the end.

Note that there's a difference in negotiating for compensation and setting expectations. For example, if you're getting called in but you had a previous commitment that you can't back out of it's OK to work out what time you can come in beforehand…but it's not OK to tell your manager that you expect a few hours off on Monday because you are coming in on a Saturday.

The Big Picture
We all value our personal time, but from time to time we're going to have to give some of it up to go into work outside of normal hours. When it happens, remain positive, focus on getting the job done, and be a professional about it. Handle it wrong and you'll have to dig yourself out of a proverbial hole, but handle it right and you'll earn yourself a few extra karma points which may come in handy at some point in the future.

Tuesday, September 29, 2009

Off-Hours Work: A Guide For Managers

If you work in software development or IT long enough eventually you're going to find yourself in a situation where you have to work during off-hours; it's just the nature of the job and can happen for a variety of reasons like: hardware failure, a new client is brought on that spikes CPU or bandwidth, or maybe you're just really behind schedule and need to catch up.

It's happened to me a few times in my career (and will happen again, no doubt), and after the most recent occurrence I started thinking about the best ways to deal with the situation. Today I'll share how I think managers should approach off-hours work.

Set expectations
You don't always have the luxury of time at your disposal (e.g. when hardware fails), but when you do the more advance notice you can give people so they can make plans the better. If you're telling people they need to work outside of normal hours then level with them, let them know what you expect, and be honest about it. Make sure they know that you realize the circumstances aren't ideal and appreciate their help. "Look, I know you don't want to work on Saturday, and neither do I, but we need to meet the commitments we've made. I need everyone here on Saturday from 9 AM until at least 5, maybe later if we're not done" will go over a lot better than "Be here at 9 AM Saturday and I don't want to hear any excuses!". Be sure to deliver the message in person or by phone, not by email.

Take care of people
If people are giving up their personal time for work you need to take care of them. Provide breakfast\lunch\dinner if they're working through those hours (and tell them in advance that you've got that covered). Make sure coffee\sodas\snacks are available. If the dress code is usually business casual then let everyone wear shorts to work if they want to. If everyone feels comfortable they'll be more productive and less hung up on the fact that they're working when they'd rather be somewhere else.

On the other hand, if people feel like you're forcing work out of them without concern for their well being you're not only going to have a bunch of unhappy people to deal with but you may end up causing long term damage to your credibility\working relationship with them. Reasonable people will only put up with that kind of treatment for so long before they move on.

Focus on the task at hand
The last thing people need is you standing over their shoulder saying "WTF" or to see finger pointing and hear blame. Likewise avoid the temptation to get distracted by talking about what you're going to do to keep from getting into the same situation again. Save all that for a post-mortem when you're back in the office during normal hours. People will be much happier if you help them finish what they came in to do so they can get back to whatever they really wanted to be doing in the first place.

Don't ask your team to do anything you wouldn't do yourself
I once had a manager tell me at 2 PM that I had to stay that evening to do a release to production. It was something he knew about for a week but didn't tell me about until that day. To add insult to injury, while I stayed until 2 AM to get the work done, he went home. He lost a measure of my respect that day that he never gained back. Don't be that manager – if you're going to ask your team to work during off-hours, be prepared to come in too.

The Big Picture
You've called in your team because you need something done that can't wait until everybody is back in the office during normal hours. You're asking them to make exceptions so be prepared to make a few yourself. If you handle the situation right at worst you've got some slightly unhappy but understanding team members. Handle it poorly and you'll likely be dealing with more problems than you started with. Seems like no-brainer stuff, right? Amazingly, some managers don't get it. On the other hand, neither do some employees. In my next post I'll flip the coin and talk about how I think about how they should deal with having to work during off-hours.

Tuesday, September 15, 2009

Networking While On Vacation

There's been a lot of attention given to professional networking (e.g. Andy Warren's blog posts) recently and if you recall I'm planning on kicking off my PASS Summit experience this year by attending Don Gabor's pre-conference session on starting conversations. It's perfectly reasonable to go to a conference, code camp, or SQL Saturday with the expectation that you're going to meet people who share a common professional interest and that you'd like to connect with, but how many of us put those networking skills to use outside of that context? For example, say you're going on a vacation...does your networking mojo go on one of its own too?

I just got back from a cruise celebrating my 10th wedding anniversary and on a whim before I left I grabbed a handful of business cards. Cruising can be a very social event if you want it to be – think thousands of people in the same setting for several days, and in most cases you run into the same people repeatedly at dinner, ports of call, and other activities around the ship. It's a perfect setting to practice conversation\networking skills. It turned out to be a good thing that I grabbed those business cards because I ended up meeting a sales rep for a large software company, a developer for a well known tax software company, and sat at dinner every night with a fellow IT person for a home hardware company. Will I gain anything from having given them my card? That's hard to say, but the chances are much better than had I not given them anything at all. One interesting note – of the three that I met, only one had a business card to give back to me.

The moral of my story – and the lesson I learned for myself – is to always keep those business cards with you, even when you go on vacation, because you'll never know who you may run into that you'll want to stay in touch with.

Monday, July 27, 2009

Interested In *Free* SQL Training? Attend A SQL Saturday Near You!

Can't make the PASS summit? Or maybe you're going but looking for something whet your appetite between now and November. How about attending one of these SQL Saturday events happening soon?

Why go to a SQL Saturday? How about:

  • FREE training – in additional to local presenters you'll get the chance to see pros like Steve Jones (Baton Rouge), Tim Mitchell (Baton Rouge), Michelle Ufford (East Iowa), and Andy Warren (South Florida). The speakers list isn't finalized for some of these events yet; folks like Brad McGehee and Joe Celko have been at past events so you never know what kind of talent you'll get the chance to learn from.
  • FREE swag like books, shirts, software, and other fun stuff to barter with back at the office (or keep for yourself!)
  • FREE food (depending on the event – some events ask for a minimal donation to cover lunch)
  • An opportunity to build your professional network by meeting other SQL DBAs & developers in your area

These events are also a fantastic opportunity for you to jump into public speaking. SQL Saturday focuses on local speakers and many events are still looking for speakers. SQL Saturday is how I got my start in speaking and helped me gain the experience and confidence necessary to speak at the PASS summit coming this November. Speaking experience is also a great addition to your resume. I encourage you to consider answering the call for speakers if you're interested in advancing your career or even just giving back to the SQL community.

On a personal note, I'm scheduled to present three sessions at South Florida on Aug 8:

We all know times are tough and many companies are cutting back on training budgets or cutting them out altogether. How can you argue with FREE training, swag, and food plus the chance to mix and mingle with other SQL professionals? Sign up for a SQL Saturday in your area today!

Thursday, July 23, 2009

So You Want To Meet People At PASS…But What Do You Say?

Going to the PASS Summit this November? Let's fast forward and pretend it's November 2. You've made it to Seattle and are at the convention center for the welcome reception. While there you spot so-and-so whose blog you read or so-and-so who you follow on Twitter. You'd like to  say something to them so you walk up and introduce yourself. Do you: a) strike up a meaningful conversation and finish by exchanging contact information…or: b) pause awkwardly for a few moments, struggling to figure out what to say next, only to walk away empty handed?

I'd be willing to bet that most people (including me) stand a fair chance of having answered the latter. In this day and age we tend to be pretty good at tweeting, texting, and emailing, but for many holding a conversation can be difficult. Unlike email which gives you time to articulate your thoughts (or delete them before hitting the send button!) on your own terms and time, holding a conversation is an engaging exercise that requires you to be quick on your feet. I've been in many circumstances where I've completely fumbled my way through the conversation, even with people who I know fairly well. It happens to the best of us.

There are a lot of people I know I want to meet at PASS this year and probably just as many more I'll want to talk to once I'm there. What do I say to break the ice? How do I remember their name? How do I keep the conversation interesting? This is PASS, the place for people who work with SQL Server to see and be seen. I'd rather not find myself in the middle of those long awkward pauses so I'm going to do something to help hedge my bets. Right before this year's welcome reception there's a special 2 hour workshop held by Don Gabor called "Networking to Build Business Contacts". I'm going and I think you should too.

$60 gets you into the session plus a signed copy of Don's book How to Start a Conversation and Make Friends. Not sure if it's worth it? Read Andy Warren's 6 part series (Part 1, Part 2, Part 3, Part 4, Part 5, Part 6) chronicling his personal coaching sessions over the phone. I happen to know Andy personally and I've seen him put Don's advice into action. Trust me, $60 is a steal for the kind of ROI that knowing how to hold a good conversation will net you.

The bonus is that not only will I pick up some valuable skills that I hope will last well beyond the conference but I'll get to meet some of the people on my list who are also going to the workshop (e.g. Tom LaRock and Grant Fritchey). If you're going to PASS and you care about building your professional network, I strongly encourage you to sign up too. If you do, make it a point to find me and say hello. Lucky for us we'll both know a few tricks to hold a great conversation.

Tuesday, July 14, 2009

SQL Quiz #4 - Leadership

Chris Shaw posts SQL quiz #4, I make an observation on Twitter about who gets tagged, Brent Ozar tags me for complaining being a squeaky wheel, and then I wait 3 months a really long time before posting a reply. Well, better late than never so here goes…

Question: Who has been a great leader in your career and what made them a great leader?

First I want to lay out my criteria for what makes a great leader:

  • A manager who keeps things moving towards a goal or in a particular direction
  • A motivator who keeps everyone enthusiastic about working towards that goal
  • Someone who challenges you to do things that you don't know how to so that you can learn and grow
  • Someone who sees your potential and puts opportunities in front of you
  • Someone who sets an example by walking the walk (the opposite of someone who says "do as I say, not as I do")

That said there are two people who stand out in my mind: Ryan (last name withheld to protect the innocent), a manager I've had in two previous jobs, and Andy Warren (last name not withheld – practically everybody in the SQL community knows who Andy is!).

Ryan was a lead developer at my first job out of college. He was a rock star – he "got" technology and software and he was the go-to guy that everyone sought out when they needed advice or help fixing a problem. On the other hand I had a "me" complex – I thought I was hot stuff so I didn't like Ryan much because I saw him as competition. It didn't take me long to realize that I knew squat and that I needed to get over myself and start learning from the people around me. I'm guessing Ryan noticed my change in attitude because after that he seemed to look out for me as he advanced into management. In particular he sent me for my CCNA certification and eventually put me in charge of the production infrastructure. Ryan later left for another job but sought me out to come work for him again where he put me into a role that helped me grow both technically and professionally. We worked together for a few more years before parting ways (permanently? who knows…), and I will always appreciate the doors that he opened for me. Of all the managers that I've ever worked for he was the only one that met every one of my criteria for a great leader.

Andy Warren
A few years ago I was introduced to Andy Warren by a coworker. Andy was looking for local speakers to give presentations at OPASS and, being the kind of person who's up for new challenges,I volunteered…and completely bombed it. But as bad as I thought it went, Andy still give me constructive feedback on how to do better and asked me if I wanted to try again at the first SQL Saturday in Orlando. I took his advice and did a much better job; In fact, I liked speaking so much that I started volunteering to give more technical presentations whenever the chance presented itself. I also enjoyed reading Andy's blog every day and thought about starting my own. Andy was more than encouraging when I talked with him about it, and that's always been the case with him no matter if I've needed help with something or just a different way of looking at things. I'm fortunate to have become friends with Andy and it's his leadership that helped me become active in the SQL community and lead to being selected as a first time speaker at this year's PASS summit. I hope that one day I have the opportunity to emulate Andy and help someone up and coming in the SQL community the way that he helped me.

I'm not going to tag anybody else since the train left the station on this one a few months ago…and I promise that I'll respond quicker the next time if I still get tagged!

Wednesday, July 1, 2009

The Best Thing I Learned At PASS

Note: I'm writing this as part of the "Best Thing I Learned At PASS" contest. Why? Because if I win it's worth a free registration or hotel stay for the 2009 Summit, and I like free!

Let me start by making a small confession: I've never actually been to the PASS summit in person. So how in the world can I write about what I've learned? Because I've been there vicariously through the blogs and Twitter streams of people who were there last year. Thank goodness, because before the rise of blogging\social networking if you had asked me what happens at the PASS summit I would have said…I honestly don’t know what happens at PASS besides a bunch of technical presentations given by people who write books and magazine articles for a living. My ignorance about what PASS is became clear to me last November as I read about the daily keynotes, the community sessions, and the nighttime parties. I came to realize that PASS is about so much more than just sitting in technical presentations. It’s about learning from people just like you who are doing the same things as you do every day. It’s about uniting with your peers and meeting new people who share a common interest. It’s about escaping the daily workload to reenergize and reinvigorate the passion to do our jobs as best as we possibly can when we return. So even though I haven’t been to PASS in person, I’ve learned one important thing: For the sake of my career, I need to go to PASS. If I can figure that out without actually having been to PASS, just imagine what I’ll learn when I do go this year.

Wednesday, May 20, 2009

Inside A Datacenter

I spent the last 4 days in Denver helping my company move in a new datacenter and while I was there it occurred to me that a lot of people have probably never seen the inside of a datacenter. I've been in 8 (that I can recall), and while that might not seem like a lot to seasoned hardware folks that's enough to get a feel for what makes these places tick (and understand the difference between a good facility and a great one).

Whenever I visit a facility I take a few minutes to walk through the aisles of racks and look at what hardware other people are running. I bet people probably think that datacenters are full of high end servers and SANs, but I've found that it's exactly the opposite. At the 3 facilities I visited on this trip I saw only a handful of SANs, maybe 1 per 20-30 racks. On the other hand, 9 out of 10 racks had at least one 1U server, 3 out of 4 racks had at least one 2U server, and 1 out of every 3 racks had at least one DASD drive enclosure. Regular readers of my blog may recall that I've done a lot of testing on drive performance for this kind of equipment. There are thousands of these servers in a medium sized datacenter and given the number of people I've talked to who haven't heard about disk alignment I'm guessing that adds up to a lot of wasted performance.

I also like to look at how people install their hardware in racks. Some installations are messy – cables strung about like spaghetti, no thought given to heat dissipation, etc.. A few make you stop and look twice because they're so pristine. On average I'd say that most installs are OK – not bad and done well enough to keep things running cool. There's definitely an art to installing servers in a rack.

If you end up spending any more than an hour working in a datacenter there are a few things to keep in mind. First, datacenters are climate controlled; they are cool and dry inside. Make sure you bring ChapStick to keep your lips from getting chapped and lotion to keep your hands from getting too dry. You should make sure to stay hydrated; you can't bring liquids into the facility so you'll want to remember to take frequent breaks to walk outside and get a drink of water. As I said, there are thousands of servers in a datacenter. It's loud. Wearing earplugs or headphones won't hurt. Walk outside if you need to hold extended conversations (especially on the phone – the person on the other end will appreciate it!).  You don't feel it while you're working inside, but the conditions can get to you. Between the dry air, lack of water, and near-shouting to talk to my coworker who was with me I just about lost my voice after day 2.

If you're interested in seeing a datacenter in person you can talk to your hardware\network admins and ask them to give you a tour; If you have even a mild interest in computers you'll probably enjoy the experience. You can always take a virtual tour too - the video below is from FORTRUST, one many facilities in Denver, and will give you a good idea of what's involved in running a datacenter. There are a lot more videos on YouTube of other facilities – just search for "Data Center Tour" (or save yourself the effort and just click here).

Thursday, February 5, 2009

Showing Your Value

As many expected, January brought with it a rash of layoffs and going-out-of-business announcements. Many agree that this is just the beginning and we’re in for a year full of bad news. Unless you’re the Rush Limbaugh type you have to have some hope that President Obama’s administration will get the economy moving again with a minimal amount of carnage. However, the reality is that change takes time and while those of us who receive a salary wait for it to happen we should be doing everything possible to show that we’re providing value to our employer because these days even people who are doing a good job are being let go. Being perceived as someone who is valuable instead of someone who does a good job could very well mean the difference between collecting a steady paycheck and looking for a new job.

Here are some ideas to help show your value to your employer:

  • Help improve productivity – Create an opt-in email distribution list for and share daily tips on how to use Management Studio, how to write more efficient queries, etc.
  • Educate – No doubt training budgets are tight and your employer will probably appreciate your help with keeping skills current. Solicit suggestions from coworkers on SQL topics they are interested in learning more about, create a presentation, and hold a series of brown bag lunch-and-learns. A side bonus is that you’ll develop something that you can present at a user group meeting, SQLSaturday, code camp, etc.
  • Volunteer – Seek out a project where you think you could contribute and offer to help out. Offer to write the stored procedures, optimize performance, or dogfood software.
  • Save money – No one will argue with saving money! There are a lot of ways to tackle this one: find an open source alternative to costly software, automate a manual process, optimize expensive stored procedures (thereby reducing the need to buy more hardware), or do some data mining to look for revenue leaks. Get creative and think big because the more you can save the company the bigger the impact you will make.

In addition to demonstrating value to your employer you will have some impressive things to add to your resume. In tough times like these showing that you are willing to go above and beyond may preserve your job or, in the unfortunate event that you are let go anyways, give you the edge in getting a new job quickly.

Friday, January 2, 2009

New Year’s Resolutions

2008 is in the rear view mirror and it’s time to participate in the annual tradition of making resolutions for the new year. Here’s mine:

  1. Learn…
    • PowerShell. I’ve got a soft spot for command line scripting and PowerShell finally brings Windows up to date with the kind of scripting that Unix\Linux has had for quite a while. It’s time to graduate from DOS batch files and grow up.
    • More about DMVs. They expose a boatload of information about server usage and performance, yet I only know a handful of them at best.
    • SQL 2008. It’s been out 5 months now and I’ve done little more than install it once on a virtual PC.
    • Analysis Services. I said the same thing last year. This year I mean it. No, really!
  2. Be a better mentor. For 2 years at my job I was the sole production DBA and got used to doing everything myself. This year my company hired a second DBA. It’s been a challenge to let go of certain things and this year I’ve got to do a better job of passing on what I know.
  3. Publish twice a week. When I started this blog I set a goal to post at least once a week. In 2009 I’m shooting for at least twice a week.
  4. Go to the 2009 PASS Community Summit. I have never been and from what I read I really missed out by not making it in 2008. I intend to go in 2009 – be it as a speaker, a volunteer, a reporter, or just as myself.
  5. Run a half-marathon. I need to take better care of my health, and that means more than playing Wii Fit every now and then.

I hope that you have a happy and productive 2009!

Friday, December 12, 2008

SQL Quiz Part 2

Chris Shaw posed another question in his SQL Quiz and I was tagged by Jonathan Kehayias this time, so here goes…

The question:
What are the largest challenges that you have faced in your career and how did you overcome those?

Answer #1: Being let go
One of the ways we define ourselves is by how well we do our jobs; we take pride in what we do (well, most of us do anyways) and nothing makes you question your skills, worth, and value like being let go. Call it the professional version of being dumped by a significant other. I was let go once and it completely blindsided me. Not only did my supervisor tell me I had nothing to worry about but I thought I was pretty well respected as the go-to type of guy. My coworkers even told me I was irreplaceable - “they’d be stupid to let you go!”, they said, and I bought it. Wow was that a big mistake. To this day I remember the surreal feeling of sitting in my supervisor’s office and hearing him explain in what seemed like slow motion what was going down. To top it off, it was 5 days before Christmas and I had family visiting in town.

How I got over it:
I went through the typical range of emotions that come with a life altering event like this. But once I got over my anger\resentment I realized that for once I was going to be able to enjoy Christmas. No beeper. No 3 AM calls from the NOC. No piles of work waiting for me when I returned after the holidays. I was fortunate enough to receive a decent severance which allowed me to take a couple of weeks off and just enjoy life, and it was wonderful! The timing ended up working in my favor, too, since most companies start looking to fill positions Jan 1 when budgets kick in and money is available. While I looked for a new job I was able to reconnect with colleagues I had lost touch with, travel the state to visit siblings I hadn’t seen in a while, and spend more time with my wife and kids than I ever had the chance to do while I was working. Looking back, it was probably one of the best two months of my life! Now I’m a firm believer that things happen for a reason, and since my departure my former employer has changed (putting it politely). My supervisor and his supervisor were both let go not too long afterwards and the company “partnered” with a larger company that turned around and outsourced most of the business. The stories I hear from my former coworkers me make me realize that I would probably be so dissatisfied with the environment now that if I hadn’t been let go I would have left on my own. Although it sure as heck didn’t seem like it at the time, I realize now that being let go was a blessing in disguise and I am in a much better place today because of it.

What I learned:

  • No one is irreplaceable. The minute you think you are something will happen to change that.
  • Things happen for a reason. You may not understand it first, but give it time and you will.
  • Sometimes you just have to play the cards you’ve been dealt, even if it feels like a raw deal. It’s how you play them that makes a difference in the outcome.

Answer #2: Finding the right balance between work and life
It’s easy to become so consumed by your career that it can happen without you even realizing it. I was so balls to the wall at my first job out of college that I would work at any time of the day or night I could to get my job done. I was recently married, didn’t have kids, and my wife knew the value of doing well so she encouraged\supported me. Fast forward to about three years ago when I had two kids and a career on the rise. I was was pushing 80 hour work weeks which was great for my company but not for life at home. Somewhere between hearing my kids say (on more than one occasion) “daddy works all the time” and telling my wife “things will get better, I just need to get through this project” for the umpteenth time is when it hit me that I was spending more quality time with my computer than with my family. Shortly after that, the events in my first answer played out.

How I got over it:
I’ve come to realize that I don’t have to be a superman to do well, nor do I feel like I have to do it all anymore. When scheduling things that need to happen outside of normal hours I make it a point to find a time that doesn’t conflict with my responsibilities at home. Instead of working until 8 PM I’ll leave the office at a normal time, take a break for a few hours and spend time with my family, then go back to it once my kids are asleep. Or, as appalling as this might sound, I simply leave it for the next day. Working all the time wore me down, both mentally and physically; On the other hand taking a break gives my brain a break, which in turn makes me more productive and more friendly. I get that emergencies happen and there will be times when I have to drop everything and work for a few hours but now they’re true emergencies and not the artificial ones I was creating for myself.

What I learned:

  • Going all out to do a good job is admirable, but not when it comes at the cost of those around you. A job should be a means to an end, not an end unto itself.
  • Take time to take a break from work. Find a hobby or spend more time with your family. It will make you a happier and more productive person.

OK, time to tag two more people. Andy Warren and Jack Corbett, you’re it!

Monday, November 17, 2008

Two Mistakes

Two mistakes was a post started by Chris Shaw that’s been making the rounds of SQL bloggers as each poster challenges others to write about their mistakes. There’s a Chinese proverb that says “Even a wise man sometimes make a mistake”. Andy Warren seems to think I’ve made a lot of mistakes and tagged me in his post. He must think I’m a pretty wise man.

Mistake #1:

I inherited this mistake, but since I didn’t correct it before the fit hit the shan it’s on me too. About a year and a half into my first job out of college I inherited the role of IT Manager after the person who had the job was let go (it was a small company, obviously). One of the first things I did was to make sure we were backing up our databases. We were, but there was something looming that I was too naive to know about at the time. We only had one SQL Server – a Dell connected to a PowerVault DASD array. Problem #1 was that it was configured as RAID 5 and for about six months there was a failed drive that no one noticed. Problem #2 was that the backups were written to a partition on the PowerVault. I think you can see where this one’s going – about two weeks after I took over we lost a 2nd drive in the RAID 5 array and the server took a nose dive. Worse yet, it happened while I was out of town and the junior guy was on call (if I was a year and a half out of college at the time, imagine how junior the junior guy was!). It cost us a LOT of money to work with a drive recovery company to get some of the data back, plus a week of lost sleep and red-eye flights to the datacenter to rebuild the hardware. I also learned for the what it’s like to spend a night on a concrete bench in the Atlanta airport. Oh and we had to explain to all of our clients why they were down for a week.

What I learned: Don’t store your backups on the device you’re backing up. Monitor your hardware for drive failures. If you inherit something, don’t ever assume the person before you did it right; look for the skeletons in the closet and fix them ASAP. Bring a travel pillow with you whenever you go out of town.

Mistake #2:

At one of my previous jobs I was on a team of people responsible for the daily care and feeding of our software in production. Our responsibilities included database administration, release management, manual intervention for tasks that hadn’t been written into the software yet, and occasionally fighting fires when something unexpected came up. We used MSMQ pretty extensively, and during a release our release manager pushed a configuration file that pointed the software at a non-existent MSMQ server. It only took us about an hour to realize something was up because there were dollars tied to those messages and the numbers were down from where they should have been. We took the divide and conquer approach to fixing things and somewhere along the way two servers were left with the bad config. This was in the days of Windows 2000 which does this funny thing with MSMQ where an outbound queue will accept messages without error but after the outbound queue size hits 2 GB it will just send those messages into the ether. No errors, no warnings, nada. So sure enough, those two servers with the bad config hit their 2 GB limit and happily threw away everything after that. We never realized a thing because it was two servers out of eighty and we were busy looking at the big picture rather than paying attention to the details, and of course we didn’t have anything monitoring MSMQ outbound message counts. When revenue came back to around what we expected no one double checked that every server was contributing an equal amount. Needless to say, it was some time before we figured out that those two servers still had a problem, and by the time we did it was too late to recover the messages – and the dollars – that were lost.

What I learned: Good communication is vital for success. Pay attention to the details! If you fix a problem, be skeptical - check, double-check, and triple-check that you really fixed it. Never underestimate the importance of monitoring, or the costs associated with not doing so.


Time to pass it along…Jon Kehayias, you’re it!