It's interesting, I'm wondering what will happen in a few years time in this sense actually.

"When I were a lad" (oh dear...), getting my first home network set up required knowing at least something about IP addresses, netmasks, network cards, and even IRQs just to get a couple of computers talking. Trying to share my first dial up internet connection brought me into the world of WinGate, proxy servers, NAT, and far more that I didn't know about at the time, but was quickly forced to learn.

Now, if I want to do the same thing on WinXP, I have the "Home Networking Wizard". It's great for most users, don't get me wrong, but I reckon it means the number of people hitting a Computer Science course or, worse, a software related job with far less knowledge about how computers /actually work/ is going to go up. Either that or they're never going to get interested in them in the first place, since it all just "works", and no-one thinks about why...

Long live the BBC Micro!

Cor. It would certainly be nice if SQL Server 2005 'just worked', Rob! Actually, you're right about the need to vault over the pain barrier a few times in order to learn IT skills rapidly.

(BritSpeak paragraph others turn away now) The BBC micro, Amstrad and Spekky have definitely spawned a generation of geeks in the UK.

Going back to Rodney's original point, I think it is the same problem everywhere getting good DBAs. It takes five years to train a DBA, and the industry has cycles of boom/bust every five years. This means that there will always be either too many or too few of them.

Being utterly fed up with Recreuitment Consultants, I applaud those company's that look for their own candidates but fail to grade their expectation of the required expierence (say in years of being a DBA, years of SAN expierence and to what level...) how do candidates know what level it is they need to attain before applying?

We've all been there - "just seen the CV you submitted, you look a strong candidate...<long triesome conversation with ReCon>...and could you change the line about your MSSQL DBA expierence to be a little more 'extensive' and include ..." - start ringing the alarm bells!

What do you do?  You've spiffed your CV for the job description, you want to remain honest but you want the interview.  What you really want is a great job not a bad interview.

20 interviews for a tech role is nothing (having recruited a few folks over the years) but I wholeheartedly agree that finding someone who has the capacity and interest to get on with learning something new is the difference between a good team member and great one.  Their going to be the most difficult person to find.

I believe there are two slightly different types of senior DBA, a senior platform specific DBA and a senior platform agnositc one.  For example, a platform specific MSSQL DBA will know the details you mention.  Whereas a platfom agnostic one will know how to find it for any platform and may know it for your OS/RDBMS combination.

I have also noted a difference between System DBA and Data DBA as I call them.

System DBAs ensure that the components associated with there system work together, this will include an RDBMS, a database, might include a web server, app server, process scheduler, etc.

Data DBAs IMHO, concern themselves only with the RDBMS, database and the data going in and out.  I've seen such DBAs treat the associated front end server components as 'someone elses problem'.

Obviously it gets to a point where expecting an individual to know the intimate details of numerous RDBMSes, web servers, app servers, etc on the various OSes (even if limited to MSSQL there are differences in this restricted pool of OSes) AND the initmate details of your set of data combined with generic relational theory, at least one SQL syntax (does anyone out there support only one RDBMS?) etc becomes impossible.

However any DBA at intermediate level or above should know relation theory, be able to discuss enough generic OS admin details to talk intelligently to any OS admin (Windows, Unix or mainframe) and IMHO be a skilled researcher.

I beleive it is the 'skilled researcher' item that allows me to resolve any issue on any platform, a bold statement I know but I'm onto my third RDBMS as a senior DBA and 9 OSes I can think of.  Some problems have taken longer as I had to do more research.  

