April 26, 2008 at 6:05 am
Comments posted to this topic are about the item The Exceptional DBA: Soft Skills
April 26, 2008 at 6:56 am
At my company the new product is being developed by a separate team that subscribes to the agile development concepts. While I wouldn't say they are "religious" about it, I do sense a disdain for email and phone communications. In the extreme, agile developement teams are all close together. Ideally any systems or DBA types supporting such a team are also close.
For someone who works Tuesday-Saturday in database support ( and who would like to telecommute more than just Saturdays ) this becomes tricky, especially in this economy. I think many older boomers like myself would like to get out of long commutes but it doesn't appear most companies are ready to outgrow the "walk around the building and talk" approach. Doesn't matter that half the time the "walkers" don't find the person at their desk.
My co-workers caution me that face-to-face communication is still critical to really know what's going on and that humans are just slow to truly adopt email/messaging etc. I'd say half of the emails I send at work are never responded to.
So soft skills are important even though some of us would happily get by on electronic communications from home. I may have to get serious about looking at full-time telecommuting elsewhere.
April 26, 2008 at 10:49 am
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 day.
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. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
April 26, 2008 at 12:58 pm
Keep updating the technical skills. Willing to listen to other people's opinions. No matter how good you are, someone may come up with a better idea.
Some DBAs think they know everything and never listen to anyone's idea.
July 10, 2008 at 11:27 am
An Exceptional DBA MUST BE Perfectionist, because If you ignores details, you ignores the reality
December 5, 2008 at 9:41 am
Tony,
I am starting to see a lot of job requirements listings like this for DBAs, system admins, and software developers.
We know, and some managers know, that no one has all those skills. People can't live fast enough to acquire them all. And, the technology keeps changing, which makes them a moving target.
I say "some managers" because I am seeing a trend in the industry toward what I call "career managers". These are almost completely non-technical people who climb the corporate ladder by taking few risks and living on the backs of their subordinates. Their expectations are too high, their knowledge too low, and they are looking for superstars to help keep them successful so they can continue to climb. These types of managers tend to be the ones that place job postings requiring multiple lifetimes worth of experience. They are also the ones that won't hesitate to work their people to death so they can survive and get promoted.
I've gotten to where I ignore the fact that I don't meet all of a job's posted requirements because no one does.
I've also noticed that the proliferation of these types of job postings are largely contributing to the phenomenon of "resume spamming". More and more job seekers are sending out resumes for jobs for which they do not meet the posted requirements. Who knows? Sometimes a person gets lucky.
The sword cuts both ways. If job postings defy rationality, job seekers respond in kind.
LC
December 6, 2008 at 9:05 am
crainlee2 (12/5/2008)
Tony,I am starting to see a lot of job requirements listings like this for DBAs, system admins, and software developers.
We know, and some managers know, that no one has all those skills. People can't live fast enough to acquire them all. And, the technology keeps changing, which makes them a moving target.
I say "some managers" because I am seeing a trend in the industry toward what I call "career managers". These are almost completely non-technical people who climb the corporate ladder by taking few risks and living on the backs of their subordinates. Their expectations are too high, their knowledge too low, and they are looking for superstars to help keep them successful so they can continue to climb. These types of managers tend to be the ones that place job postings requiring multiple lifetimes worth of experience. They are also the ones that won't hesitate to work their people to death so they can survive and get promoted.
I've gotten to where I ignore the fact that I don't meet all of a job's posted requirements because no one does.
I've also noticed that the proliferation of these types of job postings are largely contributing to the phenomenon of "resume spamming". More and more job seekers are sending out resumes for jobs for which they do not meet the posted requirements. Who knows? Sometimes a person gets lucky.
The sword cuts both ways. If job postings defy rationality, job seekers respond in kind.
LC
That's pretty much spot on, so far as I'm concerned. In my previous job, the new IT manager actually scheduled 12 hour days on a project that was way behind thinking that it might make a difference. It did! I didn't think it was possible, but it made things MUCH WORSE! People's already low moral made serious flushing sounds... the "whatever" attitude towards writting code became the mantra... IT people starting finding new jobs in other companies... people fled in droves because it was the "last straw".
While I agree that the good manager will surround himself with intellegent people and become a "professional delegator", it's important to remember that it's the people around him/her that make that manager successful. It's important to remember that the successful manager will enable his/her people, lead instead of push, and "take some heat" from the upper levels to protect the very people responsible for making any project successful.
And, if you're a good subordinate, understand that the occasional all night death march is going to happen. Do your best... remember that "When you're going through hell... keep going." If it turns out that all night death marches are the rule instead of the exception, make damned sure that you're not part of the reason that occurs. If you are, then get hot. If you aren't then, you know the choices... in today's economy, choose wisely.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2008 at 4:25 pm
December 8, 2008 at 7:21 pm
'Zactly... 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
December 8, 2008 at 9:33 pm
More and more I think that you need a break. I probably work too much, and I'm trying to figure out how to be better there. Really more efficient in less time so that I get away more, or take more breaks.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply