Art of the DBA Rotating Header Image

career

We Are All Developers Now

Last year, I had a pretty intense conversation with a friend of mine at a SQL Saturday. It was one of those that started with the typical “grumble grumble grumble damn devs” statement. There was a time I would have echoed that with a hearty “harrumph harrumph”, but as I’ve progressed through my career, I’ve come to realize that the line between developers and DBAs has softened and blurred, particularly in the age of DevOps. What followed was a back and forth about the habits of DBAs and developers and lead me to a phrase I’ve added to my lexicon: “We’re all developers now”

I know, I know. What about the long standing division between righteous Operations folks (DBAs, sysadmins, network engineers, and their ilk) versus the .Net, Java, Node, and other heathens of the Developer world. These “barbarians” assail the fortresses of Operations with hastily written code that is not properly tested. This causes sleepless nights filled with pages  that a weary admin must respond to and resolve. Why would anyone in their right mind associate with these irresponsible practices?

Borrowing From Your Neighbor

The first step to answering this question is to step back and actually look at what happens in the developer world and compare it to what we do in administration. It’s a common practice to borrow code and practices from our peers in the SQL world, so why not do the same with those who develop other types of code? Especially those who develop code for a living (hint: consider the recursiveness of this statement).

As an administrator, I created all sorts of administrative scripts. Obviously I’ve got a reputation for PowerShell, but I also have T-SQL scripts that I use as well. For a while I would hack these together as any other good DBA and store them on a USB/Dropbox/Google Drive/OneDrive. It was functional, but I only ever had the current state of those scripts and didn’t always know why I changed things. I could put in a header, but this was tedious and manual, an anathema to how I work.

Enter my time at Xero. I hadn’t really used source control before and the teams there used it heavily. I got a rapid introduction to GitHub from Kent Chenery(@kentchenery) and Hannah Gray(@lerevedetoiles). It didn’t take long for me to realize the benefits of source control, not just for databases, but for my own personal scripts. Now I maintain my own personal GitHub repo and not only have a central location where my code is stored, but it can be shared with others who can contribute and collaborate.

Code, Rinse, Repeat

After adopting source control, I began to look at other developer practices and habits. While one can debate the pros and cons of Agile development, one of the concepts I like is iterative development. As with other work we do, iterative development isn’t rocket science, but it took me a while to adopt it because of a natural fear admins have: production paranoia (aka “what will this break”).

Admins of all stripes are in constant fear of breaking production, and for good reason. We want every change to be right and as close to perfect as possible. However, most folks who develop iteratively realize that perfect is a road block. It is hard to anticipate all the factors. When you develop iteratively, you ship what you can and fix/fail fast once you deploy it.

I’ve adopted this approach for my own script/process development. Whether I’m publishing a script or deploying a server, I focus on delivering a product. I test aggressively, but I’m prepared for the event that something will fail. I focus on the feedback loop to test, evaluate, remediate, and deploy. As an aside, this feedback loop is often where application developers will fail, because they are often driving towards the next set of improvements or features. It’s incumbent on both sides of the fence to adopt and enforce the feedback loop.

It’s All Just Ones and Zeroes

I could go on about habits I’ve adopted, but the real question is “why are developer practices important to administrators?” As we move into a realm of automation and scripting (as any good admin will), we are doing more and more code development. Sure, we can click through GUIs to setup SQL Server or run a backup, but the more experienced folks out there will have scripts to accomplish these tasks. Network and system admins are deploying infrastructure to the cloud using CloudDeploy or ARM templates. We live in an age where almost everything can be codified.

This codification means it is imperative that we focus on good habits for managing our code. It might be that we’re writing T-SQL code for SQL maintenance. Perhaps we’re writing shell scripts to execute code deploys or build a continuous integration pipeline. Suddenly we’re developers of a different stripe.

So what do you do about it? You probably haven’t implemented some of these habits and, likely, you might be a little mystified on how to get started. I suggest you start where I started: Go to a developer and talk to them. Maybe chat with a couple. Go to a local developer user group and see what they’re talking about. This is about learning, so find a mentor who can help you learn this topic.

And who knows? Maybe you can teach them a few things about your world while you’re at it.

Be Like Water

“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.

Bruce Lee

 

If you look around the internet, you will come across this famous quote. Often cited by arm chair philosophers (myself included), these simple sentences speak on being flexible and adaptable within your life and how being too rigid can limit us. These limits will make it difficult to truly grow and improve ourselves, whether it is our professional or personal lives.

We can break this quote down in many ways, but I’d like to focus on how it impacts technology professionals. One thing I love about working in technology is how often things change. The joy comes from the constant learning we must do to keep pace. If we’re not pushing ourselves to explore and discover, we risk falling behind and losing our way.

Empty Your Mind

