I was tagged by Scary DBA and recent MVP awardee Grant Fritchey with the latest viral question:
“So You’re On A Deserted Island With WiFi and you’re still on the clock at work. Okay, so not a very good situational exercise here, but let’s roll with it; we’ll call it a virtual deserted island. Perhaps what I should simply ask is if you had a month without any walk-up work, no projects due, no performance issues that require you to devote time from anything other than a wishlist of items you’ve been wanting to get accomplished at work but keep getting pulled away from I ask this question: what would be the top items that would get your attention?”
Yes, it’s a bit silly, but think about it – a full month to do the stuff you’ve wanted to do all along. No ringing phone. No midnight SPID-killing. No “I accidentally deleted all of our customers, can you drop what you’re doing and fix it?” support tickets. Thirty days to show off how smart you are, or to get even smarter. A month to work on real projects with real value.
With that in mind, the first thing I’d do is to remove any visible signs that I’m on the island, which should keep the rescue craft from easily finding me. This might buy me 2, maybe 3 more months on the island.
Seriously, with that kind of unallocated time, I’d round out my Analysis Services knowledge and learn everything I could – including MDX, data mining, and DMX. I believe business intelligence is the future of SQL Server and of the data profession as a whole. Those who are well-versed in these technologies will bring enormous value to any organization.
With any remaining time I had left, I’d finally get around to writing some tools to make my job easier. I’ve had many moments of pause throughout my SQL Server career when I’d tell myself, “Someday, I’m going to create an application/script/add-in to make this task easier". With my time in isolation, I’d spend the time to streamline those tedious task that take up too many mindless clicks or keystrokes.
Now to keep this rolling, I’m going to tag my friend Jack Corbett, who I’ve “known” online for a couple of years but only met in person last weekend in Pensacola. I’ll also reach out to Ken Simmons, whom I also met at the same SQL Saturday event.
I was tagged by Gail Shaw to post two big mistakes made during my professional career. The only challenge here was to narrow the list down to two :)
The first one is very easy. During my early days working with SQL Server, I wore a lot of hats, including that of web developer. One of my first major web projects was to create a student assessment system, which would allow instructors to create online exams. Students would then be able to use the web interface to take the exams, and the manual paper grading process would be no longer. Now I’m not ashamed to confess that I was underqualified at the time to effectively complete this process; as the sole developer/DBA, the entire project from spec to support rested on my inexperienced shoulders. Nevertheless, I forged on and delivered the application on time, albeit untested. The magic hour was the following morning, when a dozen educators were to begin entering exams on the new application. I should also mention that I was still in college at the time, and was in class – over an hour’s drive away – during the critical go-live.
It probably goes without saying that my phone started ringing shortly after the first staff members arrived. Problems were rampant, and I ended up leaving class to go address the issues. I dodged the angry mob at the front door and managed to get in and take care of the most pressing issues so the test building could commence. In the end, the application was made usable and found a niche where it worked pretty well. However, I can’t help but wonder if this tool wouldn’t have gained more widespread acceptance if I had been more experienced at the time and had done a better job during development and deployment.
Lesson learned: Admit when you’re in over your head, and insist upon a thorough testing cycle.
The second one caused me a good deal of embarrassment and cost me the better part of a day. After receiving a report from an end user that a critical report had not been run on one of our main databases, I got with our hardware guys to arrange for a restore of the database backup file from tape. Since this is a large database, it takes a few hours to copy over, but our backup guru agreed to copy the file directly to the development server to save another copy operation from live to dev. I got the call a few hours later that the copy was complete, but I found only old files on the target directory (and deleted some of them, as part of a periodic manual cleanup). I called our backup guy again and told him something had gone wrong and the file hadn’t been copied. Always a good sport, he kicked off the file restore again. When the call came that the process was again completed, I checked the backup directory and still found only old files, including one I had deleted earlier. I made another call to our backup guy to find out what was wrong with the backup software, and simultaneously opened a window to the live database server backup folder. As I was explaining to our backup engineer that he had made a mistake, I saw the filenames in the backup directory on the live server – which looked curiously like the files I had deleted! The database backups on the live server had a different naming convention than those on the dev side, and I had recklessly deleted the restored file the first time. A quick RESTORE HEADERONLY confirmed that I had just wasted a good part of my day, as well as that of one of our best hardware guys.
Lesson learned: Before you assume someone/something else is at fault, make sure you’re not doing something silly to cause the problem in the first place.
[Post edited 12/19 - added the link to Gail Shaw's blog.]
I’ve read a number of responses from Chris Shaw’s first DBA networking quiz. I missed out on the first one, but I have been tagged by Grant Fritchey for the second round.
The Questions for this quiz… What are the largest challenges that you have faced in your career and how did you overcome those?
1) The first one of these, I still laugh at when I remember it. I got involved in the IT industry later in life than most (mid-20s) and found quickly that I had a knack for learning and applying new things quickly. I was doing tech and sysadmin work and there was an acute shortage of those skills, so I probably received more praise and recognition than I really deserved at the time. During those early days I started to imagine myself as the alpha ubergeek, and believed that I could be an expert at all things technical. I started to learn programming, jumping from C++ to Java and Perl to PHP, then onto non-Windows system administration – Linux/UNIX and even a little OS/2, and finally database administration in MySQL, Oracle, and of course SQL Server. I remember at the time thinking that I would be able to set myself apart as an expert on all these disciplines. Need an enterprise application built? I’m your guy. It’ll be a web app? That’s still me. I’m also the database guy (architect, dev, and DBA), and I’ll do the sysadmin as well. Oh, and I maintain the hardware too. I actually created a schedule that encompassed about two years, and included time for me to self-train in each of these topics. I wish I still had that schedule, which would now be good for a hardy laugh, but I can remember that I had allocated a mere three months to teach myself everything about both PHP and MySQL. This story does have a happy ending, in that I realized the absurdity of my intentions before I got myself in over my head. My youthful inexperience allowed me to convince myself that I could learn everything about everything, and could maintain this knowledge as the technologies changes. Another positive result is that my study in these other disciplines gave me a cursory understanding of other technologies to which I might not have otherwise been exposed.
Lesson Learned: Don’t try to be an expert in everything. Identify a few things that you enjoy and do well, and maximize your time in those areas.
2) This challenge is ongoing, but I’ve gotten much better at this, particularly in the past year. I’m a big believer in hard work, and I have seen that a person who learns a craft that is in demand and puts his or her nose to the grindstone will do well. However, when I think about the people that I perceive as successful, these are not people that simply work hard (although most of them do work very hard). Those who are exceptional are people-persons as well. They work to know their constituency, including executives, end users, and fellow technical staff, and are comfortable at explaining difficult concepts to all groups. They are good enough at office politics so that they are rarely blindsided. In short, these successful people have soft skills to accompany their technical prowess. One of my favorite lines used to be “I’m not a salesman, and I don’t play office politics”. However, I’ve learned that everyone has to be a salesman to some extent, even if you don’t sell anything, if for no other reason to do enough self-promotion to ensure that you don’t become an office wallflower. Office politics is not necessarily an evil thing – at its root, it’s about knowing people and understanding interpersonal dynamics.
Lesson Learned: Keep working hard, but you’ll do even better if you also spend some time talking to and getting to know the people you work with/for.
To keep this thing moving, I’m now tagging Tim Costello and Devin Knight.
