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.
“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.”
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.”
Senior Technology Specialist, Microsoft
And with that, it is very clear to me that Kevin loves me more than Buck.