If we look at the IT career path through the lens of Lee’s quote, the idea of flexibility becomes obvious. Through my time in the IT industry, I’ve seen the rise of the Internet, the cloud, concepts like Agile development and DevOps, and other changes that range between large and subtle. If I’ve learned anything, it is that defining myself as a DBA, sysadmin, or developer limits what I am willing to do and narrows the opportunities available to me.

When someone asks you to take on a new task, how do you approach it? Do you look at it through the lens of your job role? Or, instead, consider how it relates to your career path? Do you determine what you want to work on based on what you know and are comfortable with, or do you let the opportunities shape your growth?

As technology professionals, it’s important not to limit ourselves. Today’s experiment might be tomorrow’s trend. A hobby we tinker with could easily become our driving passion. We need to be receptive to what’s around us, be formless and fill the demands that are presented to us. Do not close yourself off to challenges because you haven’t done them, but be prepared to know what it takes to fill those vessels.

H Two O

This probably sounds daunting because there’s so much going on in the technology world. Should we be able to do anything? Be ready to build networks, write applications, design databases, and so on? How do we keep up with the overwhelming number of disciplines and developing technologies in our world?

I’ve long held that the “full stack developer” is a myth. We live in a world of specialization and trying to have deep knowledge of all disciplines is impossible. Sure, we can understand something of everything (being a jack of all trades, master of none), but it becomes difficult to bring the full weight of our expertise to bear if we only know a little bit of a lot of things.

At some point in our careers we need to understand what makes up our “water”. This brings me to another long held view of mine: technologies change, but concepts remain the same. The example I like to use is relational databases. Over the years we’ve had platforms like Microsoft SQL Server, Oracle, MySQL, PostGREs…the list goes on and on. Each of these platforms introduces new features every few years, trying to one up each other.

At the core, though, each of these platforms is a relational database. The relational model was codified by E.F. Codd back in 1969. Think about that for a moment. While Microsoft SQL Server is adding new features every few years, the foundational concepts that we all work with are forty seven years old. Almost half a decade of a technological principle that we build our careers on.

I don’t consider myself a SQL Server professional. My skill set is not limited to just SQL Server as a platform, but relational database design and data management. I am strongest with Microsoft’s offering, but I can adapt to another platform because I understand and own the foundation. The core concepts are what I build upon, which is what makes me stronger and more prepared.

Be Like Water

Becoming like water is more than just being adaptable, it’s about understanding what defines you. Job roles and requirements are just vessels we fill with the knowledge and experience we have. If we choose to be like water, we remain fluid and can, at once, fill the needs of a role as well as be more than that.

Be the sum of the things you have learned, not the tasks you can accomplish. My challenge to you for the new year is to build a deeper, more fulfilling career. Flow and adapt, learn and absorb. Empty your mind and be open to the numerous possibilities in front of you.

Be like water, my friend.

T-SQL Tuesday #84: Getting Ready for your Presentation

boy-speech-lettersI’ve been super busy lately, but I wanted to at least post something for this month’s T-SQLTuesday. The topic is about encouraging new speakers, something I’m very passionate about. I think that speaking is one of the best things you can do to boost your career. If you are reading this and are considering speaking, I encourage you to reach out to your local user group and see if you can get started with a 15 or 30 minute session. Take a shot, I’ll bet you’ll be surprised.

What I want to share are some tips for the day you give your first presentation. A lot of folks are going to talk to you about building and preparing your presentation, but that is only half the battle. What you should do when you actually GIVE the presentation is often glossed over, even though this is the most high pressure moment of the whole cycle.

How do we reduce or relieve some of this pressure? Well, let’s start with a list of things that could possibly go wrong when you present. Think about the following list:

  • You’re presenting and you get an on-call page.
  • Your demo blows up spectacularly.
  • While giving your presentation, your computer attempts to apply updates.
  • You start 10 minutes late because you have issues with your video or sound.
  • During your presentation, someone sends you a picture on your favorite IM client:

oh_hai

Any of these will easily throw an experienced presenter off their game. For a new speaker, it can spell disaster. I’ve got a routine that I go through on the day of my presentation, which is designed to reduce that risk of disaster. And who doesn’t like reduced risk?

Getting Ready

Step 1: At the beginning of the day, well before my presentation, I make sure my presentation machine has been updated with Windows and other corporate software. This is SUPER important if it’s a Tuesday (when Microsoft releases updates). Doing this avoids any update surprises while I’m presenting or right before I go on stage.

Step 2: A couple of hours or so before my presentation, I will walk through my presentation. I open up the PowerPoint slide deck and step through it. When I get to demos, I will walk through my demo scripts. I test EVERYTHING, and do it in order. If I encounter an error, fix it, and then start over. This helps me insure that the flow works and that I understand what the step dependencies are in my demo.

Step 3: About an hour before my presentation, I will turn off everything on my presentation machine unnecessary to the presentation. Programs like Skype, Google, unneeded local SQL instances, Virtual Machines….so on and so forth. I only want what I need running to make sure that I have enough resources for my demos, along with keeping possible distractions shut down.

