SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Things I Wish I Had Known

I was tagged by Grant Fritchey (aka Scary DBA) in the latest get-to-know-you question.  This one asks, “What do you wish you had known when you started?”  I could go on for hours about the things I wish I hadn’t had to learn the hard way, but here are the highlights.  Apologies to those who were tagged before me if I repeat their points.

It’s OK to make mistakes.  It’s also OK to admit it.
There are two types of people in this world: those who make mistakes and fess up, and those that make mistakes and try to cover it up.  Everyone – everyone – makes mistakes in their jobs, and in life in general.  While there are some high-profile mistakes that are notoriously noteworthy (airline disasters, medical errors), the vast majority of us are permitted, and even expected, to make a few errors here an there.  As long as you can learn from your errors and not continue to make the same mistakes, it can be filed under the “Valuable Lessons Learned” heading.  Further, those whom you work with and for will have more respect for you if you admit your errors up front, especially when you deliver a plan for resolution.

Technical skills are not enough
When I started out, I had my mind set on simply learning a craft, fine-tuning my skills to become one of the best in the field, and keeping my head down and working hard for the next 40 years.  While it is important to grow and learn hard skills, today’s economy is not friendly to the stereotypical technical geek working in a dark basement and slinging code (or monitoring logs, or building desktops, or whatever).  To be successful, you’ve got to break out of your technical world every now and again and interface with nontechnical people.  Spend half a day shadowing one of your end users to see how the systems you build/support help them to do their jobs.  Spend time with senior management and executives to find out what big-picture goals they have, and how you help get the organization there.  Have coffee with someone unfamiliar with technology and learn how you can ease them into the digital age.  Most importantly, get to know the overall goals of your organization/clients/customers – you’ll be far more successful in the long run.

You are responsible for your own career development
Technical careers require constant learning.  Training, college, and conferences/trade shows are great ways to learn and network, but many companies can’t or won’t fork over the cash for these career development events.  The bottom line is, it’s up to you to take charge of your career.  A few thousand dollars for conference fees can be painful, but it could be argued that you’ll easily recoup that investment over the course of your career.  For those who truly are budget strapped, there are tons of free career resources; user group events, online references (even videos!), libraries, and volunteer opportunities are all cost conscious ways to build your network and skillset.

Don’t try to be an expert in everything
There are generalists, and there are specialists; nobody can be an expert in all things technical.  Find something that you enjoy doing (that statement alone should be a bullet point), and become an expert in that thing.  You don’t have to specialize to the point that you’re a niche player, but you can limit your scope such that you can be known as an authority in your chosen area.

Don’t take things too seriously
I almost didn’t type this last one for fear that I would portray myself as having a lackadaisical attitude toward my career; nothing could be further from the truth.  We’re all human (see #1 above) and are limited by a number of factors, including emotions, limited energy, family commitments, and natural abilities.  Don’t be a stickler for absolute perfection; accept that some things are part of live and unchangeable.  When obstacles block your path, don’t freak out or become the voice of negativity; take a breath, smile, and know that, if it was easy, everybody would be doing it and our skills would be far less valuable.  Address problems or deadlines with a sense of urgency, but don’t let your commitments consume you to the point that you spend all of your time working.


Again, I could go on for pages on this topic, but these are the lessons I’ve learned the hard way that stand out in my mind.  Now, to keep this thing rolling, I’m going to tag Jack Corbett, John Magnabosco, and TJayBelt – not sure if TJay reads my blog, I suppose I’ll find out shortly :)

Tim Mitchell

Tim Mitchell is a business intelligence consultant, author, trainer, and Microsoft Data Platform MVP with over thirteen years of data management experience. He is the founder and principal of Tyleris Data Solutions.

Tim has spoken at international and local events including the SQL PASS Summit, SQLBits, SQL Connections, along with dozens of tech fests, code camps, and SQL Saturday events. He is coauthor of the book SSIS Design Patterns, and is a contributing author on MVP Deep Dives 2.

You can visit his website and blog at TimMitchell.net or follow him on Twitter at @Tim_Mitchell.


Posted by Steve Jones on 13 February 2009

Nice list, and I agree. I think I have learned a few of these myself over the years.

Posted by Michael COmperchio on 16 February 2009

It's funny, but I was talking with some friends last night about this very thing.... Yout is wasted on the Youts. While, today, I know what you say is right, to have tried to tell me that 25 years ago would have been a waste of breath (or finger energy I guess :) ).

Posted by Pete on 16 February 2009

I would also add:

Don't be afraid to ask for help!

Posted by mindy.riddick on 16 February 2009

Wow. Thank you.

Posted by LALAPAT on 16 February 2009

The best part I like is "Technical skills are not enough". Thats really a good one. Thank you very much for sharing with us.

Posted by LALAPAT on 16 February 2009

Is there any way that I can email this article to a friend ?

Posted by Luis Gerardo on 16 February 2009

Nice contribution...


Posted by Tim Mitchell on 16 February 2009

Sure thing... you can e-mail just the link, or share it on Google reader if you are using it.  Thanks to all for the kind remarks.

Posted by ahmed_hinnawi on 17 February 2009

Sure, theoretically a nice contribution, but (nice but) it depends on the nature of persons (we are not same) - today if you want to be a specialist (not a generalist) 24 hrs a day is not enough to allow you to know every thing about ONE thing, anyway, even the simple persons who are outside the playground, they become victims to that much informations available today.

Posted by princess.lipscomb on 17 February 2009

I always keep a document or journal with those strange situations so that you can easily refer back when someone else is in need.  They have become handy over the years.

Posted by eileenh on 18 February 2009

As humans, nobody can tell us anything until we ask. So, keep thinking of questions to ask and learn from the answers. Remember that the users of our software are the same as we are so help them ask us the kind of questions that are needed to help them understand what we are trying to tell them.

Posted by Anonymous on 18 February 2009

I was recently tagged in a blog entry from Tim Mitchell titled "Things I Wish I Had Known"....

Posted by mustafak on 23 February 2009

great! Especially, whole part of "Don’t take things too seriously"

Posted by Anonymous on 14 March 2009

Today Kevin Kline, Quest's #1 SQL guru, tagged me, challenging me to offer bits of wisdom to SQL n00bs—which

Posted by Anonymous on 15 March 2009

And I remember what she said to me How she swore that it never would end I remember how she held me,

Posted by wilkeyrd on 3 June 2009

Great article, many great gems in here for both new and old

IT types.

Posted by LongtimeDBA on 5 July 2009

The 1st item that you discuss about mistakes needs to be looked at on a case-by-case basis. I recently was in a situation where a number of issues from a number of different areas lead to a longer than expected system maintenance outage. I discussed openly an issue that I had caused ( we wont go into that it was at 2 AM on a Friday night after  already working 70+ hours that week ) and how it happened and what would be done to insure that it wouldnt happen again. The other areas talk around their issues blaming others, acting like their was no problem or lied about there not being a problem and we DBA's must have done something wrong. On Tuesday I was praised by my management team for being honest and the following Wednesday I was shown the door. While I agree that honesty is the best policy and that your integrity in the end is what you will be known for be aware of its consequences given the environment you work in.

Leave a Comment

Please register or log in to leave a comment.