I decided to start a series of blogs where I interview key people in the SQL Server community. Instead of me asking technical questions, I plan on asking about their outlook on the future, books they read (non-fiction and/or technical), and their overall thoughts on where technology (mainly SQL Server) is headed. You can find more interviews here.
Mohammad: Do you think people who dismiss the cloud as a “fad” or just don’t take it serious enough to learn about it (i.e. Azure, AWS, etc), will be in a tough spot to find a job 5 years from now?
Andy: Yes and no. Do I see cloud adoption growing tremendously? Absolutely. Do I see it completely replacing on-prem infrastructure? No. As such, I don’t think one who chooses to dismiss the cloud will definitely be in a tough spot, but they may be more challenged.
Alternatively, because the role of the database professional is so broad and has numerous specializations, one could instead choose to focus on a different area that is less directly impacted by the cloud. For example, a T-SQL developer could get away with minimal exposure to the cloud. Is that ideal? No. But they could still get by.
Mohammad: Do you ever see the traditional SQL Server DBA role being replaced/eliminated?
Andy: Yes. But before you get your pitchfork and light your torch, hear me out.
First, what do you define as a “traditional DBA?” In my mind, that refers to a DBA who is the all encompassing owner of everything related to the database, and master of all. But as the footprint and capabilities of SQL Server grown and expanded, being master of everything SQL Server has become impossible.
To be effective, I argue that we must all specialize in some way. Today, it is impossible to maintain a high level of proficiency in the entire SQL Server stack.
When I think of a DBA today, I distinguish between Development DBAs and Operational DBAs, and even those are overly broad, generic titles. Some who think of the “traditional DBA” would say that it is synonymous with an Operational DBA, and I might agree. But that sheds light onto the other problem I see – these labels mean different things to different people, even DBAs themselves!
And that is why I believe the “traditional DBA” is dead.
Mohammad: What are you most proud of doing/accomplishing for the SQL Server community so far in your career?
Andy: I am most proud of my efforts to grow new community speakers. I started this effort in late 2016 with a T-SQL Tuesday challenge (https://sqlbek.wordpress.com/
This year, I am continuing that effort with a new professional development session of my own: Everybody Has a Story to Tell: Developing Your First Presentation. I debuted this session recently at SQL Saturday Nashville with great success and look forward to presenting it elsewhere throughout 2018. And I continue to actively mentor prospective speakers.
Mohammad: What non-technical/non-fiction book/s would you recommend? If you only read technical books…what do you recommend?
Andy: Truthfully, I rarely read books these days. I used to be a bookworm growing up and do kind of miss it, but it’s a huge time commitment. That’s not to say that I do not read at all. I read a lot.
My reading effort is spent on the internet. I read blogs, forums, industry news, and other websites. I consume much of this material using RSS feeds via Feedly (RIP Google Reader).
Mohammad: For someone who’s career focus has been on one aspect of SQL Server (i.e. Database Engine), do you think it would be wise for them to become a “jack of all trades” by starting to learn, SSRS/IS/Azure, etc. or remain focused on their area of expertise? In another words, which would you say is more valuable? mile wide / inch deep or inch wide / mile deep?
Andy: Well, I already kind of answered this when asked about a “traditional DBA.” I do not believe that a “jack of all trades” DBA is really possible. Who can learn (and master) SQL Server’s storage engine, T-SQL, SSIS, SSRS, SSAS, R, Python, Azure, etc.? Even the top names in our industry specialize. I classify myself as primarily a Development DBA with a focus on T-SQL development, performance tuning, and storage engine internals.
But just because you are specialized already, does not mean you must remain focused in that area of expertise. I didn’t. A few years ago, I felt like I hit a plateau in my database developer roles, so I made a conscious change to take a position as an Operational DBA. I brought a wide variety of skills to the table, but lacked other skills common to an operational role. For example, I had little hands on with HA/DR technologies. I’d never worked with FCIs, barely knew what an AG was, much less even understood clustering. Replication? Sure, I could click through a wizard? :-) But that new role challenged me to learn new skills and help me grow as a data professional. I look back and wouldn’t change that decision – it’s made me a better data professional as a whole.