Step 4: At least 15 minutes before I’m due to present, I go to my room and hook up my presentation machine. I test the video and make sure my adapter works. This way I can address any tech issues that could hamper the presentation. I will display PowerPoint and also my scripts and demos to make sure everything looks ok.

I also usually duplicate my screen to the projector. This is important because if I extend, this means the only way (typically) that I can see what’s on my screen is to look back at it. This is distracting for your audience. If you duplicate, you only have to look down at your screen, which maintains contact with the audience.

Step 5: Right before I present, I turn my phone OFF. Then I put it in my bag. I get it away from me. I don’t want to get calls, I don’t want to have to worry about silencing it, and I don’t want it buzzing in my pocket if I’ve got a lot of notifications. The phone is off and away.

It’s GO time

At this point, I’m free and clear to do my presentation. Does that mean that nothing will go wrong? Of course not. However, performing these steps puts me in the best position to give my presentation without disruption. It is a foundation for success. Just like we build out our database solutions to minimize the option of failure, we need to approach our presentations with a similar sort of care to help guarantee our own success.

I want to thank Andy Yun(@sqlbek) for hosting this month’s T-SQL Tuesday. It’s a great topic and I hope folks get a lot out of it. If you’re considering stepping into the speaking world (and you should!), this month’s blog posts should give you all the tools to succeed. Good luck!

Three Things I Want From My Job

I’ve been off for a while and I apologize for that. The beginning of the year has been crazy and I am just now getting my feet back under me. The short version is I recently changed jobs and have started working for UpSearch(@UpSearchSQL) as a SQL Server Consultant. This is an exciting change for me, full of new challenges and opportunities.

Blah blah blah blah, right?

Without making light of the change, I know you all hear this every time someone starts a new gig. This post is not about that, but about some reflections I had about why I changed jobs, what satisfies me at work, and the reasons we do this stuff in the first place. I want to share these thoughts with you to hopefully help you broaden your perspective on why you are at your job and what it is that keeps you going back (besides the obvious paycheck).

Three Things

When it comes to our jobs, whether we’re interviewing for something new or looking back on our current position, we should have a list of what keeps us happy. After all, we measure and track statistics around our databases and compare them to a baseline. It should be no different for our careers. This list can be as detailed or broad as suits you, but you should have something. My list is actually pretty simple, consisting of three questions that I ask myself:

  • Am I compensated fairly?
  • Am I working on cool s#!t?
  • Am I respected?

These questions do not have simple answers, but they do have answers. As we go over each question, hopefully you start to see how they might apply to you.

Compensation

This probably seems the simplest. After all, we all get paid and we want to make sure our salary is competitive to the market, right? This definitely is something we should be thinking about and reviewing. It also takes a bit of self honesty about our capabilities and how they match to what is being paid for. Are we senior or mid-level talent? How much do we drive value for our employer? Salary is very much a two way street.  If we want to be paid fairly, we need to demonstrate our worth.

Of course, we also need to keep in mind that compensation is far more than just salary. I’ve worked jobs where I got paid pretty well, but had to fight to go to conferences like the PASS Summit. Some jobs had liberal vacation policies while others offered the minimum. When you consider your compensation, you have to ask yourself what keeps you happy from a larger perspective.

Coolness Factor

I’m the kind of guy that needs to be challenged. It is why I spend time blogging and presenting, as well as playing with different kinds of technology. This is how my work fulfills me. I could simply punch the clock, work from 8 to 5, and collect my check, but this wears thin pretty quickly. I need more in a job than just going through tasks by rote so I can go home at the end of the day.

This is why it is important that I get interesting work. I need problems to solve and challenges to overcome.  To be clear, I understand that I will have to do the tedious stuff as part of any job. Work like this needs to be balanced out, though. Heck, sometimes the challenge of managing the tedious stuff in a more efficient manner is engaging in and of itself. The key is that I want my job to help me grow, not allow me to tread water. Job satisfaction is measured on this growth.

R-E-S-P-E-C-T

This last item is the linchpin. For the longest time, I was happy with the first two items on this list. Then one day, I sat up and realized that I was getting worn down by my job. I couldn’t quite place my finger on why, because I was getting what I wanted out of compensation and the work was definitely cool and challenging. The problem was I was struggling with going into work every day and my motivation was rapidly draining.

The key, I realized, was a matter of respect. Whether it is peers, team members, or management, I need the people I work with to respect my time and my knowledge. This may seem a little arrogant, but it is important to recognize your own value. Companies hire me to be a database expert, and an expensive one when you boil it down. This means my time and opinion carry a certain amount of cost, and when that cost is being wasted because others in the company do not recognize that value, it becomes wearing.

Without trying to sound too negative, we need to understand our professional value. As with the compensation question, it takes a lot of self honesty to value ourselves appropriately. It is important to recognize that within ourselves. This is because it is an important factor for job satisfaction, because not only should we recognize that value in ourselves, we need others to realize it and respect it.