And I beleive this is better than knowing one RDBMS in total detail.  It has stood me in good stead as OSes have gone out of favour (anyone want a Dynix/Informix DBA?, I'm glad I can also administer Solaris/Oracle and Windows/MSSQL, etc)

Regards
Karl

Rodney,
Could not agree more.  I've been in and out of databases - from both the commercial development/product management side of the business, as well as the consumer/DBA/Data architecture side of the business.

There is, I fear, a growing gap between "real-world", experienced, capable, and competent DBAs and what I term the '1 to 2 years under their belt, took a cram course and got certified" DBAs.

Your other reviewers make great points about the challenges we face - after all, systems are not getting simpler and smaller in scope - just the opposite in fact. I suspect we will need finer granularity in our job scops as systems continue to develop.

However, there is another, big aspect that I suggest is a large contributor to the current landscape.

Before we get too frustrated with individual talent, we need to remember what is fueling this growing gap.  Being a 50-something US citizen, I've watched too many businesses morph from desiring to hire the best they can afford in the market, to being greedy, short-sighted entities that want Congress to provide them an endless stream of cheap labor via work visas.  Folks who can come in and take the 'jobs that no one wants' ... which is short-hand for the jobs recently vacated by expensive home-grown labor, vacated via a reduction-in-force.  The job is shortly thereafter marginally re-defined and filled with such employees.  Failing that, (hey there are only so many visas each year after all) they'll take the '2 year wonders' described above, after all, they have certifications!  Before anyone shouts conspiracy theorist - I've personally witnessed this - not once but several times, so it is not a theory.  It is observable and factual.

I believe that is why all HR seems to care about these days is how cheap is the labor, and is it certified?  When business is allowed to artificially supress the going rate by importing cheaper labor with the same skills from the 3rd world, the only room left is for the '2 year wonder'.

Think about it this way.  10 years ago, IT was the 'engine of growth for the US economy'.  About that time the work visas started flowing out of Congress every year to cover what companies such as Microsoft argues is a shortage of qualified labor.  Now, I took enough economics to know in a 'free market' when there is a shortage of something, prices rise.  When there is a chronic shortage in the supply of something prices soar.  So why is it that 10 years on, the 'price' of 'qualified' labor for IT is less now in many sectors, than it was 10 years ago?  Why is the quality of that qualified labor arguably less now than it was 10 years ago?

Now, like you, I hasten to add that this does not characterize ALL employers, but like you, I observe this condition is noticeable and 'generalizable', because it is so prominent.

I also hasten to add that I've worked with many people here on the 'work visa'.  They are generally as competent as their western counterparts, but that is not the point.  The point is, until I see our leaders in business and government volunteer to take pay cuts that put their standard of living at the same level and the labor they are importing, I object to the notion that I or my fellow citizens should submit to artificial pay cuts to sate a bunch of greedy CEOs who are too lazy to figure out a way to survive other than cutting costs.  

Eisenhower warned us in the US of the 'military-industrial' complex.  I think someone needs to warn us about the 'congressional-industrial' complex.  After all, 10 years on, if we still have a shortage of qualified labor, if I were in government I'd have started to shift my focus away from work visas to employment programs and other issues that would address to root cause of a lack of qualified domestic labor.  Well I would if I were nominally concerned with trivialities like, oh, say, national security, a sustainable tax base, not having my economy held hostage by foreign markets, etc.

We need to get the grimey hand of government out of the labor management business and let the market freely dictate what the price of quality labor in our own country(s) should be.  Moreover, stock holders need to start demanding better performance out of their management teams.  

Demand for excellence, and a requirement that our governments quit trying to cheat the free-market system - that's the recipe for a return to quality DBAs, Developers, Data Architects - really any position.  But as long as businesses can cheat the system in the short term, I expect this trend to continue and worsen.

(Ever notice that these CEOs and 'leaders' that talk about how the industrialized western worker needs to learn how to compete with the 3rd world, never seem to suggest that the same might hold true across the board?  I bet there are qualified CEOs in India, China and other locales that would love to come work in the US.  I also think, based on recent scandals and high-profile busts that one could argue there is a shortage of qualified CEOs in the US.  HMMMMM Sauce for the goose - maybe that's the cure?).

Maybe I fall under the "The second type of DBA has chosen the migratory path from developer in a few short years, and has not benefited from the trials and tribulations that experience provides" but I have also come across team leaders who are hung up on technical detail which is frankly puerile,  keep important information close to their chest so that they can reveal it at opportune moments to make themselves look clever  and their underlings look inadequate,  are poor communicators and generally have an over inflated idea of their own self importance.  I am sure that you couldn’t possibly be one of these managers who confuses altruism with climbing up the greasy pole and fills his head with large amounts of soon to be obsolete technical data but one thing I would say is that in my (obviously limited) experience developers tend to be brightest people working in IT and the “DBA role” and whatever it may entail is generally small potatoes in comparison to writing a good piece of software.

Incidentally I do know the difference between AWE and the /3G and /PAE  switches but would seriously question your sanity if you a) expect there to be multitudes of DBA’s out there who have experience of 64 bit installations and b) expect a DBA to rattle off all the differences between the different SQL Server Editions in a interview.  Get off your high horse and get real.

