Telling ain't training. That's the title of a useful book and the most important lesson I learned during my years of teaching and coaching.
While teaching mathematics at Washington State University, I could see that telling my students about compound interest was not enough, and assigning them homework just made a tedious subject more distasteful. Instead, I found the best way to engage them was by having them apply the concepts of compound interest.
So, I walked into the classroom one day and decided to deviate from the lesson plan by taking them through a typical credit card bill -- the balance, minimum payments, amount of interest paid and how long it would take to pay off the debt in full. This was long before the current laws requiring such information to be displayed on a bill. As we walked through the first example, you could see that applying the knowledge contained within their textbooks was opening a brand-new world of learning for them.
This brand new world of learning allowed the students to better grasp the subject material. But simply gaining the knowledge of some arbitrary mathematical formula only goes so far. If you want to help someone become adept at any subject, you must find a way for students to apply the knowledge and skills they are learning. They must actively put their hands (or minds) to work. That's when we go from telling to training.
Let's fast forward a bit. Since my days of teaching and coaching, I've been working with databases for the past 20 years, give or take a few grey hairs. Much of my database experience has been with Microsoft SQL Server, but I've worked with Oracle, Sybase and even Informix through the years. And just a few weeks ago, I took part in some MySQL training classes.
While I found many of the MySQL database topics familiar (backups, statistics, indexing and even some database design), I couldn't help but think about how I wasn't being trained as a MySQL DBA. I was being told about the role of a MySQL DBA. The information was good, but there's no way I could declare myself an adept MySQL DBA after a two-day class. I will need to put my hands on the command line and break a few things before I would dare to make that claim.
But one thing about the class and the material stood out to me more than the rest. As I listened to details regarding the common MySQL administration tasks, as I was told about performance troubleshooting tips and tricks, and as I learned about data recovery techniques, I realized this: The general concepts about storing data on disk are similar between all platforms.
It doesn't matter if you are running Linux, UNIX or Windows, or if you are using Microsoft SQL Server, Oracle, Sybase, DB2 or MySQL. They all have the same resource constraints -- memory, CPU, disk and network.
Like learning a different language, the names may change between database platforms, but the concepts do not. A disk wait for SQL Server might be labeled PAGEIOLATCH_EX whereas for Oracle it may be DB_SEQUENTIAL_READ, but both are suggesting the query is waiting for a page to be read from disk and into memory.
My years of experience allow for such knowledge and skills to transfer between platforms. With the right set of tools to help translate (much like a Rosetta Stone), a SQL Server DBA can step into the role as a MySQL DBA and be up to speed in a short timeframe. The same is true for many other IT specialties. The trick, of course, is finding the Rosetta Stone that will help you to apply your skills and experiences across platforms as often as necessary.
Having knowledge is good. Sharing knowledge is better. But applying knowledge and sometimes adapting it to other scenarios is the best way to train yourself when it comes to new technologies.