October 22, 2009 at 9:20 pm
Comments posted to this topic are about the item The Value of Experience
October 22, 2009 at 11:02 pm
Yay or Nay?
I'll say definitely Yay!!!
In my experience (15 yr) of recruiting, I've interviewed somewhere between 500-600 people and went over thousands of CVs to pick those top 500. Not all of them were as good as I hoped in day 1, but the only ones that lasted long and did well on their jobs were the ones with vast experience in OTHER fields. We're talking about C# programmers that were computer technicians before, business analysts that were programmers before, etc.
The reason is that today, almost anything can be done by any tool: You can calculate tables in MS Word and design good looking text in Excel. The issue is choosing the right tool for the right job. You need to know your tool's capabilities, but more over,have a true knowledge of its LIMITATIONS.
DBA is no different than that: If you're really good you might know HOW to do that using SQL; But If you have experience, you will know IF you should do that in SQL in the first place.
Yay it is!!!
October 22, 2009 at 11:37 pm
I have to agree. I call it the hammer and nail principle.. When all you have knowledge of is SQL you think every problem should be solved with SQL. You need to have experience in other tools to be able to evaluate whether a problem should be solved by a particular tool..
CEWII
October 22, 2009 at 11:42 pm
I'd have to vote yes on this one. Other experience in some other area of IT is an absolute must. But there's 2 basic types of DBA - those that work in development environments, providing information and guidance to development teams, and those who work in production environments, keeping systems up, available and responding well.
Development DBA's do best if they come from a programming background because they have the experience of understanding the requirements of application development and using database resources from the other side. Production DBA's that come from a systems administration / networks / OS background are more suited to the job of keeping systems up, understanding the need for reliable and tested backups, capacity planning and security.
I've never met a DBA that just did a short course and then got a job... probably because they wouldn't keep that job for long...
October 23, 2009 at 12:05 am
I'm going to take the opposite stance from a lot of other folks. Sure, I believe that you have to know other "stuff" to be a good DBA or even Developer... but too many people are using things like CLRs, NHibernate, Hibernate, and a wad of other hooie because they don't know T-SQL or what it can and should do. Everyone keeps ragging about DBA's that need to know something else... how about GUI and other types of programmers? They should learn T-SQL! 😉
Just like folks say that not everything should be done in T-SQL, not everything has to be done in something other than T-SQL. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
October 23, 2009 at 1:12 am
I am going to say Yes and No. Yes because you need experience of other areas but No because I think you need to have experience of other areas of business not just computing
If you do not understand the operational reasons/needs of the organisation, you cannot be effective. Your databases may be backed up, optimised, performance tuned etc etc but the information within them is useless to the front line forces. DBAs should be proactive not reactive
Madame Artois
October 23, 2009 at 1:39 am
S Hodkinson (10/23/2009)
I am going to say Yes and No. Yes because you need experience of other areas but No because I think you need to have experience of other areas of business not just computingIf you do not understand the operational reasons/needs of the organisation, you cannot be effective. Your databases may be backed up, optimised, performance tuned etc etc but the information within them is useless to the front line forces. DBAs should be proactive not reactive
Your comments dont make sense, A dba is responsible for integrity and security of data, the content is irrelevant. Your responsibilities to the business could be non-existent depending on the company. Knowing how the business operates does not help as much as people make out.
Having a broad IT knowledge/experience/background can help you as you have a lot of experiences to draw from. Having business experience is only helpful, if you are engaged in assisting directly with the business.
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
October 23, 2009 at 2:02 am
Too be a good DBA you do need understanding for other things than just the database. I'd say you should have some AD experience, OS experience. If you also have programming experience of setting up and distributing programs and building programs you'd be a even better DBA because then you are of higher value to the company because you can help the developers in a better fashion. Limiting experience to only one thing without no understanding of what the sql server is running in for a type of environment is a bit ignorant I'd say because having the bigger picture always provides a greater understanding.
October 23, 2009 at 2:16 am
Just like folks say that not everything should be done in T-SQL, not everything has to be done in something other than T-SQL. (Jeff)
True, but in order to be able to choose among two or more options - you need to have the other option (other than TSQL)....
For instance, a guy with some UNIX knowledge will never write a script to replace strings in a text file. He'll use SED command instead. If you only know Windows, you'll never know that it ever existed...
October 23, 2009 at 4:53 am
From my perspective I'd say understanding the context of the data you're manipulating allows you to see the bigger picture. However I'm a bit of a mongrel.
Choosing the right tool for the job is possibly not as important as reducing the complexity of the environment though. Tacking yet another "best in class" solution on every time you want to do something new is surely not the way forward (for a start how do you know it is best in class if it hasn't been around for 10 years, it's probably just another piece of cutting edge buggy crap). For me - there isn't much of anything you can't do with your business logic in TSQL, I'm with Jeff.
As to knowing bits about other aspects of the architecture - of course you need to understand a bit about the OS you're sitting on and the authentication systems surrounding it.
Perhaps how puritanical you are about this questions depends more on your environment than anything else - if you're looking after 50 databases for a company you're going to be spending an awful lot of time examining log files and query execution plans and doing not a lot else, if you're looking after 5 you need to spread out a little...
October 23, 2009 at 5:46 am
The DBA does need to understand the business.
Real world example: A developer who didn't understand nulls designed a nomalized database schema. For many of the table columns he recommended a Default of zero for column values. This went right past the DBA. The columns contained values for a sexually violent predator tracking system. The # of murders, rapes, etc were defaulted to zero if the values were not entered into the data entry screens. These values weren't always known when the initial data was entered. Instead of marking the missing data as null, the database created values. Misleading information, YES. Garbage in Garbage out, YES. Never the less, the DBA missed it.
The developer was MCSD certified.......
October 23, 2009 at 5:56 am
The example I was thinking of was not so dramatic but just as dangerous since it involved bridge construction. And again, it involved default values (amongst other catastrophes).
Madame Artois
October 23, 2009 at 6:00 am
I think its been about 20 years at least since I first heard the DBA moniker and its still the most nebulous title I know of in the technology business. To this day, I think if you asked 100 people what a DBA "is" or does, you would get a smattering of 100 different answers.
Still, for me, I have never filled any DBA position without two critical skills: One, obviously, an in-depth knowledge of SQL Server (or Oracle in some cases), and two, some knowledge of at least one mainstream programming language. I have had people insist to me that a DBA does not need to know a programming language - I disagree totally and find that to be like a carpenter who knows various types of wood, but has no knowledge of tools and how to use them. I don't see how any person can "administrate" databases without some idea of how those databases actually get used.
I've given up my long held hopes that someone would standardize the DBA role and define it once and for all, but I have learned that when we go looking for DBAs we always include those two requirements. At the very least, this weeds out those who think, but are not sure, that they are a DBA.
October 23, 2009 at 6:04 am
I use to think that "wide" experience, such as I have, made me a better DBA and overall better asset for my organization. I would not trade my wide ranging experience for anything but, having said that, I realize that I am far from an expert DBA and that with todays advanced technologies as specialist with very focused experience might be a better choice.
I think there is room for both and both are needed in different situations. When designing/planning new systems I think both are needed, during implementation the specialist is a better bet to get over the hurdle and during long term maintenance either experience set will work. For my money, I want the MANAGER/EXECUTIVE to have the wide ranging experience and enough confidence to listen to the specialists when needed. Those type of managers/executives are hard to come by.
James.
October 23, 2009 at 6:21 am
IMHO, you have to know your sh!t, but if you're living in a bubble of technology and you isolate yourself from the knowledge and issues of whatever business you work in, you're not going to last long.
Case in point. No one is ever going to nominate me for any DBA honors. But I try very hard to understand the business area I work in (asset management) and hopefully I can add some value that a sheltered propeller head wouldn't.
Likens to the Predator problem previously mentioned.
Lastly, bringing some "logic" to a problem can be both rewarding and challenging. In a sort of amusing way, I find myself being invited to meetings or purposely left out because I think of the "what ifs". Some people have ideas but don't want to or cant defend those ideas from even a cursory examination, others welcome the challenge and use it as an opportunity to improve it, or prove it is valid.
I received a great compliment in the form of an insult. I have a nickname with certain people here. Besides "The big @rsehole", some refer to me as "Mr. Black-n-White". Might have something to do with me referring to a situation as either correct all the time, or it is wrong. analogous to algebraic proofs...
Honor Super Omnia-
Jason Miller
Viewing 15 posts - 1 through 15 (of 45 total)
You must be logged in to reply to this topic. Login to reply