Can I get a little satisfaction over here?

Job satisfaction, while ultimately a binary yes or no answer, has a lot of degrees of measurement. After all, I can think of jobs I’ve had where the pay was fantastic but the environment sucked. Or where the entire team thought I was a rock star, but I was not working on interesting or engaging work. When I felt my job satisfaction going down, I could always track it back to one of these three items.

What is important here is that by understanding what satisfies you at a job, it gives you a tangible item to resolve. It might simply be a matter of going to your boss and telling him what the problem is. This gives you something tangible to work on with your employer and is fair to them, because chances are they don’t want to lose you and will work with you. It also may mean you need to find another job that fills that gap. In this case, when you sit down in an interview, you can have a conversation with the person across the table about what fulfills you.

Whatever your reasons are, it is important that you know why you get up in the morning (or other time) and go to work. Your reasons are probably different than mine, as these tend to be pretty personal. I hope that by giving you some insight into what job satisfaction means to me, it can help you build your own list of questions. Measure your job satisfaction, know what makes you happy, and then figure out how to get it.

The #SQLNewBlogger Challenge: Git ‘er done!

This week my friend Ed Leighton-Dick(@elieghtondick) announced his New SQL Blogger challenge.  It’s an effort focused on getting new bloggers to write regularly and build a habit of blogging. We’ve heard a lot about how blogging can build your personal brand, so I’m a big fan of this challenge and will participate, even though I’ve been blogging off and on for the past few years.  So far, some big names have come out in support of this challenge. Awesome to see. Not to try and ride their coat tails, but I want to add my own thoughts because I think it’s incredibly important to participate.

Most community members will be intimidated by this challenge. I say this because I’ve heard (and said) all the excuses that are probably going through your head when you think about blogging.  I want to show you how you can overcome that intimidation and participate successfully, jump starting your blogging career.

I don’t have anything to blog about

I hear this all the time. Really what people are saying is “I don’t have anything valuable to blog about” and I completely call shenanigans on this attitude, for much the same reason as why I tell folks they should start presenting. Everyone has something to share. Even if you think it’s simple or a no-brainer, I guarantee you someone will benefit from your knowledge.

Let’s consider why new bloggers get so intimidated. The perception is that current bloggers, especially the BIG names, always seem to have some clever script or gotcha to contribute. Something no one else has ever thought of. It’s a tough act to follow, especially if you are just getting started.

However, to butcher a song lyric, “Any blog is a good blog”.

I always recommend that new bloggers approach their blogging as self documentation. Write for yourself, don’t expect anyone else to read it (and if they do, BONUS!). There have been a number of times where I go back to my blog for a technique or script I wrote in the past. It’s a great entry point to get you to started writing and reduces the “freak out” about other people reading what you wrote.

They’re All Going to Laugh at Me

This could also be the “what if I’m wrong” clause. For new presenters and bloggers, there seems to be a permeating fear about getting called out for something wrong or bad that they publish. I’m sorry, have you met the #SQLFamily? What I love about the SQL Server community is that most folks out there are extremely supportive and helpful. If something is wrong, the community will help you fix it and learn from it.

The bonus of doing this in the internet is making corrections and updates is easy. If someone corrects you or shows you a better way, you can blog about it! If there’s an error, you can fix it! Consider your blog a living diary that can be adjusted as necessary. The only caveat here: Be public about your changes. Either write a new post or make an addendum calling out your edit. Stealth edits look fishy, be public.

Who Has Time To Blog?

Blogging is like any other part of your life where you need to grow: you need to make time for it.  It doesn’t have to be much, an hour or two. The trick is to schedule it like any other commitment and stick to that schedule.

My routine is to write every Saturday morning. I found a nice little tea shop near my house and include that in my morning routine:

  1. I’ll walk to the tea shop around 9 AM. It’s a 30 minute walk and gives me time to think about what I will write about. Plus, the physical activity energizes me.
  2. Once I get to the shop, I order my tea and breakfast (oatmeal, ‘cause I’m trying to lose ‘dat weight). Then I find a space, get plugged in, and start writing.
  3. The writing process is very stream of consciousness. I use Google docs and basically just spitball out what’s in my brain. I don’t worry so much about grammar or sentence structure, the idea is to get my thoughts on paper. This also might include hacking out scripts or testing the stuff I’m blogging about if it’s technical.
  4. Once the writing is complete, I’ll take a Twitter/Internet break (note, I shut Twitter down during the writing, reduce those distractions). Not long, maybe 15 minutes.
  5. After the break, I’ll do one major pass to clean up sentence structure and grammar. Then I shut it down and go home.

 

It should be noted that at this point the blog isn’t quite complete, but the bulk of the work is done.  Next steps for me are to get to get the post into WordPress and schedule it. I always schedule my blog posts for Tuesdays at 8 AM MDT, giving myself a deadline.

