Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

To DBA or Not to DBA (DBA Jumpstart)

This post is part of the SQL Community Project started by John Sansom called #DBAJumpStart.
“If you could give a DBA just one piece of advice, what would it be?”
John asked 20 successful and experienced SQL Server professionals this exact question. I share my own thoughts with you below and you can find all our answers together inside DBA JumpStart, a unique collection of inspiring content just for SQL Server DBAs. Be sure to get your free copy of DBA JumpStart.

In my day to day operations I have the opportunity to work with people in various capacities in regards to data.  Sometimes it is in the capacity of a mentor, sometimes in the capacity of a consultant, and sometimes just in the capacity of the dude that fixes the problem.

I enjoy working as a database professional.  There may be times when I want to scream or yell or pull out my teeth and hair.  Then there are times when I just bounce off the walls with joy and pleasure.  Some may call that a manic-depressive disorder.  They just don’t understand the true life of a data professional.

Reminiscing

In becoming a data professional, I took the long route to get where I am.  I made the decision to work with SQL and learn about SQL 17 years ago.  I made the decision to learn about SQL because I viewed it as a really difficult thing to learn.  I wanted that challenge.  Then again, back then I also enjoyed the challenge of learning to configure Cisco routers.

Early on, I passed the Microsoft exams for SQL 6.5.  A couple of years later, I finally landed a job where I got to touch a database.  That was part of my duties with being in one man shops.  I worked in a few of those one man shops for a while where I had to be the exchange admin, domain admin, DBA, and even janitor at one shop.  I don’t miss the days of having to fix the plumbing in between troubleshooting performance issues and checking the router for DoS attacks.

Eventually I got an opportunity with a larger enterprise to be a production DBA.  All I had to do was work with SQL Server all day long.  It was fun designing metrics and monitors to alert on various thresholds while saving the company oodles of money.  I really thought I was learning something cool.  I thought I was doing pretty good too.

Fast forward a little more and a couple of job changes and I found myself living in Las Vegas and getting more involved in the community.  Boy did I learn quickly how little I actually knew about SQL Server.  Sure, there was reading of posts, books and forums before that.  But that just didn’t quite open my eyes like becoming involved.

I soon started applying myself even more so I could learn more about SQL Server and then be able to try and teach those things to the developers where I worked.  I also started working on trying be good enough to be able to teach people at User Group meetings.  Throw in the efforts to answer questions on forums and writing articles – and it was an explosion of learning.

Now I present pretty regularly at User Group meetings.  I travel around the world to present at SQL Saturdays.  I have contributed articles and co-authored a book.  I also had (still have) the sweet opportunity to participate in the Mentoring project hosted by Andy Warren.  I even went so far as to challenge myself and attained the MCM.  Yet, I know that I have really only scratched the tip of the iceberg with SQL Server.  There is so much to learn about SQL Server still.  If I were to compare myself past to present, I would rate my skills in various areas lower now than I probably did back in the day.

Through the years, and more particularly the more recent years, I have observed many teammates and DBAs for clients.  These observations have revealed some good and some bad.  When I notice certain behaviors that need to be changed, I try to use it as a teaching opportunity.

Price of Rice

One thing I find myself doing on a frequent basis is to try and gauge if I might be treating my work as a 9-5 J O B or if I am treating it like a career?  Am I just punching the clock or am I investing in myself and improving my skills?  Am I helping others improve their skills or am I hording the knowledge like an Oracle DBA?

As I observe others, I can’t help to ponder some of those same questions.  For instance, if I encounter a veteran DBA of 10 or so years that can’t perform a transaction log backup, I will wonder if being a DBA is just a J O B for that person.  The way you treat your work duties is often transparent about how much you care for the quality of work you do and is also revealing in how much one values their skills.

Taken that same DBA that can’t perform a log backup, I might start to wonder if their is a time investment outside of work to better their skills.  I might wonder why I have to show that person five or six times how to perform that log backup.  This may sound a tad judgmental, but it is not meant in that way.  Let’s call it an informal assessment to try and figure out how to help that person become more efficient at performing their job duties.

As a data professional, I think it is an important thing to do.  Spend some time on introspection and try to determine just how much of a career the job is.  Find out if it is a career or if it is on the short end of the spectrum that points to it being just a J O B.

As a team lead, I like to give everybody on the team the task of taking 15-30 minutes each day (on the clock) to improve their skill-set in some way.  This is a tactic that does not work in all environments and with all employers – I get that.  But if that 15 minutes a day means that the teammate will be more efficient down the road, it is a good investment.  If that 15 minutes means there will be less time redoing some work, then it is time well spent.

As I mentioned earlier, there is plenty about SQL Server that I still need to learn.  An important component of learning is to invest some time.  It’s a matter of finding a topic and then taking the time to research.  I do my research by reading and then experimenting.  Once I feel comfortable with that research, I will typically write about the topic.  Why?  It helps to solidify or to disprove some of the principles just learned.  It also helps to cement that research into memory.  I also like to do it because it serves as a personal archive that I can refer back to at some future point (I have done that plenty of times).

Another thing I like to do after learning about something different in SQL Server is to present it to a group of people.  That group can be co-workers, a user group, or at a SQL Saturday (as a few examples).  The beauty of presenting on the topic is that it helps me to embed that knowledge a little further.  It also helps me to try and gain an even deeper understanding of the topic to be able to answer questions that may arise. Best of all is that it helps to disseminate knowledge to others.

Recap

For me, being a data professional equates to a career.  I get that for some it is just a J O B – and that is fine.  For some, it may just be a J O B because they have not figured out how to advance it into a meaningful career.  Those people don’t want to just be a clock puncher and want to make something more of their chosen profession.

As a data professional, I suggest the following practices to help turn your profession into a career.

  1. Regular introspection – check in with yourself on occasion to keep yourself headed in the right direction.
  2. Learn something new – Treat this like a cursor. Keep finding something new to learn and act on it.
  3. Give Back and Get Involved – When you learn something new, teach it to somebody or post it on a blog. This helps give back to the community and more people can learn and grow.

These three simple steps can help turn a J O B into a career.  Better yet is that these steps can help to invest in yourself.

 

 

Comments

Leave a comment on the original post [jasonbrimhall.info, opens in a new window]

Loading comments...