This month’s T-SQL Tuesday is hosted by the 2016 PASS Volunteer of the year, Malathi Mahadevan (b|t). Her topic is one that is central to succeed in a technology career – continued learning. As the technology world evolves at an ever-increasing pace, how do you keep up? How do you maintain your current skills, and continue to learn new ones? What are your learning goals for 2018?
This is especially timely for me. I recently took my first in-person training class in years, and loved it. The class was “Architecting on AWS“. With any class, not just a technology class, the quality of the instructor is paramount, and I was lucky to get a great instructor here. My current employer is looking to move some assets to the cloud (in the investigation phase) so the training was certainly applicable. I had been self-studying for about six weeks before the class, took the class, and after another week and a half, took the certification test. As of last night, I am an AWS Certified Solutions Architect – Associate. It is my first non-Microsoft certification. The landscape has changed since quite a bit since I earned my MCSE in Windows NT 4.0.
What do you want to learn? (specific skills and talents)
This is the hardest question to grapple with. This fall, between PASS Summit, Ignite, AWS ReInvent, and countless other conferences, it felt like new features and products were being announced every 30 seconds. I empathized with the dog from Up
I have been around long enough to know that many of these new features will never amount to much. Some of them will end up with widespread adoption, and some with have very specific use cases. The issue is that I do not have a crystal ball, and can not pick a specific feature. As such, I am looking at general trends, and what I find interesting. I have flirted with Data Science, and I do not enjoy learning that, and there is no specific use case at work that would lend itself to those skills.
I love data architecture. I can (and have) explained normal forms, data domains, proper data typing to people until I am blue in the face. Maybe because I was a structural engineer long before I was a DBA, I have a natural affinity for proper design.
But proper design, and proper data architecture, do not mean what they used to. NoSQL solutions have become pervasive, and it is almost impossible to be a well-rounded DBA without having at least a high-level understanding of these technologies. Vendors are promising magic pixie dust for some of these. I am pretty sure that CosmosDB can actually slice bread, and on the AWS certification test I just took, when in doubt the answer was DynamoDB. I have already worked on one project that involved a NoSQL implementation that failed, because it was not a proper use case.
My goal for 2018 is to learn these different database implementations, and more importantly, learn their proper use cases. I know that in one year, I will not be an expert in graph, document, and other types of databases, but I want to know how to set them up, use them, and scale them. And if I can not tell you when to use one type or another (in the real world, not for a certification exam), I will have fallen short.
How and when do you want to learn? (methods of learning and timeline on learning)
My recent experience with AWS training has reminded me that nothing beats proper, focused instruction by a good teacher. If I can get my employer to pay for another training class, I would love to. However, getting that budgeted along with having them pay for PASS Summit may be tricky.
If face-to-face training is not an option, then I need to learn on my own. Me and my kindle are close friends already, and we will be getting closer. Also, I will get a Pluralsight account. Even if my employer is not willing to pay for it, I am willing to invest in myself.
My learning path will be as such:
Pick a database type (ie, a document database, graph database, key-value pair database)
Learn what it is, structurally
Look at several implementations (MongoDB, Couchbase, Elasticsearch, etc)
Pick one of the implementations and do a deep dive on it, including creating simple applications that use it.
Write the equivalent of a white paper on when to use this type and database, and anti-patterns to determine when not to
Given time constraints and other priorities that may arise, I hope to this to be about a three month process for each type of data store. I would then work toward the end of the year to synthesize what I have learned to come up with a set of architectural rules and recommendations that can be used to help determine what kind of data store to use at the very beginning of a project.
One of the reasons that these technologies have emerged is their implementation by major cloud vendors, so I will have to become well versed in AWS and Azure as well.
How do you plan to improve on what you learned? (Putting it to use at work/blogging/speaking)
I would look for opportunities to use what I have learned to help make architecture recommendations to developers at work, as we go forward with new designs and implementations. As previously mentioned, we did have a failed NoSQL implementation already, so hopefully that can be avoided in the future. Even with an academic understanding of any technology, you never really know how to use it unless it is being used for a real project.
I would also offer to present at local UGs for each phase, and maybe have to guts to submit to a local SQL Saturday for the “final” set of architectural recommendations.