Voice of the DBA

Tag: career

  • Make It Routine

    The first one is hard. The rest are boring.

    I heard this statement from someone recently, and it sounds like something a technical person would do. It’s been a goal of mine, or maybe a direction to aim for, though I sometimes think that goal is more aspirational than actual. It can be hard to do that for every task.

    The first time I tackle something, it should be hard. It’s new work. It’s a new process/code/thought/action/etc. It’s unfamiliar, and I spend more time on it than I want. After that, I’d hope I could repeat the thing again in much less time. That’s the goal, and that’s what we aim for in a lot of DevOps work. Make the things we think are hard, less hard. Make them boring by codifying things, using automation, and have the computer replicate the task.

    I think the second one is often hard as well. How often have you tried to reproduce something you did and can’t quite get it? Heck, I now depend (and use) SQL History constantly because I will write some code, change it a bunch and then realize that I can’t reproduce the version that did thing thing (or broke the thing) I was working on. I need to rewind things and figure them out again. Usually by the 4th time I’ve done something, it’s starting to become easier. By the 10th its boring.

    Unless I’m playing guitar, in which case, some things take a few more reps than 10.

    I’ve had plenty of developers say never repeat yourself. If you can automate it, you should. In practice, that’s hard. Sometimes I’m unsure of whether I’ll do something again, or often enough to spend the time automating it. There are also times I’m not sure it’s worth the effort. I spent a day once trying to automate a bunch of Outlook appointments, only to realize the whole Office API and deluge of information out there made this much harder than the 15 minutes a year I spend putting in all my Database Weekly reminders.

    I don’t want to discourage you from automating things and making them routine or boring. My database deployments ought to be routine. The daily checks should be so boring and automated that I don’t bother with them because I know the machine is doing the work and will let me know if there is something I should examine. The efforts to refresh dev dbs, or respond to audit requests, or even reset a password ought to be boring and easy. Some of us build ways to smooth these tasks and ease our jobs, and some of us treat every one as an ad hoc thing that we do over and over.

    The stuff you do over and over is going to be handled by AI at some point (maybe soon). Maybe soon, maybe in a few years, but a lot of simple stuff that you keep doing- that mindless, tedious stuff that doesn’t require a lot of thought – is going to be handled by AI agents. Either you’ll direct them, or your boss will ask someone else to do it after you leave. AI can handle things like figuring out when disks are full and cleaning out old log files, shrinking databases, archiving things, and then writing scripts (and scheduling them) to prevent issues. If that’s your job, your days are numbered.

    Make things routine by thinking about the pattern, how we could reduce or eliminate a lot of labor, and how we can use a computer to handle them. Even better, learn how to guide an AI to do that work and prove your worth.

    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.

  • Un-Migrating From the Cloud: T-SQL Tuesday #199

    This month we have a very interesting invitation from Koen Verbeeck. He has hosted once before, and agreed to help me out this month by tackling another topic. We’ve shared a few beers in the EU, though not in some time, so I hopefully will get the chance to buy him a pint and thank him for this month’s invite.

    He was inspired by another friend, Alexander Avidsson, who wrote about skills and the cloud, but with an interesting take. This month’s invite is about moving back on-premises from the cloud, which is something I’ve had a few customers do, or start doing. Nothing is quick when migrating systems, either to or from the cloud.

    Here’s my take.

    How Easy Is It To Un-Migrate?

    I decided on a fun title here, since so many people talk about migrating to the cloud. Is going back on-premises an un-migration? Or a re-migration? Just a migration? I won’t worry about the semantics.

    I work with a lot of different customers at Redgate Software. Whether they are discussing development topics (Prompt/Toolbelt), deployment issues (Flyway), production stuff (Monitor) or compliance (all of the above + TDM), I find that most of them are still rooted in an on-premises mindset. Even when they’ve migrated to the cloud, it’s often lift-and-shift, with VMs running in AWS/Azure/GCP. In that sense, they still tend to manage things in an on-premises way.

    They’re more comfortable with those skills and more confused by cloud auth systems, still. In 2026.

    I think that’s still the norm and it’s easy to think that most people work in the cloud all the time. Some do, and I think most people have some familiarity with one of the major cloud systems, but I would expect that lots of people would love to come back on-premises.

    Is it easy? No. It’s another migration, and while you might find it easy to re-provision hardware (whether purchased or rented from another provider like Rackspace) there are still major data movement challenges in the db world. How do I sync systems? Can I get log backups? What type of quiescing and cutover is there?

    The tech stuff, matching versions, etc. is likely easy. After all, most of us don’t use the latest and greatest functions from SQL Server, so moving back to on-premises likely just works. If you are in the IaaS world, this is simple, other than the latency of copying data down (and explaining the egress charges).

    I actually think customers might gain some efficiencies from moving systems with known workloads and costs back on-premises. Especially those that create lots of tickets for DBAs or developers. Any time spent moving back will come back in the skills that so many have with on-premises systems.

    The one downside I think might cause some issues is HA. It’s easy in the cloud, and hard on-premises. Those are skills that some people likely need to brush up on if they don’t have a significant HA footprint with VMs.