Skip to content

Happy Labor Day 2014

Happy Labor Day to everyone. It’s a holiday in the US, so a break from labor for many of us, but those of you outside the US are probably hard at work, so I hope you have a very productive, stress-free day.

Labor Day was conceived as a workingman’s holiday, and should celebrate the efforts of workers at their crafts. It was an attempt to heal relations between railroad workers and companies in the wake of the Pullman Strike, but has also come to mark the end of summer and beginning of school for many in the US, though many educational institutions have already started the new year in August.

With that in mind, I’d like you to stop and think for a minute about the things you build or work on. Think of something that you are proud of having worked on. I hope that you have a few fond memories of work that has gone well in your career.

I’ve built lots of software, and there are quite a few systems I’m proud of. I worked to rewrite an inventory application for an import business, a data center management application for one large company, and even a few reports that I thought were very useful and valuable to my employers. I didn’t build most of the software running this site, but I do think that SQLServerCentral as a total entity is the thing I’m most proud of. I’m not sure if my fellow founders, Andy Warren and Brian Knight, feel the same way, but I’m quite pleased that I’ve been able to help many SQL Server professionals get better at their jobs.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.

DevConnections 2014

I live on a small ranch in Colorado. It’s a working ranch where we board horses, and my wife trains both horses and people. There’s a lot of work to be done at the ranch, and both me and the kids help out.


We have a variety of tools we use to deal with the various chores and infrastructure we have to manage. Depending on the task, we might choose a specific tool.


We also like to use the right sized tool for the job, especially when the job involves heavy lifting.


I often think about my career in technology, and how similar it can be to my life now. I’ve often worked with a variety of technologies, from networking routers, to Active Directory to Exchange in my career as a DBA. I’ve had to understand development languages and techniques to collaborate effectively with developers. Knowing a little bit about a lot of things has helped me often.

That’s one of the reasons I like the DevConnections conference. With so many different technologies being discussed a the same event, I can walk from a SQL Server session on execution plans to a development talk on Fiddler. You can learn about testing software and SharePoint queries along with Trace Flags without leaving the building.

Most of us work with a variety of technologies, and if we don’t, we often do work with a variety of IT pros. Learning a bit more about how others do their jobs, how their technologies might interact with yours, or even picking up a little jargon, can help you to be a better IT worker overall.

I’ll be in Las Vegas this September for DevConnections and I hope you’ll join me. It’s a good time at the Aria resort with plenty of ways to relax in the evening after a packed, educational schedule each day. And if you’re interested in Continuous Integration for Databases or High Performance Encryption, stop by one of my sessions.

I hope to see you Sept 15-19 in Las Vegas. Register today!

If you’d like to see a video promo, click below and enjoy.


I read this sentence recently, and it really caught my eye, mostly because I’ve rarely seen hooks being built into the software systems that I’ve written, or that have been deployed to my production systems.

“A quick chat with your Operations team should convince you of the necessity to log every error condition to a single wellknown location, with the appropriate severity, so that they [the Operations team] know exactly what the problem is.”

It seems obvious, but so few people I know have taken advantage of this. Far too many software products build their own logs and display errors on screens rather than alerting operations departments. So few people have taken advantage of RAISERROR to write to Windows logs, or the custom SQL Server performance counters to disclose information to operations systems or personnel.

That’s my experience, but I wanted to ask you this week how you’ve handled things. Do you have software installed that does this? Is it a part of your development process to include hooks?

Do you hook your logging into operations systems to alert others?

As I think about it, I can’t imagine not doing this now. After all, I like to sleep. I don’t need calls at 2am from Production operator trying to find a log and debug a problem. I’d rather ensure that I log information to well known places and ensure exceptions will catch the eye of operations people. I want to give them as much information as I can in order to help them solve the problem. I’d rather sleep and depend on the on-call staff then be woken up because they rely on me to solve problems.

Personally I think that logging to the Event logs, or including configuration switches to send alerts to other software ought to be part of the best practice of developing software. It’s a maturity point where we recognize that we’re building interconnected systems, not individual bits of software that live like hermits.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at

