You feel excited as you start your new job today! You are ready to roll! This is your dream DBA position!

You go to the office, you start getting initiated on the job, and you start having questions about processes, procedures, rules and so on. After a few days you start working on tickets, and you have even more questions.

• What are the standards when creating a new user in database ABC?
• What do I do if the backup fails on step#2 of the job?
• What is the patching procedure and how do I do it?
• What is application RunNow and what database is supporting it?

Your questions just keep coming.

Does this sound familiar?

When you get your answers from your new team members, I envision two scenarios here.

You become very impressed with this new job, because people are helpful and they point you to a location on the network where all DBA documentation resides.
No matter what question you have, the answer is somewhere documented.

Or

You become very frustrated with this new job, because people are helpful, but they cannot point you to any type of documentation. You kind of feel lost without having anyone around to guide you.

How is this possible?

Documentation makes it possible. Documentation will make your job easier. Documentation will save your butt at 2:00 am when you get paged.

But Documentation doesn’t get created overnight. When you see a site that is well documented, that work took years and months of DBA work. It all started at one point with the first document, and it evolved from there.

When you see a site without documentation, that too is the work of the DBA (or the lack of instead).

Why?

Because there’s the DBA that documents, and there is the one that doesn’t.

The DBA That Does Document

The mindset of the DBA that does document is one of fixing the problem, documenting the process, and sharing with the team.
The DBA that does document always thinks about taking screenshots, capturing statements, log outputs, proof of the work that is being done.
The DBA that does document is focused on finding a solution, and is also focused on not reinventing the wheel. Their mind says “I must document this process, as I don’t want others or myself spend the long hours troubleshooting the same thing.
The DBA that does document is focused on finding patterns, automating things.
The DBA that does document understands the importance of good documentation. Nobody needs to convince them about the importance of documention, they will do it for you as part of the job.
The DBA that does document is AWESOME!

The DBA That Doesn’t Document

The mindset of the DBA that doesn’t document is one of fixing the problem.
The DBA that doesn’t document is not focused on helping others with processes, screenshots, log outputs. If they can fix it, they are happy.
The DBA that doesn’t document is ok to reinvent the wheel. They even forget the same incident happened some times in the past.
The DBA that doesn’t document does not understand the importance of good documentation. No matter what you do to convince them, bribe, threaten, they will not document. And even if they do, the documentation will be mostly useless.

So which group do you belong to? Which group do you want to belong?

Click reply and let me know!