You need to commit to this to make it work. The best way I’ve found to hold myself to commitments is to set deadlines. Need to build a presentation? Commit to giving it on a specific date. Need to get a blog post up? There’s my weekly publish deadline. Will you hit those deadlines every the time? Probably not, but as long as it’s not a habit and you don’t let yourself get away with missing a deadline, you’ll be fine.

How Can I Help?

While I think this is a great challenge, I think it’s fairly obvious I’m not a new blogger. How I’m participating is lending my less-than-expansive blogging experience to get others started. This post is the first portion of me owning the challenge as I hope to show you the path to getting started. There’s yet more that I can contribute. So here’s the next steps:

  • Need someone to review your blog before you post it? Hit me up.
  • Want to bounce blog post ideas off of someone? I can do this.
  • Lacking inspiration for what to blog about? Let’s talk.

Let me help you make the most of this challenge. I’m not a expert, I’m not a big name, I’m just a dude doing his SQL thing. But I think I can share some of that with you to make the road a little easier.  Email me via mike at this blog.

Own that $#!+

Blogging, like presenting, is a huge part of building your career and personal brand. It will make you more visible to your peers, help you retain knowledge, and improve your writing skills through practice. By blogging you strengthen the larger SQL community by adding to the pool of tribal knowledge as well as making yourself a stronger member of that group. Remember, you have something to contribute, a unique piece of knowledge that you can share with your comrades in the community. I encourage you to step up and answer the challenge.

Validation and Inspiration

I’d like to take a brief break from the technical posts to talk a little bit about community. As I write this, I’m currently heading back to Denver from SQL Saturday Phoenix. As with other SQL Saturdays I have attended, this was a fun event with lots of great learning and camaraderie with my fellow SQL geeks. This is a bit of a love letter to those geeks, but I wanted share with you some of the impact this event had on me.

Validation

As with everything else I’ve done in 2015, my presentation at this event was Powershell related.  I gave a presentation on Powershell Tips and Tricks for SQL Server DBAs for the third time this year and was pretty pleased with my execution. What blew me away was the reception from the audience. I had a ton of positive feedback and comments and could tell the attendees really appreciated what I shared with them.

Why am I telling you this? Because I want to convey to you why you should present and the benefits of it. It’s more than just having your ego stroked or getting that pat on the back (though those don’t hurt). When you share your knowledge, you have an immediate and profound impact on other people’s careers. Each and every one of us has something that others can benefit from.  We need to share it. To know that I showed my audience a better way to do their jobs and help them step up to another level is extremely gratifying.

Much is made of technical presentations being used as a vehicle for advancing your career. They are also a vehicle to advance the careers of your peer group. The great thing is the more we help each other, the more we help ourselves and make our skills and abilities stronger. I could see this in the gratitude of my audience and the feedback they gave me from my session.

Inspiration

What I like most about technical conferences is not just the education and the sessions. These are valuable for both the presenters and attendees, but the true value is gained in the conversations that happen around the event. This is why it’s so important to make time to talk with the other people at these events, to chat with speakers, and to avail yourself of the social aspects. You’ll find inspiration for solving problems at work, developing new strategies for your current position, or defining the next moves in your career.

I had several such conversations while I was at the event. Coming away from this SQL Saturday, I was able to help some of my peers with strategies and ideas for their blogs, their presentations, and their jobs. Beyond that, though, I was inspired for other things I could do to both improve myself and my career.

One example was a conversation with Amy Herold(@texasamy), where we talked a lot about Powershell and automation. She gave me a few ideas that I could further develop and we talked about some projects we could collaborate on. I’ve got some exciting ideas that I hope to work with Amy on over the next few months that will help both of us grow.

It’s hard to have these kind of conversations during our day-to-day jobs. Since we’re usually only one of a couple people (or maybe the lone gunman) doing data work in our jobs, it’s difficult to bounce ideas off of others and get that inspiration. You’d be amazed at what kind of thoughts you will get when you have really smart people to talk with.

Satisfaction

The reason SQL Saturdays are such great events is it allows the greater SQL community to share, connect and learn with one another. If you haven’t been to a SQL Saturday, I strongly encourage you to go. I know it’s sometimes tough, being on a weekend when some of us would rather be getting along with our non-database lives.  I want you to think about what you could do with your career, though, if you gave up that one weekend. Where could you go if you could have that kind of free learning. Most of all, how much better will you be by plugging in to the SQL community and feeding off the energy and knowledge you can find at these events. Building your career is more than just learning, it’s collaborating and sharing. SQL Saturdays give you all of this in spades.

 

#tsql2sday 52: Stop depending on “it depends”

depends-on-who-is-askingIt seems to be a standard practice for data professionals to say “It depends” when asked for suggestions, recommendations, or outright solutions.  This isn’t surprising, because in the “magic” world of technology the actual solution for a problem usually requires some very specific information and that any number of solutions could work.  Add in to this the nature of our world usually puts you at the whip end when things break, so we are natuarally hesitant to draw a line in the sand.

