Voice of the DBA

Category: Editorial

  • The Mythical Bus Accident

    What if I got hit by a bus?

    I’m sure many of you have heard some variation of this, or used it, or maybe your boss told you to be ready in case you (or someone more important) gets hit by that vehicle. This is the “bus factor,” and it’s often used in reference to preparation for unforeseen events. Not literally someone getting hit by a bus, but perhaps a sudden accident that takes someone away from work (hopefully not fatal). Perhaps it’s someone leaving for a new job. Maybe it’s retirement, which is something my boss and I at Redgate chat about periodically.

    Don’t worry, I’m not planning on retiring anytime soon. I expect to work until at least 2033 and possibly longer. Likely longer, I’m a weird work-a-holic in some ways, and I love my job.

    Recently, Rob Sewell wrote about a DR plan for his life, and specifically about his setup in case his wife needs to understand what’s running. I certainly don’t have the automation or complex computer setup he does. In fact, none of my computers really need to be running for anything on the ranch to function.

    However, there is a lot of important data.

    If you think about how embedded your life is with digital assets, you’ll realize quickly that if you were to get hit by the mythical bus, a lot of stuff might disappear. Most won’t matter, but your partner/spouse/children/parents might care about some. They might really care about a few items.

    There will be passwords to banks, the locations of photos, videos, and other memories. There will be documents you’ve kept on maintenance, or manuals on how something works, or maybe it’s just the various email (and social) accounts you have. You might not care, but the person behind you might feel the need, and want to, notify your friends and coworkers that you’re gone. Maybe your family wants to know how to keep your site alive (I still miss Tom and re-read his work occasionally).

    This isn’t to be morbid or worry you, but the planning you might undertake for your life is a lot like the planning that you should be doing at work for your job. Others should be able to take over for you (especially on vacations), and a guide to how you’ve solved problems, patched over issues, and built scripts that run rarely but reliably for some forgotten reason. Those items should be available to others. Certainly, your IT staff can give someone else access, but will those others know what to do with that access?

    I’ve documented a bunch of processes for SQL Server Central. Mostly so I can go on sabbatical and not worry, but also so that others can share the load. I’ve given away some of my work to others, I’ve been lucky to have others volunteer (volun-told) to help, and I realize as I write this, I likely need to update some docs. Not a fun task, but my buddy Claude can likely help me. And he will.

    Planning for the future is prudent, it’s respectful to others, and it’s a common courtesy. I used to think the future was a long way off, but as I age, I realize it’s closer than I think. Planning for the future is a good idea, and it’s something I need to ensure I update every so often, to help the others in my life.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • A Security and AI Fail

    The AI boom is still growing like crazy. Many organizations are trying to learn how they can use AI to improve operations and become more efficient at a reasonable cost. Plenty of companies are spending crazy amounts of AI tokens, sometimes blowing their yearly budgets in months and not necessarily receiving substantial value back. Some companies are trying to train AIs to understand their operations and perhaps reduce their other costs, primarily labor. Still others are tiptoeing in the waters of AI LLM use and conducting smaller experiments, with limited access to AI technology.

    Meta has been a company at the forefront of trying to train AI based on the work employees already perform. There has been plenty of concern that their efforts are designed to lower headcount and replace humans with AI agents. That might or might not work, though I don’t expect a lot of organizations to do this. It’s likely harder than any of the hype suggests, and most organizations have much more complex types of operations than Meta.

    However, in collecting this data, Meta has had other issues. Notably, they have had security problems with all the data they are trying to collect. Some of this data was exposed and they have paused the data collection for now. They were trying to move fast, likely cutting corners or not thinking things completely through. They created these issues. Hackers are constantly looking for holes and the quicker anyone moves to change their software and processes, the more likely that security holes slip by.

    Plus, data governance and protection is hard. Most developers really don’t think through data protection and security well. They’re focused on software and assume the data store (RDBMS, NoSQL, data lake, etc.) is handled by someone else.

    Data is hard. Especially at scale.

    While I’m sure most companies aren’t looking to track employees’ every move (which is a big uplift), they will be trying to move data around and use it for AI purposes. With RAG, with model training, with who knows how, but they are just as likely to cause a security incident if they are not careful.

    Think data governance and data security early. Develop patterns with DBAs and InfoSec alongside software engineers to ensure that as you stand up new agents, systems, and data stores, you aren’t asking for trouble. Re-using existing data is fine, but if you assume that your development team automatically knows about data security, you’re going to have issues. They likely don’t, and if you (or they) think they do, make them prove it.

    AI is amazing, but it’s also easy to mess up the data part of this. Everyone I deal with at Redgate Software is concerned about data governance, and more so all the time. For good reason. Meta made the headlines, but a lot of us aren’t better at securing our systems. We just aren’t as much of a media target.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Forward Deployed Engineers

    I recently recorded a session with Ken Muse and a Redgate Flyway Solution Engineer. It was a fun session using GitHub and AI, and better managing the code in an automated fashion to bring some determinism to AI coding. I’m hoping it will be released soon, and you can see a vision of how you can better wrangle your AI agents and reduce risk and increase reliability.

    When we started our discussion, Ken noted that he is an AI forward deployed engineer for GitHub. His job is to work with teams in how to use agentic coding. When we were first prepping, I had never heard the Forward Deployed Engineer title, which is apparently getting popular. It was in an issue of the Pragmatic Engineer Deep Dives last year, and I must have missed that issue. Apparently, this is a role that works part of the time with customer teams and part of the time with product or engineering teams.

    In other words, a software engineer with a new title who gets paid more than a software engineer.

    Titles are always a funny thing to me. I’ve seen people who write computer code go from programmers to developers to software engineers to forward deployed engineers. The job is the same. I work with a team of others who write code, or I work with a customer who wants code and might need help writing it. Or, if I’m working at a company that works with outside customers, this is really a consultant role renamed.

    DBAs have had a similar change. I started as a DBA because they made a lot of money at the time. I moved from programmer to DBA, without much change in skill, but with a nice pay rise at a new company. I left that role before we got Data Engineers, Site Reliability Engineers, Database Reliability Engineers, and who knows what else. However, if I had stayed in a company, I’m sure I would have been changing my title periodically to earn more money.

    Certainly, I’d still have been adding skills that give me a reason to change my title, but I’m not sure the job would have changed. Instead, I’d be trying to grow my career not only with seniority and time, but with new skills and title changes.

    Maybe that’s a good reason to keep learning new skills. New skills let you claim you need a new title. Hopefully, you pick a title that HR doesn’t have any data about, so they have to set a new range for the position that’s above your current range.

    Viola! Instant raise.

    Not a bad career plan. Just make sure you’re adding some skills that are asked for in job descriptions, including soft skills. After all, a forward deployed engineer is going to be working with others, so communication is going to be key.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • I Can’t Make You Learn

    Oh, how I wish I could make you learn. How I wish I could coach, guide, inspire, or even bribe you to learn more about your job, or things related to your job, or even things in life. I wish all of you would improve your skills, but more, I wish you would want to improve your skills. I find lots of people who do want to get better at things, but far too often, people aren’t trying to improve because they want to coast along at their jobs. Or really, anywhere.

    I get it. You’re stressed and busy at work, though hopefully not too often. You have challenges at home, kids to raise, parents getting older, financial stresses, concerns about politics or sports or exercise or diet or just about anything in the world. We all have things that take mental energy in our lives. How/why/when should I add another thing to the list?

    My view in the past has been that I invest in my knowledge and my skills because that helps me in the future. Whether that’s learning to write better T-SQL, or it’s learning a new thing about T-SQL, or it’s learning how to find information about the new thing in T-SQL. Or it’s something completely different. In the past, I’ve spent time learning to write better with a blog, knowing this might lead to a future job, but also to experiment and decide how much I liked writing. I’ve learned to organize presentations better, partially because I wanted to impress people at a user group, but also because I knew this skill would help me argue for a raise or communicate well in a job interview.

    I thought about this recently as a fan switch went out at the ranch. That’s not related to work, but I like to learn everywhere in my life. We have a whole house fan that cools the house at night. Someone else installed it years ago, but the switch stopped working. My wife wanted to call someone right away, as none of us are a) electricians, or b) have worked on a hard-wired fan. However, I thought this couldn’t be difficult. It’s worth a small experiment. I ordered a part that was vaguely familiar to the broken switch, not having much confidence that it would work.

    My son and I found the breaker (which was an adventure) and disabled it. We disassembled the switch, matched up wires, and replaced the switch. We turned on the breaker and were excited that the fan worked. We of course, had another adventure putting it back together, as the first time things didn’t work when we enabled the breaker, but we solved the issue. A couple of hours in total and $40 for a switch when it would have been easy to call someone and (likely) spend $150 or more.

    I always ask questions when work is being done. Whether that’s a tradesperson doing building or repair work, or a fellow tech professional writing code, or a fellow marketer authoring content. I want to learn to be self-sufficient and more capable. Even if there are things I’d really never do and happily pay someone to do them, I want to know how they are done.

    At the very least, I want to be able to judge future quality. That’s a skill I need with electricians and AI technology.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.