Things You Know Now

I was recently tagged by Chris Shaw, in his blog post Things You Know Now, with the thread started by Michelle Ufford (aka the SQLFool), in her blog post also entitled Things You Know Now.  In the original thread, Michelle asks "It doesn't have to be DBA skills, but what do you wish you knew when you were starting?"

Of course, I wish I knew the top and bottom value of a lot of stocks years before anyone else did.  That'd make Kevin a very wealthy dude.  It would also make Kevin a person who didn't care about IT at all.  (Gosh - that sounds wonderful!)  But that gets out of the realm of useful advice and into pure day dreaming.  On the other hand, when I think about useful advice that might benefit someone else, I can come up with a couple tidbits.

First, I am now a huge fan of the adage "The perfect is the enemy of the good" meaning that the search for getting everything just oh-so-perfect can prevent us from ever getting something that's a-okay for our needs.  I would now modify this in IT projects to "The new and unproven is the enemy of the old and solid."  I've always known how important education is for an IT professional in general and a database professional in particular.  Because of this, we're many times willing to support or were even an eager champion for a new and unproven technology.  Knowing what I know now, I would have, overall, done a better job of being a DBA and manager if I'd fought "the next best thing" more often in favor of better processes and better business practices that fed and supported the overall actions of the companies I worked in. Here's an example - when I was lead DBA in a previous job, we were talking into developing a huge knowledge management and collaboration system using the latest and greatest technologies in the Microsoft stack.  I knew that a reasonably effective solution could be built on top of the SQL Server relational engine, but I was lured by the glittering new technology and luster of the "new and improved".  Fast forward two years and, after millions of dollars in development costs plus more than one tarnished career, Microsoft decides that the core technologies of our project are going to be abandoned.  In retrospect, I should've stuck to my guns that a finished "good enough" solution is always, always, always better than an unfinishable "perfect solution".  A smooth running family sedan is much better than a hot rod that never gets out of the garage.

Second, job security is only ensured through success on the job, not through popularity, relationships with the boss, mad skills, knowledge or any other measurement.  Because of this, it's critical to understand what it is about the job that measures your success.  For many DBAs, keeping the SQL Server systems running smoothly and remedying/recovering from problems is "success".  I know of several extremely talented individuals who have written books and have had MVP status, but couldn't keep a job for long because they didn't focus being successful in their day-to-day job. 

Finally, plagiarise code freely.  Build a network of friends who don't mind sharing their hard work, such as good scripts and homegrown documentation, and then reciprocate in kind.  I developed a lot of code, techniques, and processes over the years that I probably could've gotten from others.  In this way, I could've leveraged the smarts of others to help me get more done during the working day, so that I could've spent more time at home with the family.

Well, those are my "Things I know now that I wish I knew then".  I'd love to hear your comments!

Best regards,

-Kevin