Let's get real here... The DBA is now a insulated from the world of hardware. Most shops have a group of people who maintain the san and server boxes... It's my job to try to get tables designed with foreign keys, indexes and the like and make sure that sql is running.. not setting up a SAN or server. We have quickly reached the point where one person CAN NOT and SHOULD NOT be an expert in everything.  I am giving my age away but in the mainframe world we had the "Systems" people and the "App" people what makes you think the windows/sql server world would be any different as it gets more and more complicated.

The gist of this article seems to be the author's distaste for the "mediocre" -- i.e., those people who are less knowledgeable and talented than the author thinks they ought to be.  I am tempted to dismiss such rants as thinly disguised self-congratulation -- too tempted, I'm sure.  Yes, I ought to work harder at my craft, and I'm sure that I'm not the only one who is grateful that I don't need to take a job interview at the moment.

Even so, it is a truism that half of us are below average.  'Below average' for a DBA may mean something different than 'below average' in some other profession that requires less in terms of logical and abstract thinking prowess, but that is beside the point.  In every profession, there will always be a pecking order.  Sometimes we are judged not by how much we know, but by how much grace we are willing to extend towards the lesser talented.  I am reminded of the old Connie Francis song, "Everybody's Somebody's Fool".  No matter how dilligent we may be, there is someone, somewhere, who could dismiss even the best of us, reading this, as a "mediocrity".  (I've seen and worked with a couple such people; it can be the most inspiring, or degrading, experience in one's career, depending on where they happen to fall within the saint/jerk continuum.)

As a DBA who was around during the Mesozoic era, and writing COBOL before amphibians developed toes, I have always found that it is easier to impress management with a willingness to take responsibility for a task, than with any arcane knowledge that resides on the tip of the tongue, and (more likely than not) is already out of date by the time it is mastered.  It is easier to endear oneself with one's boss if one is pleasant and easy to work with, than with the ability to combust spontaneously into lectures on 5th normal form, or extended memory switches.

FWIW

My experience has been that the DBA function can be an afterthought.  I've worked several places where developers only talked to the DBA when it was time to move the database into the Test environment or if their query was "slow".  Including the DBA was done because they had been told by their manager to do this.

A competent DBA should be able to explain the importance of file placement on attached storage in order to minimize IO.  I agree about being a 'skilled researcher'. Quickly finding the offending query or queries that cause things to be "slow" and explain what it is about the query that is offensive is important.  Helping developers with tips on improving performance is important.  Too many developers are interested only in meeting the deadline and if the finished objects meet spec.  Performance is an afterthought. Being able to get along with folks and explain things in a non-technical manner is helpful.  I've had so many people with whom I work tell me that I am not like other DBAs in that I don't act like I'm God and treat them like they're peasants.

I do think the main role of HR is to keep management out of employment related lawsuits and secure labor as cheaply as possible for the qualifications desired.

I fully agree with Rodney. There is a huge gap between a DBA like myself and the DBA wantabees...    I have been making a good living the last few years by being the hired gun that comes in and cleans up the mess created by a wantabee or worse a .Net / Web programmer that thinks that EM or Studio looks and acts just like Visual Studio.  

I have been introduced to many in-house DBA when I have started a new assignment.   Then within a few days, the in house guy is gone.  In one case, the in-house guy was walk out at lunchtime.   Sad situation but too many people are believing the paper qualifications as opposed to solid understand of the database world.