I recently started a series on Simple Talk for those who want to be a DBA, and it made me think back to my first weeks on the job and what I would tell me “then”, knowing what I know now.  If you are just getting started as a database administrator, then this is for you as well.

Dear Past Me on my First Day as a DBA,

Congratulations!  You got your first DBA job, and you have the imposter syndrome to prove it!  You got introduced around as the new DBA, and you looked around to see who they were talking about.  You got a ticket to run a script, and it scared you half to death to know you had the permissions to do that and more!  You are reading code that is hundreds or thousands of lines long and looks nothing like what you learned in school - and you are wondering when they will expect you to do that.

What have you done?

It’s a good thing that you like to learn, because that is what you will spend the rest of your career (but particularly the next year) doing.  The first few months are going to hurt.  There isn’t much way around that, because there is nothing simple about what you now do for a living.  You have a lot to learn.  However, the resources to help get you up to speed are all around you – blogs written by experts who have been where you are, websites and social media tags such as Stack Overflow and #SQLHelp to ask questions and get answers, and people in your area who know the challenges and who will help point the way.  Read everything you can.

Start with the people you can trust – the MCMs, the MVPs, and the sites that are solid –SQLServerCentral, SQLSkills, Simple Talk, and Stack Overflow .  You’ll quickly build up an inexhaustible blog roll, and find that the answers to 95% of your questions are to be found in the virtual wiki you just built for yourself.  If you can, go to user group meetings and SQL Saturdays.  They are free (or very inexpensive) and you can learn a lot and meet some great DBAs in the process.

Don’t expect yourself to do it all right the first time – you won’t.  Expect yourself to learn.  Expect to make mistakes, to own your mistakes and to fix them.  Expect to never ask for help without being able to show what you have done to help yourself first.  Google will be your friend.  Plug in the error and you will have more help than you can imagine. Pick the first several links whose descriptions seem to most closely relate to your issue and start reading.

But who do I trust?

Since you have been reading everything you can get your hands on, some names on forums will begin to look familiar.  Over time, you’ll realize you have a mental go-to list.  Query tuning issues?  Look for Erik Darling, Brent Ozar, Kevin Kline.  Security?  Definitely Denny Cherry.  Deadlocks?  Jonathan Kehayias is a good bet.  Query Store?  Erin Stellato.  SQL Server on a SAN?  David Klee bridges the worlds brilliantly.  HA/DR?  Allan Hirt and David Klee.  Replication?  Hilary Cotter.  Isolation levels?  Kendra Little and Bob Pusateri make a potentially confusing topic much easier to understand.  Indexing?  Kimberly Tripp or Kendra.  Window functions?  Kathi Kellenberger.  But don’t let yourself get comfortable!  Keep reading and listening at conferences, or you’ll miss Bert Wagner and Pam Lahoud.  On the other hand, if you are on forums like Stack Overflow looking for answers, look at upvotes and reputation to help guide you.

Observe everything you can, because you won’t always be the newest person on the team.  When someone does something that you see works, learn from it.  When you see something fail, remember that, too.  Take note of the things that would have helped you and made all the difference so that you can do those things and be those things for the next person.

If possible, try to arrange time to see how your databases are utilized by your end users.  See how the application front ends work and are used.  The more you understand about the different layers of the stack, the more you know how your data is used, the better of a help you will be.

As much as you can, try to be the bridge to other teams.  When you see bad coding practices, show how refactoring the code can help – and be ready to explain why it worked.  Hardware will not be your first language, but know that it is okay to ask the “stupid” questions and show that you are willing to try, because you want to work together to make everyone’s job easier.

If you find that someone comes in after you who is brighter and more talented than you are, you are fortunate indeed.  That is the someone to learn from.  That is the someone who will make you a better DBA than you would have been otherwise.  Embrace that opportunity, and be willing to pay it forward if you have the chance.

You are about to learn so much technical stuff that you will feel your brain is swollen sometimes.  Every time you think you know a thing, you will realize that you don’t know it as you should have.  That will be discouraging until you realize that is when the real learning begins – for us all.  You will learn the technical - and you will learn so much more than the technical.  You will learn to trust the knowledge you have, and you will understand your limitations.  You will be proud of your accomplishments while knowing how much you have left to do.   You will see just how true it is that you can never know everything to do with this job, and you will be ready to help those who know less than you do, while looking to those who are ahead of you in the game.  And in teaching others, you will have taught yourself as well.

So, what did you just do?  You did something good.  So breathe, and dive in, though you’re scared half to death.  You’ve got this.  I’m rooting for you.