Voice of the DBA

Tag: software development

  • Choose the Second One

    I wonder if any of you have ever tried this. When faced with a problem, think of a solution using whatever comes to mind. For most of us in the data space, this is a SQL-based solution, hopefully a set-based on for MSSQL. For Oracle, you might approach things differently. In any case, solve the problem.

    Then force yourself to imagine that you weren’t allowed to implement the first idea for some reason. No funding, no time, whatever the reason, you can’t implement it. Maybe it’s your team hates your ideas and just won’t approve the PR.

    Now, come up with a second idea. Something new and different. This might be harder in the data space with SQL than in application programming (C#, Java, etc.), but the idea is expressed in A Philosophy of Software Design by John Ousterhout. It’s how he has often taught his software design course at Stanford. His approach is to force students to think more deeply about their design, and he often finds that they build a better system the second time.

    Hard to do, but arguably a good idea. He talks about this in this podcast with the Pragmatic Engineer, and how many smart people underperform when building their software. He says it doesn’t necessarily take more time to do this twice, which I am skeptical of. This might be easier for students, but in the real world, is it even practical? Often we’re not working on very hard problems; we’re working to implement something that needs to get done, and often isn’t that well-defined. In fact, many of the things I find developers are asked to build things that either aren’t well thought through or are relatively trivial. There might not be a good second solution for a lot of vague ideas whose value is unclear.

    I do think that often we go down a path that quickly becomes complex. Engineers will start to overcomplicate things, so perhaps slowing down, spending a short period of time thinking of a second solution, debating another approach with others is worth a little time. Maybe you wouldn’t implement it, but at least think it through and game out the approach with pseudocode.

    I haven’t run into anyone who approaches software this way on a regular basis, but if you do it, let me know. If you think it’s a good idea, maybe it’s worth trying at the beginning of the next sprint when you tackle a new design requirement.

    Steve Jones

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

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

  • Make It Routine

    The first one is hard. The rest are boring.

    I hear this statement from someone recently, and it sounds like something a technical person would do with a task. It’s often been a goal of mine, or maybe a direction to aim, that I want to make things easier with some script or automation. Sometimes I think it’s more aspirational than actual. I might want to make most things routine and automated, but that doesn’t always work out.

    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, have the computer replicate the things.

    I think the second time I tackle a task 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 the 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 over and over stuff is going to be taken over by AI. 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 disks are full and cleaning out old log files, shrinking disks, 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 to your employer.

    Steve Jones

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

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

  • Day of Data Baton Rouge Slides and Code

    Thanks to everyone for attending my talk today at Day of data Baton Rouge 2026 (formerly SQL Saturday Baton Rouge).

    The slides are here: Building an API with DAB – Baton Rouge

    The repo for the code and demos is here: DAB-Experiments

    Use the Getting Started folder for the setup and demos as batch files. This is for SQL Server with a user set as JoeUser. Change this in the .env file if you want to alter this. I use Northwind, with a few additions in the .sql files.

    Apologies, it’s not completely organized as I am still working on the flow and structure. feel free to reach out with questions.

  • Using AI for Git Hooks

    Recently I had someone internally ask about whether SQL Source Control supports Git Hooks. Since it was after UK work hours, I decided to run a quick test. One problem, I haven’t setup a Git hook in a few years.

    Could AI help me? See what I did.

    This is part of a series of experiments with AI systems.

    Asking for Help

    Claude is my go-to AI. I don’t have a good reason why I don’t lean on Copilot or ChatGPT or anything else, but I’ve become more comfortable with how Claude works and responds to me. When I have something that doesn’t have any PII or other sensitive requests, I tend to start with the free Claude site.

    Here was my prompt: what is an example of a git precommit hook

    Simple, easy, no punctuation or big setup. I just needed something. I got some code:

    2026-01_0150

    and an explanation. Here’s the’s the text of the explanation (italics from me):

    This hook:

    1. Prevents commits with console.log statements

    2. Catches trailing whitespace

    3. Runs your linter

    To set it up, save this as .git/hooks/pre-commit and make it executable with chmod +x .git/hooks/pre-commit.

    If the hook exits with a non-zero status (like exit 1), the commit is aborted. You can bypass hooks temporarily with git commit --no-verify if needed.

    Many teams use tools like Husky to manage hooks in a project, making them easier to share across the team since .git/hooks isn’t version-controlled by default.

    This shows some bash, which I don’t think runs natively in Windows. That makes sense as a lot of coders are likely using Linux/MacOS for complex stuff and the default training for Claude likely assumes that. I asked about Windows and got two options: Node.js and Husky. Since I don’t like to install things, I went with Node. Here’s the next question I asked.

    2026-01_0151

    I didn’t want to lint or worry about whitespace, since I’m depending on SQL Source Control to create the files, so I asked a different question: can you create a pre-commit hook using node (for Windows) that checks for a commit message between 1 and 50 characters?

    The response is good. I didn’t want this, and reading this, I realize Claude is right. I wasn’t quite thinking through the process here. I also didn’t want the code for a commit-msg hook, so I ignored the code.

    2026-01_0152

    I could see that I was getting generic hooks, mostly for other code, so I rephrased a prompt: I want a sample pre-commit hook for .sql files to test something, what is a good example

    The response was a practical hook for SQL files. The code had a couple of messages printing our errors when I failed things, and the code here isn’t important, but here was the explanation. The bottom of the code is shown, and then the list of things that are checked.

    2026-01_0153

    At the top there is a comment about the hook, and since I’d done this a few years ago, I thought I know what to do, but I asked. I mean, why not ask the AI for more help? I liked that it noted not only do I need to add this to my .git folder, but I need to track this if I want to share it. That’s important. I do want other team member, or in this case, me on another machine, to have this hook.

    2026-01_0154

    Testing the Hook

    I then went to SQL Source Control and made a change. In this case, I added a file that I knew would fail the check. Here’s my code:

    ALTER PROCEDURE dbo.GetAllCustomers
    
AS
    
SELECT * FROM dbo.customer

    I could see this code change in the SQL Source Control GUI, but no error. I thought this might be staged, and I somewhat assumed the hook would fire on staging, so I asked.

    My new prompt: when does this hook fire?

    The response let me know that I had to commit this to get the hook to fire. It runs on the commit command, as before the commit succeeds. That’s good to know. Thanks, Claude, for helping me learn something.

    2026-01_0157

    In checking from the CLI, I realized that SQL Source Control at this point hasn’t staged the file. It also hasn’t written the file, so there’s nothing to stage. One of the downsides (one fo the few) of SQL Source Control is very limited git configuration. The write, stage, and commit happen at once.

    I tested this and sure enough, I got a failure when I tried to commit. The hook fired and saw my SELECT *, and my lack of a semi-colon.

    2026-01_0146

    I tested this further by fixing these elements individually, and I could correct the SELECT *, but I couldn’t fix the semi-colon. I realized with testing that when SQL Source Control writes the file, it always includes a “GO” at the end. So my hook doesn’t work.

    Asking for Modification

    I decided to see if Claude would fix this, as I wasn’t sure what to change myself. I’m not a Node nor RegEx person, and I’d be googling a bunch to figure this out (or find someone else’s code). Instead I tried this: can you adjust this hook to ignore the missing semi-colon if the file ends with a GO, or check for a semi-colon before the GO

    The response was interesting. The explanation said this:

    Now it handles both cases:

    • File ends with GO: Checks that the line before GO has a semicolon

    • File doesn’t end with GO: Checks that the last line has a semicolon

    The relevant code is here:

    2026-01_0158

    I can read this and it makes some sense, but I would have struggled a bit to get this done in a reasonable time. Instead, it was seconds for Claude to produce this.

    When I re-tested, this passed the SQL Source Control GUI and I had a working git hook looking for a couple of simple silly mistakes I might code.

    Summary

    This is an area that I have a little experience, but not a lot. I’m a junior dev when it comes to Git, and Claude is definitely more skilled. However, I have to know what to ask to get a result and I thought the answers and explanations were good in helping me setup this test in a few minutes rather than the better part of an hour (or longer) if I were searching and trying to assemble code.

    This is one of those areas where AI was very useful to me. It built a fairly trivial coding item I needed, it helped explain things when I had questions, and it was helpful in adjusting code quickly when I realized I needed something else.

    Imagine asking a colleague this, realizing you’d asked the wrong thing, and then asking them again for new code. How slow, and annoying, would this be for both of you? AI is a game changer here, for things that are too simple to work with a colleague on, yet complex enough that you’d waste a decent chunk of time googling.

    That time savings went into me testing the code and testing SQL Source Control. I verified that SQL Source Control can work with git hooks in minutes.