I am old experienced enough to remember when production support meant I carried a pager. I have provided support in a variety of roles - software developer, database administrator, sales engineering, and customer support. I am thankful for the opportunities given to me through the years, for they have helped make me a better data professional.
I am also thankful they are behind me. I have no plans to go back to a life of production support. For me, production support was not an enjoyable part of any role.
In my experience, support was a constant stream of interruptions. I could not leave the house on a weekend for more than five minutes it seemed without being contacted about some process failing. In my time as a DBA providing support, whatever broke immediately became a database issue. I don't have exact statistics handy but it seems that 99% of the time it was not a database issue.
It was bad code. Well, bad coding practices, to be fair.
For example, one Saturday morning, I need to get to the hardwares store because the toilet needs fixing. And, as you know, when a toilet needs fixing, it tends to be a priority in your life. As I am leaving the driveway my phone rings. A data pipeline is broken, and I need to figure out what is wrong.
After some basic troubleshooting it turns out the process is failing when trying to insert data into a table. The developer insists that he has not made any changes, so it's likely an issue with the database server. Because database servers suddenly stop inserting data because...they get tired? I don't know.
A few more minutes of discussing the issue and the developer suddenly remembers how another member of their own team made a schema change to a table. And suddenly, this piece of code that uses SELECT * is now failing. Problem solved! Developer knows why the pipeline is broken, and knows how to fix. And now I get to attempt another trip to the hardware store like I'm bootlegging Coors from Texarkana.
Looking back I've developed empathy to these developers. Because they weren't developers. They were business analysts who knew just enough coding to be productive, but not enough coding best practices to be efficient. And no oversight to understand how a simple schema change will affect downstream pipelines. Or, perhaps understand the value of proper testing before deploying changes.
If you are currently providing production support and are frustrated I want you to know I've been there, too. And I also want you to know this:
It's not your fault.
But it is your responsibility.
Expect things to break, because the people making things are learning, same as you are learning. No matter how loud the voices get on the other end of the line, it's not your fault. They aren't angry with you, they are just angry in general and you happen to be in front of them at the moment. They are frustrated, same as you.
Do your best to stay calm. Calm is contagious. And have some empathy as you try to solve issues, together.
If I had done those things, I would likely have a different view of my time carrying that beeper.
But I'm still not going back.
Prime Sponsor
Look, choices can be hard. We get that. We see and hear it all the time when customers ask "should I buy DPA or SQL Sentry"?
At SolarWinds we decided the correct answer was "why not have both?"
So that's what we have done. Think of it as Thunderdome - Two products enter, one price leaves.
That's right, for one price you get access to both products. You can mix and match the products in your environment as you deem necessary.
If you haven't tried our products, there's no better time to get started.
Community Links
Scale your SQL Server MDF database data files
If you have ever tried to diagnose a possible disk issue with your database server, this is the post for you. David outlines one possible solution. I want to remind you that the underlying architecture matters, too. So, if you are running in AWS versus Azure, you will have different configuration considerations. But ultimately my point is this - your database engine knows nothing about real disk performance, only what it perceives to be a disk issue.
Storage for Azure SQL and SQL Server Engineers 101
Sticking with a storage theme this week, here's some great information about storage for Azure and SQL Server.
The critical role of Zero Trust in securing our world
You are going to be hearing more and more about Zero Trust in the next few years. Now is a good time to start understanding what Zero Trust means, and what steps you and your company can take to minimize your risk.
Events
The agenda for Live! 360 and SQL Server Live! has been released, you can review all the details here.
Live! 360 brings the IT, Developer, and Data communities together for six days of training, knowledge sharing, and networking. With unlimited access to Live! 360’s five co-located events, you and your team will get the training you need to keep you and your business competitive and future-ready.
If you like saving money, use the Alumni Promo Code ALUM8 when you register and save $800 off the 5-Day or 4-Day Standard Rate when you register by August 13.
Send any questions about the event to me at SQLRockstar@thomaslarock.com
Data Janitor Roundup
The DBA's Dilemma: How to Upskill and Stay Ahead
If you can’t, or won’t, upskill then you can expect to continue in your role until the role no longer exists. This is why you should constantly be thinking about what to do next—your next pivot. The pivots can be slight, but they need to be in the direction of opportunity.
Top programming language for data science: Python still rules, followed by SQL
I was a bit surprised to see R at only 10% of "always" being used, I would have thought it to be a higher percentage. I'm not certain it is fair to place SQL at second, since SQL is used by many database platforms. Data science is being done by Python and R, not by querying a database by itself. But still an interesting result and if you are interested in data science you should learn a basic knowledge of Python, R, and SQL.
More Data Doesn’t Make You More Digital
We are drowning in data and information, and the volume continues to grow with each passing day, week, month, and year. This results in our attention being at a premium. And the best way to grab and hold out attention is by getting a signal through the noise. To do that, you must understand what you need from your data, and stop collecting everything possible just because you can.
Why data storytelling in business matters more than ever - TechRepublic
Data storytelling should be one of the top skills for everyone, in any field or industry. If nothing else, some exposure to data storytelling will help more and more people understand how pie charts kill kittens.
Thank you for reading!
Thanks for reading! If a friend forwarded this to you, go here to sign up and receive this newsletter directly. If you're enjoying the newsletter, forward it to someone you think may enjoy it too!
Send links to me on Twitter at @SQLRockstar or email me some data or feedback at SQLRockstar@thomaslarock.com
Love you, mean it.
Datahug
This newsletter created with Curated.co
Sponsor an Issue
Reach thousands of data professionals who care about data, databases, and helping others make their data the best version possible. Get in touch right here.
Tweet of the Week