You've summarized the soft skills very nicely, Tony. And, I absolutely agree, David Poole's well thought out statement of "if people will voluntarily use you as the first point of contact for database information rather than the last, then you are probably an exceptional DBA"
is probably the best way to summarize all of hard and soft skills in a single sentence.
In this current article, you wrote...
Mentoring / Teaching– the exceptional DBA must be willing to teach others what he knows, whether this be through mentoring a junior DBA, participating in forums, speaking at conferences.
Folks, I'd like to dwell on this a bit. It shouldn't just include coaching a junior DBA... participating in forums will certainly broaden your skills as well as helping the general public and that does help you help the company you work for, but not enough... same goes with speaking at conferences... it will build your skills in preparing presentations and recommendations at work. All of that builds YOUR skills, but it's missing something...
Then, you go to work and have to struggle to get folks to follow coding standards (if you wisely have them) or you have to struggle with developers that just don't understand how to code with accuracy, performance, and scalability in mind. And, make no bones about it, it's a daily struggle... and that's where a lot of DBA's fail. They don't share knowledge about the trouble spots within
the company well enough.
For example, we had problems with people (developers and general users) writing code for date/time manipulation. Of course, the general users (folks in Finance, etc) are only allowed to write queries against the reporting database. The accuracy problems with the developers and general users, alike, were that they were writing things like monthly reports that either missed all but the first millisecond of the last day of the month or they did things like subtract 1 millisecond from the first of the next month without realizing that incorrectly included a lot of "date-with-no-time" information from the next month due to rounding (3.3 millisecond accuracy of datetime). The performance problems included converting dates to character based dates using CONVERT and all manner of other calculations to get "whole days" and not realizing the effect on performance. None of the reporting was accurate nor performant. Since I was the one doing ALL the code reviews, it became a real load on my time because I would have to sit with every developer to explain and answer many, many "why is my report running slow" phone calls and visits from end users every
I explained the problems to the IT managers and the managers in other departments... and got immediate acknowlegement that there was, indeed, a problem and that they wished there was a way to fix it. I proposed teaching a class as "Lunch'n'Learn". The class would meet for the lunch hour once a week for 3 weeks to learn all about not only the right way to manipulate dates and the related aggregations, but also how to spot the wrong ways and why they were wrong so they could fix them. I created handouts in the form of a "cook book" for each of the 3 classes and, when they put all 3 together in a binder, they had an indexed booklet with everything they needed to know about how to do the date manipulations so common to reporting.
They bought it! Some of them even required their charges to attend and paid most of the hourly employees for the hour! Some of them even paid for a lunch to be delivered because they thought it was so important! Even some of the managers attended just so they could "keep up" with their employees!
That was more than 2 years ago... to this day, most of the folks writing reporting procs or ad hoc queries that use date aggregations still have the book out and open when they write queries. Many of the managers issue a copy of the "How to Use Dates" booklet to every new employee that may have to write a query to do their job. Users actually teach other new employees in their area how to do things the right way and why! The overall effect has been incredible... Performance of reports has sky rocketed and accuracy of the reports has become "spot on". Better yet, code reviews have become a breeze in this area and the phone calls for help on slow running and "how to's" for reporting queries have dropped to near zero.
What did all of that cost? What is the ROI of all that?
It takes about 4-5 hours of preparation time for every hour of "podium" time, if you do it right. That includes figuring out what you're actually going to teach, what the logical order of "revelation" should be, practicing what you're going to teach so you can end at a "logical spot" at the end of and hour, and creating the "bookable" handouts. Worst case for the 3 hour class... my cost was 15 hours of prep time. The ROI there is that it was costing me about 8-10 hours per week in code reviews and answering the phone. 15 hours of prep time, 6 hours of actually teaching (I taught the series twice)... that's 21 hours of my time vs the 104+ weeks times 8-10 hours per week! I've saved myself almost 900 hours in the last 2 years!
How about the company? What did they save? I had 20 people in each series of classes (40 people total). Let's say they were all hourly employees (they weren't). That's 3*40 or 120 employee hours and some lunch money... where's the savings? Well, they no longer need to call me for help, they spend a lot less time building and testing their report code, they spend a heck of a lot less time troubleshooting their code because their numbers don't match someone else's numbers, and they spend a lot less time rerunning their code to get good numbers.
And, let's talk about some of the "intangibles"... a lot of the reports are "public facing". They either go to the owners of the company (we're not public but the numbers better be good), goes to 3rd party billing/invoicing (errors may cost money either in missed collections or people being paid to explain to customers why we overbilled and do refunds, etc), or to tax agencies (do it wrong or do it late and get fined). The hidden costs of earning a bad billing reputation to customers may show up in the form of lost customers and bad referrals preventing new customers. The list of intangibles goes on.
I recently identified a similar problem... a lot of the developers didn't know how to parse CSV parameters passed from a GUI. Many of the others didn't know how to get a SUM of "0" for missing dates and had resorted to cursors and while loops. Others had the requirement to generate 1 nearly identical row for every "qty" aggregate that appeared in a view and had also reverted to heavy RBAR to generate the rows. Guess what? I started teaching them how to use a Tally table in SQL Server 2000 and how to use ROW_NUMBER() OVER CTE's in Oracle (Oracle calls it "sub-query refactoring", by the way). 2 hours after the first "Lunch'n'Learn" on the subject, 2 developers and a manager came up to me and explained how it had solved several problems they had been agonizing over and how much faster it made their code. Get this straight... THEY SOLVED THEIR OWN PROBLEMS and I didn't have to fight with them about using RBAR in their code during a code review! Everybody is happy and I didn't
have to show them how!
So, to summarize, it's well worth it to go the extra mile to teach
the information in both informal and formal classes of about an hour each session. I spent maybe 30 hours total (9 hours to convince everyone that it needed to be done and 21 hours to prep and teach dates) and it saved me hundreds of hours in the 2 years that followed. It saved the company immeasurable hours and intangible dollars in that same time period and it continues today. Teaching a simple introduction to Tally tables to a group of developers just saved the company and dozens of hours in writing non-RBAR code not to mention the code running better...
... And, best of all, it has improved my reputation with the managers as being "someone to seek out" when project plans are in the works or when there's a real design or performance problem. I no longer have to "fight" to get things done right... it just happens, now.
Go the extra mile... don't just share information... identify these types of common problems and teach EVERYBODY how to fix them. You will never
be sorry that you did.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs