The Core
-
I'll paraphrase my buddy, Andy, who reminded me of his core tenet a week ago.
Go with the defaults until you have a reason not to.
Normalizing should be a default.
-
Surely the most important thing for any technical role is the soft skills to fit in to your team, liaise with management, customers and colleagues, and only then the hard skills to do your own job - it is no use being a Guru if you carry out the wrong tasks because you don't understand requirements and don't know how to influence others into asking for tasks to be done the correct way.
Throw away your pocket calculators; visit www.calcResult.com -
Actually I think if the soft skills aren't there, if you don't fit, you shouldn't get hired. And you shouldn't take the job.
Soft skills are critical in my opinion, and they're a given. The Core hard skills are what I was looking for.
-
I've always been a strong proponent of normalization, but it can be carried overboard -- as in the OLTP database I inherited at my current job. It had been essentially developed as an object database by developers (with no dba on staff) with many foreign keys looping on same table. Not long after I joined this organization one of the developers asked me to look at one of his queries to populate a drop down list -- it was a 20 table join with about half the joins being left outer joins.
IMHO, this was carrying normalization way too far. Common sense can go a long way in architecting a DB.
Mike Byrd
Mike Byrd
-
Hmmm, soft skills. Icing on the cake, really. Those soft skills aren't going to help you at 3am when you have a 30 spid blocking chain on your 24/7, $100,000 per hour e-commerce app. It won't help you when the newbie support analyst decides to delete a few rows but neglects to highlight the WHERE clause in SSMS/QA. It really won't help you when you have to troubleshoot a 10 database transactional repl topology with updating subscribers...or the dreaded merge repl.
It WILL help you when you are required to champion the merits of a $250k reporting server. It WILL help you when convincing your boss that SQL 2008 is the greatest thing since SQL 2005. It WILL help you when you are the lone guardian standing between hotshot developers, lazy testers, and many a sleepless night.
Soft skills. Important, yes. But not "The Core".
James Stover, McDBA -
Soft skills are not just the icing on the cake - it is soft skills that get you someone that you can phone up who knows the answers; it is soft skills that get the previous guru to teach you the tricks before he leaves; it is soft skills that get you that vital bit of data that shows that it IS a DB problem and not an App problem.
The most important technical skill for me is to be able to understand what it is that your colleagues do: when the network guy says it isn't a network problem, is he right? when the java dev says it isn't his fault do you believe him? If you are sure it isn't a DB problem, do you have the soft skills to persuade either of these guys that they need to get out of bed to fix 'your' problem?
Finally, good soft skills will ensure that when you are on holiday, you have cover that knows what they are doing, and don't have to call you in anyway.
I guess if your organisation can find, and keep, two guys who know every last thing about SQL then you don't need any soft skills - but find anyone who says they know everything about any subject and you have found a liar or an idiot.
Throw away your pocket calculators; visit www.calcResult.com -
When I did one of my Oracle training courses, I was taken through various scenarios for recovering databases in varying degrees of trouble. The Oracle trainers were keen to underline that the first action they'd like a DBA to do is stop and think, followed very closely by a serious consideration of ringing Oracle's support. Asking before anything irreparable is done is far more likely to result in recovery than trying several things, finding they don't work and then asking the questions.
Whilst the above scenario raises all sorts of discussion points, it does underline that a DBA who thinks they know everything is a dangerous animal. Someone with the humility to ask for a second opinion even when they think they're right is a far safer pair of hands in which to put your company's precious data. The right attitude (not gung-ho, not precipitous, not impetuous, not egoistic) is a very difficult skill to instill in a potential DBA, but is IMHO far more important than their technical skills, since it underpins them.
Worth bearing in mind that Steve did ask originally about the core skills you'd want to teach to a junior DBA, so that's not someone who's going to be left alone at 3am with your £100,000 per hour e-commerce database (or at least, I'd sincerely hope not). No-one's disagreeing that techical skills are important, but they have to be underpinned with the right "soft" skills or you're just going to end up with a loose cannon.
Semper in excretia, suus solum profundum variat
-
I really must be missing the point because of the 1000's (yes, 1000's) of DBA job descriptions I have seen over the years they all have hard technical skills as the main pre-requisite. There's always the "strong interpersonal and communication skills" bullet, but this appears at the bottom well after the "security, performance tuning, and recovery" bullets. I've done dozens of interviews for DBA jobs and I always get questions around normalization, security, performance, blocking, replication, etc. The soft-skills interview is the 3rd or 4th one - usually with a senior manager - well after my core technical skills have been assessed. As I say, when the sky is falling it's those core set of technical skills that will prove your worth as a DBA. Anything less is merely a support analyst 🙂
I agree that soft skills are a necessary component of a person's overall skillset (and definitely required for career progression) but is not a core DBA skill. That's my story and I'm sticking to it.
James Stover, McDBA -
He, he. Know what you mean, James. I suspect we're heading rapidly into "agree to disagree" territory, but here's my take.
DBA job descriptions are, in my experience, rarely accurate when advertised. If they're descriptions of vacancies needing to be filled, then those descriptions are wishlists. If they're descriptions of filled and active jobs, then the descriptions tend to rely on nice, easy, clear cut and measurable responsibilities and prerequisites first. Nebulous stuff like "right attitude" is almost impossible to formalise in a job description, so is largely ignored, whether it's seen as critical or inconsequential.
I tend to find something similar with interviews, too. Discrete and distinct factors like "able to write joins in T-SQL" are easy ways to filter out candidates early on (probably by recruitment consultants and HR departments, neither of whom understand much about working in IT). It's only in the latter stages of filtering that the person/people doing the filtering are those involved in the IT department, and it's only then that the more difficult assessments are made. In short, the order in which one's skills are assessed doesn't need to bear any relation to the real value of those skills.
As for "when the sky's falling" scenario, I've been in that position a (thankfully only a) few times, and seen others in that position a few times more. What's almost invariably been the difference between successful resolution and reduction to a steaming heap has not been the technical skills, but how they've been applied, and most importantly the structured, methodical attitude that's lead to knowing when NOT to go diving forward with technical tinkering, but to consolidate a known quiescent point. It takes strength of character to say, "no, I'm not going to try fixing this until I've got a backup of what we've got" when everyone's screaming at you, but that's often what stops a bad situation getting worse. If I had a raw recruit and wanted to instill just one important point, that'd be it. I'd far rather have a plodder with the right attitude than a techical wizard who lives by the seat of their pants.
But, as I said, that's just my take, and it's obviously different from yours, and I'm not sure those two viewpoints are ever going to quite meet in the middle.....
Semper in excretia, suus solum profundum variat
-
If we want to consider the sky is falling, then the #1 skill for a junior DBA is to know you're in over your head and call me or MS for help. It you have a$100,000 system, and you're a junior, you shouldn't be restoring it.
-
How many job adverts (any discipline) get written by HR, and how many get written by techies?
In any case, as technical experts, how many of you would accept the wisdom of the uneducated masses over a reasoned argument? You'll be quoting from Wikipaedo next!
Steve: (don't take this the wrong way, but) do you truly believe that you know everything there is to know about SQL server? ??
Throw away your pocket calculators; visit www.calcResult.com -
Mike,
I think I'm missing your point. I think most job adverts get cobbled together by HR with feedback from techies. "What do they need to know?"
"SQL, backup, restore, etc."
"Anything else?"
"Well Java would be nice since we have that one old system in the corner"
"I'll add that"
I know very little about SQL Server, given the breadth of the 2005 product. In the 2000 days I had a good handle on lots of how the product worked, but I still learned things in 2004 and 2005 as I was doing more DBA type work.
I'd argue NO ONE knows everything about SQL Server and even the highly skilled experts have lots of places they've never worked in the product.
-
Steve Jones - Editor (7/10/2008)
I'd argue NO ONE knows everything about SQL Server and even the highly skilled experts have lots of places they've never worked in the product.When I was working on the dental system we put out user newsletters. We solicited the customers for articles. Imagine our shock when one of our customers submitted an article that was over 20 pages single spaced. They had combined our recall reminder feature, our top notch appointment scheduler, and our visit slip print out into a complete orthodontic treatment management system.
Neither our staff or our practice management consultants had a clue that you could do this. We had to publish their stuff in installments. The whole thing was made available as a manual. We then used that as a set of "requirements" to build this into the core product.
Expect your customers/users to surprise you.
ATBCharles Kincaid
-
This picture says it all
You'll never know everything about SQL Server, and while you learn you'll discover how much you still don't know about SS 🙂
-------------------------------------------------------------
"It takes 15 minutes to learn the game and a lifetime to master"
"Share your knowledge. It's a way to achieve immortality." -
Actually, that diagram should be labelled:
What you know
What you knowthat you don't know
The background then becomes:
Things that you don't even know enough about to know that you don't know them yet.
Throw away your pocket calculators; visit www.calcResult.com
Viewing 15 posts - 46 through 60 (of 60 total)
You must be logged in to reply to this topic. Login to reply