The Time Machine: Four Things I’ll Tell Steve Jones

I was tagged by Mike Walsh recently in a blog post he wrote about 4 Attitudes he wished he’d had earlier in his career. It’s always interesting to look back at the past and think about how things might have been different. It can also be instructive for others to see what you’ve learned and would do differently. That can certainly shortcut someone else’s journey to be a better professional.

If I look back at my career, I’ve learned lots of lessons. Some I learned early on, some later, and some I’m probably still learning. I’ve had a lot of success, but there are a few things that I’d go back and tell the 24 year old Steve Jones to remember.

Technology is not religion

To start this off, I’ll look back at something that I’ve argued far too often about early in my career. Is Windows better than Linux? Should we choose Java over .NET? SQL Server v Oracle?

It’s fine to debate the merits, but there are many ways to solve problems, and many of them work well. There’s no need to take hard lines for or against any technology. If it works, use it. If you get the chance to learn it, learn it.

Fortunately I learned this fairly early in my career.

There is no Plan

I used to think that successful businesses had things figured out while those that struggled just made mistake after mistake doing things they should know better than to do.

Having owned my own business, having worked in large and small companies, often in close proximity with upper management, I’ve learned there isn’t much further from the truth.

So many business decisions are guesses. They’re gambles. They’re hedged bets; sometimes well hedged, sometimes not at all. Often business people use their experience, but in a world that changes rapidly and in strange ways, no one has all the answers. I used a capital P on Plan because The Business Plan is just a direction to start moving. Things can, and will, change.

How many enhancements in the SQL Server platform have worked out well? How many haven’t? There are examples of each, and while it’s easy to second guess the directions a business takes, I wouldn’t bet that I’d do something better, and perhaps not even different.

I bring this up because I’ve had so much angst and anguish about decisions made by the business. I’ve argued hard for certain directions and choices, and when I haven’t had things go my way, I’ve held onto resentment or concern for far too long. I have far too often ignored my own management advice when I was an employee.

We should argue for more space, or a DR plan, or an upgrade. Argue passionately. However when the decision is made, in line with your position, against it, or even at a wide diagonal, go with it. Support the decision and do the best you can to make it work.

Take a Breath

Crisis situations are stressful. It doesn’t matter if it’s a disaster from a hardware failure, or a software rollout that doesn’t go well. People get emotional (upset, angry, fearful) and may say or do things that they might not do otherwise. Management doesn’t help and I’ve had no shortage of CEOs, CIOs, CFOs, and assorted VPs and directors that haven’t helped the situation.

When you are trying to decide something, take a breath.

When you’re trying to determine the cause of an issue, take a breath.

When you’re about to implement a fix, take a breath.

When you get an error message from whatever thing you last did that was supposed to fix the problem, take a breath.

When you think things are fixed and are ready to inform someone, take a breath.

Basically take a breath before you rush into anything. No matter what the pressure you feel or the confidence you have, stop and double check your work. I do woodworking and there’s a saying many of you may have heard.

Measure twice, cut once.

Take a minute and be sure that you are doing the right thing. Stop and read error messages and read your code again. Think about the ramifications of changing that setting. Ensure that you really do want to click that particular button or press those keys. Most of all, be sure things work before you tell anyone.

I’m still learning this one, both in technology and woodworking. I won’t lie, this is a hard one, but I  rarely regret following this advice.

We’re Not Saving Babies

This is an expression of my wife’s, but I really learned it at a large company. Around the time of the SQL Server Slammer worm, there were a lot of virus outbreaks of various flavors. I was a part of the response group as the senior SQL Server DBA.

One day a virus hit that shut down our email system. That meant that not only were employees effected, but systems couldn’t alert operators and for a billion dollar company with many thousands of employees, this was a big deal.

Our incident group was convened and gathered together in the Operations area near my cube. Over a dozen of us were looking at systems and discussing the issue. We narrowed it down quickly to a particular virus, but to clean system required a good deal of scripting and manual work to deploy to thousands of Windows hosts. One of my good friends was a senior person in his area and when we narrowed down the work and realized that 4 or 5 of us could do it, it told the manager in charge he was leaving. His child had a sports event, and the rest of us would be fine.

