Voice of the DBA

Category: Editorial

  • Navigating the Database Landscape

    The title of our keynote session at the Redgate Summit in Atlanta is Navigating the Database Landscape, and I’ll be delivering part of the talk, along with Grant Fritchey and Kathi Kellenberger today, Mar 13. This is based on the State of Database Landscape Survey results, as well as our experience working with customers and implementing DevOps solutions over the last decade. The talk was mostly written by others, but as I rehearsed the session, I found myself wondering about how I’d approach my job if we returned to being a DBA or developer.

    When working in technology today, there are many challenges outside of actually learning about any of the particular products, languages, platforms, etc. We have the politics of working with others, ongoing work, emergency requests outside of channels, random questions asked by others, code reviews, and probably a few other things I’m forgetting, all outside of learning any new skills. While I consider myself a lifelong learner, I know that finding time (and energy) to acquire the basics of any new technology is challenging.

    At the same time, while working in any size estate, it seems that someone always wants to add a new tool, platform, language, service, or database to the environment. It’s great we have choices, but it seems like sometimes every technologist wants to just use something new rather than work within the areas we have experience. Early in my career, it was rare to find more than 1 or 2 database platforms in a company. Now we have lots, often seemingly just added because one person watched a talk or video and thinks it would solve all our problems in this particular instance.

    Working in an enterprise of any size likely means there are multiple database platforms in use. While you might only be in charge of 1 or 2 today, who knows when someone will call you as the “database expert” and expect you to configure Redis or troubleshoot ElasticSearch. I’ve had friends in this position, and I’ve had people come ask me to figure out MySQL, DB2, BTrieve, Lucerne, and more in my career. It’s a challenge, and it’s also stressful because I want to do a good job, even if I don’t know what I’m doing. Fortunately Internet search, contacts among friends, and more have helped me usually solve an issue.

    The modern database landscape is likely to be more complex than ever, and with the advent of cloud services, we find there are lots of options that anyone in an organization might choose to use in production, and then ask you to support them. Our jobs are increasingly complex, both from the depth of things we need to know about a database to the breadth of different products and services that might enter our realm of responsibility. Navigating all this is a challenge, but if you rise to the occasion, there can be a lot of rewards.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Republish: Have You Deployed an Availability Group?

    I’m taking a day off to coach at Colorado Crossroads today. It’s the last day of a 3 day volleyball tournament and I’ve got my 13s and I’m helping with 18s. Hopefully not at the same time.

    You get to re-read: Have You Deployed an Availability Group?

  • Is This a Good DBA Job Description?

    I saw this on one of the syndicated SQL Server Central blogs: Job Description of a DBA. This is mostly a list of things, but it covers a lot of the general types of things that many of us expect a DBA to do. However, my question is whether you think this is a good description for a job opening. Would you ask someone to fill this list of things?

    Maybe a better question is whether you could use this to evaluate candidates, and how would you go about asking questions or gauging a fit based on this. Perhaps you should ask yourself how you evaluate others and if there is a good way to rate them against a list of daily tasks.

    To be fair, I know most job descriptions often include many “desires” along with “needs.” That can be maddening to many job seekers, as they don’t feel qualified. What I’ve found when building descriptions is that a wider variety of people provide input for what they would like in an employee than just the hiring manager. The hiring manager might weigh these items differently and accept someone who doesn’t know replication well, even though replication is used if the candidate is skilled at query tuning. I would say expert, but how do you judge that? Most of us would probably settle for someone who can improve queries even just a little bit.

    When I interview people, I want to know a few things. One is can I get along with them, as well as the rest of the team. This isn’t to discount technical skills, but we need to be a team. If we can’t get along, and maybe more importantly, disagree civilly, it’s hard to work together. We do need to bond, though that doesn’t need to be over a drink or sporting event. However, we might need to share a meal, so I hope we can enjoy a conversation for an hour.

    The other thing is that I need to see some effort and desire to succeed. I don’t need someone to be an expert, but I do need them to show an interest in helping our customers, whoever they are. Part of that is trying; part of that is getting to the end result. I see far too many people that don’t try to solve problems or care that there is someone waiting on a solution. I also see too many people unwilling to try and improve the environment, whether that’s a codebase or server configuration.  They might be good at their jobs, but I like to associate with people who want to make the world better. People who think forward, who ask questions, who under-promise and over-deliver.

    I think the job description I linked above is a good one, fairly comprehensive in scope, but lacking in lots of details. The devil is often in the details, especially in how hard someone might work to complete these tasks, and if they would work to do so to meet their commitments, but also do so in a quality manner. And, of course, under pressure. Most of us know that things break, and when the thing is a database, a good DBA is invaluable in restoring service under pressure.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • Assistants in the Age of AI

    When I started working for a living, there were secretaries in many organizations. These were people who actually did a lot of correspondence (written or verbal) and busy work for managers or executives. Over time, as email and computers became commonplace on desks, I saw fewer of these positions. As more people started to send email, we had to actually alter software to allow assistants to impersonate their bosses and manage the volume of communications that many of us deal with.

    We’re in a new age of assistants with the emergence of Generative AIs powered by LLMs that can appear to respond in a conversational style to requests and perform actions on our behalf. In this new era, will AIs function as old-style secretaries, handling simple, but important tasks? Are they the trusted helpers that secretaries used to be for many executives? Are we all going to have an assistant, and do we want one, or need one?

    There was a post on the role of AIs in this new world, and their ability to not only be a cheap, reliable assistant for many of us, but also a powerful tool for those that still have personal assistants helping them manage their workload. However, it’s not a tool that takes the place of a secretary, for many reasons mentioned in the post. It’s just a tool that can help manage some work, but isn’t really intelligent, empathetic, or able to discern subtleties that come from the context of the humans involved in a situation.

    In many ways, that’s what I see for Copilot-like AIs used by technical people. They are assistants, and they can help with tasks, but with general, tedious, common tasks. They are a better search engine, and they can handle small tasks, but they aren’t replacing talented people, and they certainly don’t always understand enough of the context of a particular situation. If a general or common solution works, AIs are good, but in terms of being efficient and optimal when solving subtle, complex problems, we still need a human to guide the AI and assess whether the response is appropriate.

    I am both enamored by AI, but also very skeptical that the technology will do more than provide faster searching for information and light guidance of options. Perhaps I’ll be proven wrong, but I think that continuing to improve your own judgment while learning through experience will ensure that you not only are more valuable than an AI, but that you can use one effectively as a tool. A useful assistant, but one that you know to overrule when appropriate.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.