Time Management and Stress Relief

April 20th, 2010

I touch upon these topics in Chapter 4 of the book, DBA Survivor, and every now and then I need to remind myself of the fact that a little rest can go a long way. Here is the excerpt:

Stress relief is important to time management as it allows for you to continue operating at a higher level of efficiency. When stress hits it will affect you in a variety of ways, one of which is your lack of focus and subsequent decrease in productivity. Not to mention the fact that you can bite someone’s head off if they approach you without bearing gifts. When you start to sense that you are feeling overwhelmed and that stress is wearing you down it is time to get up out of your cube.

Take a walk at lunch. You’ll be surprised how ten minutes around the block outside can make a big difference in your day. Go sit on a bench somewhere and watch people pass by for a few minutes. I took up jogging a few years back and find it a nice distraction during the day, especially when you have a jogging partner that you enjoy having a conversation with.

No matter what you or anyone else chooses to do to relieve stress you all have one thing in common: you select activities that energize you in some way.

That is the key to relieving stress effectively. Find something that energizes you, something you enjoy doing no matter what your mood. Of course, if you happen to find that your job is what energizes you then you are one of the lucky ones.

Another key to relieve stress is identifying those times when you are stressed and you know to get up and do something that energizes you. This is not going to be the same for each person; you will need to find the things that work for you as well as recognize the symptoms of stress when they occur.

Now, I am often asked this question regarding stress relief and time management: “…but isn’t taking time away from work in fact wasting valuable work time and making it harder to get things done in the time allowed?”

Absolutely not.

Relieving stress will keep you productive; when you are productive you are also efficient; when you are efficient, you are maximizing your time wisely. It really is that simple. Would you rather spend an hour dragging your heels to get through some tasks or spend thirty minutes getting some fresh air and then another thirty getting the tasks done with a clear mind?

When I was coaching basketball I would always stress that if we prepared ourselves mentally, physically, and emotionally then we were going to be tough to beat on any given night. Same thing for when you are at work. If you feel stress coming on and it is draining you in some way, find something to energize yourself and you will be amazed at how much more productive you can become.

I was reminded of this just yesterday while taking a jog. Towards the end I got a little tired and started to walk. Another jogger was slightly ahead of me when I stopped. I walked for a bit and then started running at 1/4 pace (rugby term). I got closer to the other jogger, then started walking again. I started running at half-pace (rugby term) and passed the jogger, then walked again. This back-and-forth continued until I was sprinting at full pace on and off for the last half mile.

Had I just continued jogging then I would have likely completed my route in a certain amount of time. By doing the intervals, with a gradual increase in pace, I completed the route in less time.

Other things in life are the same way. Know when to rest, know when to walk, and know when to run.

MidnightDBA Podcast

April 11th, 2010

My book was mentioned in a recent Midnight DBA podcast. Sean and Jen had Jorge Segarra (blog | twitter) and Denny Cherry (blog | twitter) as guests in their hotel room and the four of them had a brief chat about how there are not very many opportunities in our industry for apprenticeships. I was very fortunate to have a mentor take me under his wing when I was getting started as a DBA, but not everyone is as lucky. I share my story (and a few others) in Chapter One of DBA Survivor.

The idea of an apprenticeship also led to a very interesting comment, and that was: companies want to hire junior DBAs with a wealth of experience. About the only thing ‘junior’ with regards to the job position is the salary, because the job requirements are usually so long that only a mid- to senior level DBA would have all of the necessary skills. So, where does one go to get that experience?

Well, I actually talk about that in chapters 1 and 8 of the book, DBA Survivor. I discuss how you can get yourself prepared to find a job as a DBA and where to find the necessary additional training. Face it, companies are always going to ask for everything under the Sun when they post a job listing for a DBA. You will need to first build up those skills and then keep those skills sharp if you are to position yourself to land that job. My book can help you to understand what steps you need to take in order to make it all happen.

How Many Faces?

April 2nd, 2010

Looks like I had an excerpt from my book published over at CTOEdge.

The excerpt includes my “shards of broken glass comment” with regards to merge replication. The exact context is as follows:

I would rather eat shards of broken glass than implement merge replication, but that’s just me. Some people make a great living eating broken glass at carnivals. You should choose your own path in life.

Yeah, the book *was* fun to write.

Chris Hansen and Code Reviews

March 30th, 2010

About a year ago I blogged on how I thought Chris Hansen would make a great DBA. A few people said they liked that blog post and I loved the idea of getting Chris Hansen involved but he has yet to return my phone calls, emails, or telepathic messages.

Anyway, as I was assembling materials for the book, it occurred to me that Chris would be best suited to handling code reviews for any IT organization on the planet. So I included it in the book, inside of Chapter Four, “A Development Server is a Production Server to a Developer“, and here is the excerpt:

Chris Hansen and Code Reviews

Good code reviews are a necessary evil. They should be performed at regular intervals, perhaps at a project milestone or tollgate. Code reviews are a time for you to explain to your peers your thought process as well as receive feedback on your code and design. The end result is better code, which results in a more stable system, which results in less production support issues. So why are most companies not bothering to do code reviews?

Because everyone dreads code reviews.

Most people are not good at presenting, and on top of not being good they know they are not good and that makes them even worse. Some people could be good, but get nervous when talking in front of a group of their peers. And those that are having their code reviewed feel as if they are being interrogated by Chris Hansen from “To Catch a Predator”. It all adds up to some of the most dreadful assemblies of employees you could ever hope to imagine.

So, we know code reviews are important, right? And we know that everyone dreads them and as a result no one does them anymore, right? Now, I want you to imagine that Chris Hansen is leading the code review and you are the developer currently making your presentation. You get done explaining what you are doing, and Chris starts asking you some questions, such as…

CH: “Do you know how old DTS is? What were you thinking? And you were not going to batch your transactions? Do you know what that will do to your log file?
You: “I swear man, it was just talk, that’s all it was. I wasn’t going to do anything. I came here to tell my DBA that we needed to go our separate ways.”
CH: “Just talk? It’s a lot of talk. I’ve got the transcript right here. You say here ‘I want to cursor through all your rows’. Man, that’s just wrong.
You: “I know, I know. I’m getting help. The other day I bought a book on SQL 2008. And I am willing to do whatever I can to help you guys. Just tell me what you want me to do.”
CH: “Help us?
You: “Yeah, with whatever.”
CH: “There’s the door. Go tell your friends we’re watching. And the next time they hand us deployment instructions that are more complicated than a NASA launch sequence we’re coming after them.

Clearly you don’t want to have things go that far, but there are going to be times when you really want to call a developer out and ask them why they have their head up their ass. Stay calm, no one person knows everything, right? But also put yourself in their shoes. If every piece of code that you just spent weeks putting together was being picked apart you would be defensive, right? So it is natural to see the developer get defensive as well. In fact, it is natural for anyone to be somewhat defensive even if their code is not being picked apart.

Do your best to see this as an opportunity to teach something new. Not everyone wants a lesson, however, and for those people you need to remain calm and try your best to persuade them to see things from a different point of view. Find out their roadblock (why don’t they want to do something new) and help them get around it. Over time people will begin to trust your feedback rather than think you are always on the offensive.

Forewords From Kevin and Buck

March 17th, 2010

When putting together the materials for a book, the author is asked to help supply details for what is called the frontmatter. This is the stuff that appears before the first chapter and includes things such as dedications, acknowledgments, and a foreword. I could not decide between two people, Kevin Kline (blog | twitter) and Buck Woody (blog | twitter) to write a foreword for me so I went the anti-Solomon route and asked to include them both.

I’m not sure I could ever thank them for taking the time to write a foreword for my book. I owe them both a debt of thanks for a lot of help they have given me over the years. Kevin introduced me to my love Operations Manager (we dated for a while and then married four years ago) and Buck once helped me disable a logon trigger using the DAC during a chat session in a LiveMeeting that we were both attending. Having them both agree to write a foreword was easy: I didn’t tell them about each other. But, now with the book out, they are sure to find out I was cheating on them with the other. So, I might as well go public with the info and wanted to share with you what they wrote.

From Kevin:

You hold in your hands a collection of insight and wisdom on the topic of database administration gained through many years of hard-won experience, long nights of study, and direct mentorship under some of the industry’s most talented database professionals and information technology (IT) experts.

Consider the standard university approach to training people in our discipline. Many colleges and universities offer a curriculum in “computer science,” encouraging their alumni with lucrative careers in “software engineering.” Yet, anyone who’s spent much time working with computer technology will tell you that these terms are often misleading. After all, any type of science is predicated upon the Scientific Method: characterize your observations and
experiences, construct a hypothesis, predict a logical deduction, and test the hypothesis and prediction using one or more experiments. Does that sound like what information technologists and computer programmers do? Not just “no,” but “Heck No!” While it is certainly true that some computer technologists experiment (usually in the fields of processor design, networking technology design, security and encryption algorithms, and certain fundamental software technology platforms) this might represent 0.02 percent of the total information technology workforce around the world and frequently requires a doctoral degree.

Going a step further, let’s look at the term “software engineer.” While a full definition of the term “engineer” could fill a couple of paragraphs, the connation of the word implies the application of knowledge in science and mathematics to solve a problem with predictable results whose operation and outcome can be reliably forecast. Engineers take their profession seriously and rest their credibility on producing designs that perform as expected without causing unintended harm to the public at large. Does that sound a lot like what you do? Does that sound like the jobs of anyone you know who work with IT?

It doesn’t sound like any IT professionals I know. While the IT profession has made many strides over the years and has greatly improved their ability to produce predictable results and reduce unintended consequences, we’re still subjected to daily hot fixes, software patches, and countless interruptions that disqualify computer programming and IT from consideration as both a science and an engineering discipline.

Instead, I offer an alternative interpretation of our chosen career path. When we look at the scope of human undertaking, we can see many careers and disciplines that closely mimic our experiences as IT professionals (or IT professional wannabees). But the closest matches aren’t in the computer field, they’re in the creative arts. Don’t believe me? Consider this comparison. Engineers and scientists need to completely and deeply understand the minutia of their discipline. A good friend of mine is literally a rocket scientist working for NASA and possesses an encyclopedic knowledge of metrology (used in the rocketry structures) and chemistry (used in the rocket fuels). That’s not what we need. When was the last time you talked to a database administrator (DBA) who had exhaustive knowledge of the hashing algorithms used to buffer data into and out of the system RAM of their chosen database platform? Instead, we need to know computational algorithms about as much as a sculptor needs to know the molecular crystalline structure of marble and quartz or a musician needs to understand the science of acoustic resonance. When was the last time a musician sat you down to discuss the effect of humidity and altitude upon their next performance? (Perhaps not ironically, many IT professionals are also part-time musicians.)

Musicians need to know a heck of a lot more than acoustics, and sculptors need to know a lot more than geology. The people in the creative arts are makers, and by choosing the path of DBA, you’ll be one too. One extremely important lesson we can take from makers is that they learn best in two ways. First, makers learn by constant practice and hands-on tinkering. You will need to do this too to become truly good at database administration. When you conjure an image of an “inventor,” you probably envision a guy with messy hair, a white lab coat, and a harried-looking laboratory. Guess what? All good DBAs I know do indeed have a lab, usually called the dev environment. That’s where they regularly tinker and experiment and test.

My second and most important comparison to other makers is that they need at least one good mentor to launch their career. Every maker’s education includes years of lessons at the feet of others who were more advanced than them, whether they are artist, musician, or yes, DBA. That’s where this book comes into play. You might not have a senior DBA to lean on for advice and inspiration, but you have one in this book. Many of the fundamental lessons for a new database administrator, as a review of this book’s table of contents quickly reveals, are about how you interact with other people in your enterprise’s IT environment. Yes, it’s very important to know the technology, and you’ll learn a great deal about technology by reading this book and applying its lessons. However, you’ll also learn about the relationships between DBAs and software developers and corporate managers—areas where you must be guarded and areas where you must be hardnosed.

Of course, no single book can ever teach you everything you need to know about a discipline as broad and far-reaching as database administration for Microsoft SQL Server. So Tom has taken pains to show you the first steps. He gives sources for additional learning, ways of finding a mentor, and—when the time comes—a means of you becoming a mentor yourself. I exhort you to make the most of this fine book and, when you’re ready, take the lessons you’ve learned and give them back to the SQL Server community.

Kevin Kline
Technical Strategy Manager, Quest Software
Founding board member of PASS, the Professional Association for SQL Server

And this is what Buck wrote:

In very “real” language, you hold a book in your hands that will help you understand the day-today life of the Database Administrator. From how you become a database administrator, to backups and recover, and, of course, the joys of bacon—it’s all here. (OK, a word about that last sentence. Thomas likes bacon. A lot. In fact, he believes that just about anything is better with bacon, so it follows that you’ll get a mention or two on it in any book he writes.)

Other than the bacon information, Thomas lays out his real world experience with database systems. You’ll learn how to work in a development team, and not to fear outsourcing. You’ll find out how to maintain a production system, and how to monitor the systems under control. Thomas even explains how to leverage the SQL Server community to help you, and how you can help them back.

So if you’ve got an evening or two to kill, and you’re thinking about becoming a DBA, welcome aboard. You’re in for a treat.

Buck Woody
Senior Technology Specialist, Microsoft

And with that, it is very clear to me that Kevin loves me more than Buck.

It’s Here!

March 15th, 2010

The book arrived today. Rather than write about the experience I decided to capture it on video this time.

If you are interested in doing a review of the book, please fill out the contact form. I will try to get you a free copy shipped out in exchange for your writing a review.

We Have a Winner!

March 5th, 2010

We have a winner in the “Name That Caption” contest, and the winner is…

Jordan Bullock with “This mural IS pretty life-like, but I still miss working above ground.”

Jordan, drop me an email with your snail mail address and I will have a book shipped to you just as soon as they get shipped to me.

Thanks to everyone who participated in the contest.

Book Reviewers Wanted!

March 1st, 2010

My publisher, Apress, has asked me if I know of anyone that is interested in doing a review of my upcoming book. They will mail you a copy of the book, yours to keep, in exchange for you writing a review.

So, anyone interested in getting a free copy of my book? If so, fill out the contact form, including your mailing address, and I will get your info over to Apress. Once the book is printed you should be receiving a copy.

Voting is Complete

February 28th, 2010

OK, the community has spoken, and these are the three finalists:

“I finally found a view in this company that I don’t have to maintain…”-BrentO
“This mural IS pretty life-like, but I still miss working above ground.” -Jordan Bullock
“Ok, who put the datacenter up here on the 35th floor??” -Troy Gallant

I am going to pick one of these as a winner, once I figure out how and where to display the quote on the website.

Thanks to everyone who participated.

Voting Begins!

February 15th, 2010

Voting for the “Name That Caption” contest has begun. You can select as many as you would like, but only the top three will advance to the final round. Thanks for your participation.