Stop it.

Let’s face it, much of what we do is fairy dust and moonbeams to those outside our industry.  They don’t understand what we do, just that we make it happen.  And that’s what managers, directors, veeps, and c-fillintheblank-os want when they ask us questions: How can we make it happen and/or how to we make the broken thing go away.  The problem with saying “It depends”, especially in situations like that, is that it sounds more like “I don’t know” and that’s not what you’re getting paid for.  You’re the technical expert.  Whether you’re a consultant or a full-time employee, a seasoned veteran or a fresh-faced n00b, you’re being paid to understand the technology and be able to implement solutions.

Many data professionals, however, are afraid to take this sort of stand.  A lot of this stems from the tremendous amount of risk involved, particularly when tied in to the heavy responsibility we tend to bear.  Our job is to protect the company’s data assets and if we screw up it’s not just our head, but it could be seriously damaging to our company.  So we like to hedge our bets.  Unfortunately, a lot of people in our profession will use the phrase “It depends” as a dodge because they’re afraid of completely taking on that responsibility.

Ultimately, they’re afraid of failure.

It’s a common mantra in life coaching that we can’t be afraid of failure.  Failure is what we learn from and how we grow.  Make a mistake, analyze it, and grow from it.  We’re only human, however, and screwing up is scary.  We don’t want to look bad and we don’t want to get in trouble.  That doesn’t help the people who are looking to us for help.  This is when saying “It depends” as a shield turns into a roadblock, hindering both you and your organization from getting anywhere.

So what do we do about it?  Next time someone asks you for a technical opinion and you don’t have enough detail, ask for that detail.  What’s the RTO/RPO? How quickly does this need to perform?  What’s our budget?  Questions like that to refine the answer.  Maybe outline a solution, but caveat it with qualifiers, such as “I’d probably put tempdb on SSDs, but that assumes we can afford that sort of hardware.”  Maybe there’s a better way to do it, maybe you’re just wrong.  But it’s ok to make a mistake, as long as you’re not making the same mistake.

Most of all, I’d suggest to simply remove “It depends” from your vocabulary.  There’s a dozen ways to get the point across that a solution will require some thought and planning, but I found that when I was forced to use something other than this two-word quip, I had to work harder on my response to really explain the dependencies for a solution.  And the non-technical folks around you are ok with that.  Sure, they don’t want you talking above their head, but they also need to know why things need to be done a certain way.

Some folks might call this leadership.  Others, sticking your neck out. Still others might call this being unnecessarily risky.  I call it doing your job.  Like I said, companies pay us to know our field, it’s time we act like it.  Data is our world, very few people live it in and understand it the way we do, so own that knowledge and champion it.  And stop hiding behind that phrase, “It depends”.

(This month’s T-SQL Tuesday, a grand tradition started by Adam Machanic, is being hosted by Michael J. Swart(@MJSwart).  Great topic choice, sir!)

2013 in review, 2014 in anticipation

As is my custom, I want to blog about what I did last year and my goals for the upcoming year.  Since I have more “regular” stuff to blog about, I figured I’d sneak this in on a Friday just to get it up here.  :)  The primary reason I do this is that which gets measured, gets done (hat tip Buck Woody).  2013 was a pretty eventful year, but I didn’t quite get everything I had wanted to.  So let’s look back at…

2013

Speaking – Did pretty well here.  I met all my goals as well as actually speaking at the 2013 Summit.  I love presenting and now it’s a matter of building new presentations.

Blogging  – Not quite an epic fail, but this one was not a passing grade.  I basically blogged regularly through to about March, then fell back to my sporadic pace.  I didn’t even blog for about 3 months over the summer.  I’m very disappointed with myself and can do better here.

Certification – This was a success and was a lot easier than I had anticipated.  I sat down to take four of the five exams cold to evaluate where I stood and ended up passing them.  The one I had to study for (and I knew this going in) was the Data Warehousing exam (70-463).  Pretty happy here, but now it’s a matter of finding other options for certification.

I know a lot of folks have a dim view of certs.  I agree with the premise, that the exams and certifications (mostly) are no substitute for real world experience.  The fact that they can be crammed for removes some of the validity.  But at the same time, I think that they can be a valuable barometer for someone’s knowledge.  I fall in Glenn Berry’s camp here, that certifications are like extra credit.  If I see a cert on a resume, I won’t assume knowledge of the subject matter, but it at least shows me the candidate was willing to make an extra effort to improve themselves.

Secret Project – Ok, this more or less flopped.  Basically, I wanted to either write a book or build a pre-con for database monitoring because I feel there’s a real gap out there.  These are still on my slate of things I want to do, but I did not get that done in 2013.  Boo me.

And that was 2013.  I’d give myself a B for the year, mostly because while I whiffed on some of my goals, I also managed to go beyond on a few things.  In addition, I’ve made some career choices and moved things in that direction.  Which now brings me to….

2014

Several of the goals will be maintenance or the same.  I want to maintain on the presenting, so we’re looking at at least 4 SQL Saturdays and a Summit submission.  Blogging needs to be once a week.  This is a real stretch goal, because it’s harder than it looks, but I need to strive for it.  These two items are the base foundation my career grows from, so I need to keep that foundation healthy.

New stuff for 2014 will be:

  • I’m trying to move my career more towards being a data architect.  So for that goal, I will write more posts on general data concepts and higher level planning.  There will still be plenty of administrative stuff, but I need to broaden my blogging scope.

  • I also need to start reading more on cloud computing, modelling, and larger design concepts.  Right now I’m reading Domain Driven Design and my goal is to read 1 book a month on a related topic.

  • I will identify and start working towards a new certification path for design and architecture.  Not sure what this is, but I’ll have something identified by the end of March and start working on it the rest of the year.

2013 was a year of change in my life.  Not earth shattering change, not seismic shifts, but a definite redirection in my aims.  2014 will be solidifying my plan and starting down that path.  My biggest challenge will be sorting out the things that are new and uncomfortable from those that are the wrong direction.  The question I will continue to ask is “Does this move me in the direction I want to go?”.

 

T-SQL Tuesday #41: The Hook #tsql2sday

Bob Pusateri(@SQLBob) is this month’s host for T-SQL Tuesday with a topic I definitely can relate to.  Bob asks bloggers to talk on their presenting experiences:  how they got introduced to it and why do they keep doing it.  Since I’m right on the heels of giving my Server Core talk at SQL Saturday 197, it’s perfect timing.

To put my presentation experiences in context, let’s first talk a bit about some of my performance philosophy.  I’ve written about my musical background before and how it relates to giving technical talks.  One of my chief theories of performance (and art, for that matter) is the requirement of an audience, that art is not really art until you have an audience to appreciate it.  It’s all well and good for me to practice and play by myself, honing my skills and rehearsing pieces, but none of this becomes music until there are people to listen to it and hear my message.  Art is about communicating with that audience, sharing something of yourself through your performance.

This is a philosophy that directly translates to the presentations we give in the SQL community.  The main driver is for us to share our technical knowledge with our peers, to create and education conversation with those who do what we do.  For many, it’s intimidating to present when you think you have nothing to share.  When we realize that we can teach our audience something new, it’s an epiphany of what our impact can really be. This was exactly the “hook” that got me into presenting.

It was March 2011.  I had recently read Brent Ozar’s (@BrentO) landmark post: Rockstars, Normal People, and You.  I wasn’t sure about presenting, but I’d figure I’d give it a bash, so I reached out to the Denver User Group to see if I could sneak in for a slot.  After initially being told that my first chance would probably be something in the summer, I got a call from the VP of Events to see if I could give a short talk for the March meeting.  Apparently, the regularly scheduled speaker had to cancel and the group needed someone to fill in on short notice.

I had about two weeks.  In retrospect, that is a TON of time, but as a new speaker I felt like I was cramming last minute for an exam.  I put together a short presentation on database security, built around this cool extended stored procedure I found: xp_logininfo.  The night of the meeting came along and I went to the podium to warm up the room for Doug Lane(@thedouglane) with my “dinky, little presentation” .  The 30 minutes flew by, I think partly because of my nerves and I talked quickly, but everything went fine.  My demos worked, no one laughed at me, and my biggest sin was not speaking up so the back of the room could hear me.

Then came the “hook”.  As I was packing up for the evening, Tom Norman(@ArmorDBA) came over to talk with me.  Tom’s been a regular at the user group for a while who has given his own share of presentations.  To this day, I remember what he said:

“I’ve been a DBA for over twenty years.  You taught me something new tonight.”

Needless to say I was flattered, but it took a couple days to sink in.  When it did, it hit me: these were people that benefited from my performance, an audience that enjoyed my performance.  I was able to take my technical knowledge and mold it into something more.  Two years later and I’m a regular speaker in the mountain west area as well as VP of Events for the Denver group.  I’ve had the opportunity to speak at SQL Rally and many other SQL Pass events.  Presenting has been so much fun and it’s opened countless doors and started numerous friendships.

I want to thank Bob for giving speakers a chance to share their experiences.  My biggest hope is that we can encourage those who haven’t started speaking to do so.  If you’re reading these T-SQL Tuesday posts and you haven’t given a talk yet, go talk to your user group right now.  The SQL community is always looking for speakers and, whether you believe it or not, you have something I want you to teach me.

Speaking Out

Every January, many talk about what they want to accomplish in the New Year.  Goal, resolutions, attempts to improve both personally and professionally.  Within the community, a lot of my friends have set goals for public speaking, aiming to talk at user group meetings, presenting to their peers at their jobs, or larger aspirations.