The manager wasn’t happy, but he realized that only a few of us could script well enough to set things up for the rest to deploy and monitor. I stayed late getting things working, but I’ve never forgotten that lesson.

Most of us aren’t making life altering impacts with our work. My apologies to those of you that work on computer systems that do impact the life of death of a human. Our companies might make a little more or less based on our work, but plenty of people make mistakes all the time that cost revenue or lose sales. Almost none of our efforts are that important, contrary to the managers that lose perspective on a daily basis.

Learn to keep things in perspective and don’t kill yourself over work that can be done tomorrow. Hint: that’s most of the work.

Note, this isn’t an excuse to slack off. If you’re behind on work because you haven’t been doing it, then you might need to put in a few more hours.

Be your own person

I once got called about an interview with a company in the mountains of Colorado. It was a neat job, in an interesting business. They needed a production DBA, and I didn’t like my current job. We chatted and they told me I’d “get to manage a 13TB database.”

This was on SQL Server 6.5,

I ended the interview (politely) then, saying I wasn’t interested in the job. I had a small child and an infant. I was already spent a few nights sleeping in my office. I already had a blanket and a pillow in my desk. I didn’t want to move those things to another office.

I’ve learned over the years that there are things I like and things I don’t. I continue to learn about myself, the things I like and don’t like. Most of all, I continue to learn to be honest with myself about how I really feel about the things that are a part of my career.

I’ve watched friends stick with employers and even career fields or positions because of money, commute, prestige, and more. I’ve seen people spend far too much time working in positions that they hated every single day.

Life is short. If you don’t like administering servers, change to another career. If you struggle to sit in front of a computer and write code, find something else to do.

Change is hard and it can take time. I certainly don’t advocate quitting your job tomorrow, but I’d highly recommend that you make a 2, 3, 5, even 10 year plan to move into a career that you enjoy, or at least, don’t hate.


There is much more I could write. More advice I’d give myself, but I will say that despite the setback and stutters in my career. Despite the decisions I have regretted, I’m not sure I’d change much. I’ve had a great career, and a great life, and while I’d ask myself to think more about my decisions, I’m comfortable with where they have led me.

I hope many of you can do the same.


I’m not tagging anyone. If you want to write, write. If you don’t, that’s fine. Either way, think about where you’ve been, and if you read any advice that catches your eye, think about taking it.

I did my part – Helping others

Let’s raise some money, people.

TL;DR Donate to Doctors Without Borders, the Argenis Without Borders campaign.

What started out as a joke has grown, and we’re really looking to raise some money for this charity. I did my part

Photo Aug 28, 11 21 01 AM

I started shopping, and I’ll be rainbow decked for the PASS Summit, and maybe a few other events. It’s all in good fun and to raise awareness and funds. Doctors Without Borders is a highly rated charity, and a great cause. If you feel the need, please donate to the Argenis Without Borders campaign.

Reverse Engineering Disasters

If you are responsible for managing systems, you should have some sort of disaster recovery plan. Even if you are only managing the one system you carry with you on a regular basis, you should ask the question: What would it take to destroy this data?

It’s a good question, and in the post I’ve linked above, a technologist talks about some of the failings of disaster recovery plans because they forward engineer plans to recover systems. People think of specific problems and try to prevent them. They don’t reverse engineer to find out what events would cause them to lose their system.

That’s really the key to a lot of design and architecture in computer science. You can’t think about just what you expect to happen, or even what you want to happen. You have to consider the other ways in which events could occur or the issues that could cause an problem in your system. In development, the things you expect are considered to be the happy path. A good architect or engineer will think about everything else in addition to the happy path.

I sometimes think that far too many decisions are made while considering the happy path, but ignoring or discounting the other paths available. These other paths may be unlikely to occur, but having worked with computer for over 25 years, I can tell you that I often find the least likely events occurring far too frequently.

As the author says, you should never say “I never even thought of that happening.” Consider reverse engineering problematic situations and then make a judgment of how likely is it that any of the events will occur. That way you have at some idea of what could go wrong and what events you are willing to protect against.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at

