Another breathtaking excerpt from Thomas LaRock’s “DBA Survivor: Become a Rockstar DBA”.

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 stabler system, which results in fewer 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. To make things worse, 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.

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 Server 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.

Another TERRIFIC excerpt from Thomas LaRock’s book “DBA Survivor: Become a Rockstar DBA”. If you haven’t bought this book already, you need to cancel your Internet subscription.

Do you really have anything in common with the President? Yes. More than you probably realize. First, about half of the people around you doubt whether you are qualified to actually hold the job you have been given. Second, every time you make a decision or plot a course of action, you will constantly be criticized, even by your supporters. And third, you are going to be judged by what you accomplish in your first one hundred days, good or bad, even if it is not in your control. Every four years we elect a new President, and the person in office is always subject to approval ratings. You will have your own version of this fact of life; it is called your annual performance review. Come review time, you want your approval ratings to be as high as possible.

“Luck Is What Happens When Preparation Meets Opportunity”. This quote, attributed to Roman philosopher Seneca, reminds us that we make our own luck. The difference between lucky and unlucky people is all in our perspective.

Luck isn’t just about being at the right place at the right time, but also about being open to and ready for new opportunities. As Richard Wiseman’s ten-year study has shown:

Lucky people generate their own good fortune via four basic principles. They are skilled at creating and noticing chance opportunities, make lucky decisions by listening to their intuition, create self-fulfilling prophesies via positive expectations, and adopt a resilient attitude that transforms bad luck into good.

Landing a DBA job out of university I frequently remind myself “Boy am I lucky!!!”. But when I reflect back upon my own experiences, I remember how I attended those postgraduate database classes, how I was like a sponge soaking up everything possible. Over time I would get involved in the database community, read forums, contribute, etc. It got to the point where I visualising myself as a DBA. Fast forward a few months after graduation and along comes the opportunity – a Graduate DBA position.

Sometimes you make your own luck.

Thomas LaRock (absolute legend) presents some harsh truths that any Graduate/Junior DBA must accept if they are to succeed as a Default Blame Acceptor…

First off, let’s get some basics out of the way. You do not know everything. Sorry to tell you, but better to find out now rather than later on. Trust me. No one person knows everything; it is a fact of human existence. You are human, right? Because that simple fact will be questioned periodically, so you better check again just to make certain. Last thing you want is to find out you are actually a Cylon or something worse.

Another thing you need to know about being a DBA is that you will have fewer friends at work than when you started. Now, that is not necessarily a bad thing. See, you have been placed into a position of responsibility, and with this responsibility you will need to make some decisions, and those decisions will not always be popular. Thus, you may lose some friends at work, but these losses will be more than offset by the gains you have in the overall DBA community. So you have that going for you, which is nice.

With that responsibility, you will also find that you start getting more blame than credit for your work. I promise you this: no one will ever stop by your desk in the morning and thank you for the fact that everything ran smoothly last night. But you better believe if a batch load took five minutes longer than expected, you will have four different people asking you “WTF?”

Based on my first three months as a Graduate DBA, these harsh truths are totally accurate. But ask any DBA if they would have it any other way 🙂