Why is Database Administration so hard?
The position requires a broad spectrum of knowledge ranging from development to system administration and even management. Not only must a DBA know about backup, recovery, internal operations, memory and security, but also how to communicate with both developers and management. A DBA could be giving a high level presentation to management, helping a developer tune a query, provisioning disk space for a new system and restoring data from backup all within the same hour. These responsibilities require a wealth of knowledge with little overlap.
The consequences of failure are usually greater for a DBA than a developer. DBAs often support dozens, even hundreds of different applications and systems most of which are vital to the success of the company. A security breach, recovery failure, or performance problem could have far reaching and devastating ramifications. This requires a level of knowledge and experience that can’t be gained in a short amount of time.
The better a DBA does their job the less visibility they have. A DBA with a database that is secure, recoverable, available, and performing well will lack recognition. DBAs get noticed when there are problems. Not only do they get noticed when their problems are self-inflicted, they also get blamed when the database has problems due to poor coding, improper network setup, or incorrectly configured storage.
I switched from developer to DBA when I was 29. For me the things that make being a DBA difficult also make it rewarding. I enjoy absorbing and using a wide spectrum of knowledge, and the greater opportunity for failure makes the avoidance thereof all the more meaningful whether others see that or not.
Becoming a DBA actually demands a great measure of experience but it can basically come from only four different paths:
- Being a developer and making a segue to a DBA
- Being a developer and being drafted as a DBA
- Training straight from college/trade school to become a DBA
- Being a SysAdmin and making a segue to or pulling double-duty as a DBA
Being a developer and making the segue to a DBA
In another question that was asked on this site, How Could DBAs be more 'programmer-friendly', I mentioned that I was a developer for 16 years who worked with DBAs. Having worked with them made me realize that to the extent their experience included database theory, discrete math, and programming experience, to that extent they could see how a database should work and how a query should execute.
Having a DBA with those things in their background made me feel I was still in college learning from some adjunct professor but who really knew their stuff. As long as the DBA was willing to share what they knew, without lording it over you, they could actually become your mentor in terms of developing SQL statements (SQL is, in itself, a Context-Sensitive Programming Language) that are as efficient as possible. Sure, there are the other mundane parts, such as performing installations, making backups, doing software upgrades, monitoring performance metrics, generating reports, and so forth. But as a developer, if you focus on the databases, and the SQL that runs against those databases, over time you will becomes so adept at SQL that it will be second nature and you can focus on the application development.
The demands on a developer can be taxing, but so can the DBA. The developer who voluntarily transitions to the role of a DBA shifts focus from development and coding to the mundane things I mentioned before. In light of this, the DBA closely working with programmers creates the opportunity for the DBA to make creative contributions to any project, thus making the role of a DBA that much more interesting.
Being a developer and being drafted as a DBA
For most developers that see nothing but developing and coding for the rest of their life, this could be like choosing to be either in the reality show Survivor or the game show Wipeout. The new DBA spends their time interacting with that Black Box (known to us all simply as the database) they have contacted for data over the years.
The new DBA can now create their own tables and indexes. This could resemble letting a Japanese Hibachi cook into an Italian Restaurant. The cook can whip up anything, but must realize that there are new recipes, kitchen utensils, cutlery, meats, spices, vegetables, and host of other mundane things to adjust to (sanitation, inventory, start time, work hours, etc). This is not just a time of transition but also a time to overcome a great learning curve. A new level of experience has to be learned and developed despite expert Japanese cooking over the years. In this aspect, Developers must reeducate themselves to think like a DBA.
Training straight from college/trade School to become a DBA
This is, by far, the most lethal way to become a DBA. This is also the rarest path—in fact, this is virtually unheard of. Now we are talking letting someone from McDonald's or Burger King into that same Italian Restaurant.
Three learning curves are involved:
- Applying skills from college/trade School into the DBA role,
- Interacting with the particular RDBMS (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres), and,
- Interacting with Developers (a future DBA learning decent social skills straight out of school? Yea, right!).
In this, developers will have the upper hand over DBAs for years. DBAs must learn to adjust quickly to the needs of developers in their early years as a DBA. Perhaps a DBA could make a decent starting salary, but it is harder to grow without developing themselves in these three areas of learning.
Being a SysAdmin and making a segue to or pulling double duty as a DBA
As a former developer and now a DBA, one thing that must not be taken for granted is the role of the SysAdmin.
Having the role of SysAdmin/DBA is a little awe-inspiring to me. At my employer's hosting company, we have a guy who is a SysAdmin/DBA (SCMDBA). He is so swamped with infrastructure projects plus his own internal MySQL gigs. I do not envy him, I commend him. In honesty, since the true mind of a SysAdmin/DBA is foreign to me, I leave it to the discretion of SysAdmin/DBAs to update this paragraph (or completely replace it) to describe this path.
Conclusion
Regardless which path you choose, the role of a DBA can be distinguished or disgusting, depending on how willing you are to be mentored (or tortured) in the beginning, and how willing you are to work with other overs time. Only then can one say they enjoy being a DBA.
By the way, it just so happens I experienced the first two DBA paths starting from August 2004 at the age of 39. The two years of experience I had in the drafted DBA role made the transition to a full-time DBA very enjoyable and comfortable.
My advice to DBAs 28-29 years old? Be as good at working with people as you are with the RDBMS. If you grow in both areas, you can make it as a DBA for years to come.
Database Administration is difficult because of two reasons
Slow feedback If one makes a bad decision in the role of a software architect, it usually takes longer to get negative feedback compared to a programmer. The programmer can often become aware of the error during compilation or while running tests, which means that the learning cycle is quite fast. A database administrator making a mistake while designing a database might just get feedback when he/she discovers how the end-users will actually use the software. This means that it might take years to get the feedback that the database design was flawed and needs to be remade. Therefore, it takes years to gain experience, instead of minutes (sometimes) for programmers.
Expensive mistakes This is also the reason why CEOs of large companies are generally in their 50s.