Better Presentations–Hide those Windows

This is part of a series of tips for speakers to make your presentations better.

I wanted to give some specific SQL Server presentation items that have bothered me recently. These aren’t big things, but they do cause problems for attendees, and that might mean the difference between someone learning what you are presenting and getting lost because they can’t easily see.


How does this look?


It’s bad. Imagine if you were 15 feet back from the presenter, which is how this looks on a screen. I can barely see code.

If you look at the Object Explorer, there’s this little item in there .I’ve highlighted it below.


There’s also one on the Properties window.


In fact, my SQL Test window at the bottom, most SSMS add ins and  Visual Studio windows have them.

Click them. They’ll hide the windows, like so.


This is a much cleaner view of things.

But, Steve, you’ll say. I need those windows. I get it, I need them, too. They’re on the side of your screen and you can pop them open. They’ll stay open when you work in them, and disappear when you don’t.

Gone when I don’t need it.


Here when I do:


It’s a quick tip, and it’s easy to learn. Once you practice with hiding and using windows, I’m sure you’ll find that you work more efficiently all the time, not just when on stage.

Smooth Database Deployment at SQL in the City 2014

One of the themes at Red Gate Software this year has been “ship often, ship safe”. Actually, that’s been a theme (and goal) for us the last few years as we’ve learned how to build software faster, maintain quality, and get features into the hands of our customers. We’ve been working hard on expanding our knowledge , both through tools and education, to help our customers deliver their database software in a better way.

Grant and I have traveled around the US giving free seminars on database development, deployment, and delivery, with ideas on how you can more easily manage your software pipeline. This fall, we’ve revamped our talks and added a new one on testing, and we’ll be delivering these talks at our 2014 SQL in the City events. We’ll be in London on Oct 24, 2014 and Seattle on Mon, Nov 3, 2014 talking about software, along with a number of our Friends of Red Gate. These will be full day conferences with a variety of DBA related topics featuring a number of speakers that are experts working with SQL Server. Quite a few of our developers and managers will also be available to share our knowledge about the process of building, testing, and deploying software, particularly database driven software. We’d also love to hear about your challenges and issues you face on a regular basis. If you can come, we’d love to meet you.

Our events are a casual, fun, educational way to learn more about SQL Server. You’ll get ideas and tips for becoming a better developer or DBA that you will want to experiment with and put into place every day to make your job more enjoyable. We hope you join us at one of these events, or at one of our seminars in the future.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at

Making Better Presentations–Tips and Tricks

I give a lot of presentations each year. I am constantly trying to improve my presentation skills to continue to get invitations to speak, to represent my employer well, and to ensure attendees are interested and learn a few things.

With that in mind, I’ve compiled a number of tips that I have learned over the years, or that I’ve seen ruin some interesting presentations.

I’ll be adding to this list over time and linking to the posts as they become visible.

Feel free to try one of them (please), all of them (if appropriate), or none of them (not recommended).

Feedback is welcome.

Testing is Your Best Investment

I signed up for the FlowCon 2014 conference in San Francisco this September. It’s a two day event about software development and how we can do better. My job is starting to encompass more work in this area, and I’m excited to go see some of the ThoughtWorks developers talk about what they do well. Part of the reason I wanted to go came after watching a few videos from last year, including this one from Randy Shoup.

There are some interesting things in the talk, but one thing really caught my eye at the 9:52 mark. Mr. Shoup made a statement that “tests help you go faster” and “the best investment you can make in your own code …[are] tests for your code.” Those statements are a short part of the talk, but they make a lot of sense to me.

It’s easy to ignore testing, after all, it’s hard to test for everything that can possibly happen, and writing tests can be extremely tedious. However building tests JIT, when you find bugs or problems, can give you good code coverage, especially in the areas where you find developers are likely to make mistakes.

And like with all other software development skills, the more you work on writing tests, the easier, and faster you become at building them.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 1.6MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at


Get every new post delivered to your Inbox.

Join 4,636 other followers