Time and again, we hear the refrain about how presenting can boost your career.  I know I’ve spoken about it myself on a number of occasions.  The problem for most is their first presentation and how daunting it can be.  Sometimes someone’s not sure where they could first chance to speak.  Other times it’s a question of finding the “right” topic to speak on.  Not surprisingly, I’ve had a number of conversations in the past months with community members who are grappling with these issues.  The desire is there, but they need a little guidance in order to start down the path.

Finding the audience

I think the issue of finding a venue is the easier problem to handle.  Over the past two years I’ve become more involved with the Professional Association for SQL Server and I’ve gotten to know many of the local and regional organizers.  Recently, I’m became one of those people as well, joining the board of the Denver SQL Server group this past January.  Over this time, I’ve learned that your local user groups are always looking for speakers and typically have several different ways to help new speakers get started.

For example, we have three established groups here in Colorado, with fourth one getting started.  The three established groups all provide the same general format for speaking slots:

  • A 30 minute “lead off” slot, where the meeting will usually have someone speaking on an introductory topic
  • A 60 minute “main event” slot, typically featuring a local or national name on a more in-depth topic.

When I started my own presentation path, I got my feet wet with the 30 minute intro slot.  60 minutes is a bit much to take in for a first presentation, both for assembling material and also for the intimidation of talking for a full hour.  Also, when it’s the first of two presentations in the evening, it takes some of the pressure off because there will be someone else speaking after you.

I also know that many local groups are looking at other options with their formats in order to promote new speakers.  With the success of lightening talks at the Summit, many user groups have been talking about implementing that format within their own meetings as a way to give new speakers an even easier way to get started.  For those unfamiliar with the format, several short presentations (8-10 minutes each) are lined up next to each other.  Topics are fairly limited, as there’s only so much material you can cover.  In Denver, we’re planning on using this format to open our March meeting and having only new speakers

Speaking….in the Cloud?

Unfortunately, local user groups only meet once a month and aren’t always convenient for everyone.  The good news is there are other speaking opportunities outside of these meetings for new presenters to make use of, found in the PASS Virtual Chapters.  There are many of these groups built around various areas of interest within SQL Server and they’re always looking for speakers.  The great thing about these meetings is that they’re held online, so that many of the scheduling and possible travelling difficulties are avoided.

I personally had the opportunity to present to two virtual chapters last year and they were great experiences.  It took a little while to get used to the limited audience interaction, but it also meant that I was a little more control of the flow of things.  For new presenters who may be intimidated by the audience, this is a great in between step.  Also, you’ll have a meeting moderator who can assist you getting things going, which helps expand the comfort zone because you basically have someone backing you up.

We always talk about the Cloud and how it will change our careers.  This is yet another way that it’s impacting us.  Through virtual chapters, we have even more opportunities to present and reach a larger audience.  Certainly, we hear every day how many of the top consultants are reaching out to the community through free training and it’s easy to observe the success they’re having.  There’s no reason new speakers can’t have the same success with these very same tools.

Yeah, I’m Region Wide

If you’re involved the community, it’s hard at this point to have not heard about SQL Saturday.  I love these events and I’ve been very pleased to see the explosion in the number of SQL Saturdays over the past year.  One of the reasons these events were started was to grow the SQL Server speaker base and, by necessity of the sheer number of these mini-conferences, they are continually in need of new speakers.

While it may be a little intimidating to start speaking at one of these events, the benefits are amazing.  Even if you have had a chance to speak once or twice already, it can’t be understated how important it is to speak at one of these, even if you have to drive a couple hours or plan a quick weekend getaway.  It’s not just about the opportunity to speak, but also to network.  While attendees get a chance to meet local SQL Server professionals, speakers have a chance to talk with regional and national speakers that are also in town for the event.  For example, if you were speaking at SQL Saturday Albuquerque, you’d have a chance to chat with Aaron Bertrand, Steve Jones, and Denny Cherry.

Keeping it in house

Lastly, the easiest place to present could be no further than your workplace.  Presenting within your company has several advantages, the biggest being that you are probably already familiar with your audience.  Also, you can probably have an easier time scheduling your presentation, which becomes more convenient for you.  Overall, presenting to your co-workers provides you a more comfortable experience, which might be an easier first step if you’re not sure about getting up in front of a bunch of strangers.

The Longest Talk

Whether you speak at a user group meeting, online, or to your team at work, you have plenty of options for a venue.  “I don’t know where I could speak” is not an excuse that’s available to any SQL professional.  I used this excuse for a while, but then when I spoke with my local speaker wrangler for the Denver SQL User Group, it committed me.  Suddenly, I had a time and a place where I had to speak and I couldn’t back out.  Well, I could, but what would that say?  We’re in the tech world because we love challenges, we take on new problems, and we push ourselves outside of our comfort zones.  This is just another challenge, so grasp it and help your career go further.

Next week, come back and I’ll provide some additional information on the second hurdle:  How to choose a topic.