Voice of the DBA

Category: Editorial

  • Republish: Writing Before Reading

    I’m still in Europe, now in Rome. I’m sure it’s amazing, but while I’m gone, you get Writing Before Reading. I don’t see this in the archive, so here it is in total:

    Writing Before Reading

    This editorial was originally published on May 21, 2020. It is being republished as Steve is gone this week. Have your thoughts changed on reading and writing code?

    Coding is one of the few (or maybe only) places where we learn to write a language before we learn to read it. Many of us get started in some way by working through exercises, looking at very small snippets of code and then starting to write our own. Perhaps that’s because we experiment by changing the behavior of the computer, which naturally takes some writing work on our part.

    Perhaps we can do better, and should to better. Perhaps we would become less susceptible to the Not Invented Here (NIH) stance that so many developers seem to take. Not with major projects, but often with small sections of code or libraries, preferring to structure something new than re-used (and take the time to understand) what’s already there.

    This isn’t to imply that most developers need to write their own code or don’t work to understand others, but often they prefer to rebuild something in a way that is more familiar. It’s a form of the Mere-exposure effect, and it sometimes leads developers to prefer certain patterns, tools, platforms, and more. Perhaps it’s the opposite of the shiny ball syndrome, which leads people to chase the newest thing available in their area.

    I know there are plenty of developers that copy and paste code from the Internet as well, which might seem to be a way of getting around NIH syndrome, but I think many people do this when they find code that solves a problem. Even if they don’t understand how it works, they’ll seek to reapply that same code to a new problem.

    I do think reading code is hard. In some sense, it sucks. I’d often prefer to understand the basic inputs and outputs, perhaps rewriting the code to work in a way that’s more comfortable for me to understand. Maybe I better understand my own code, maybe I’m falling victim to the IKEA effect (I’d rather depend on my own software than someone else’s), or maybe I’m just being lazy.

    There are plenty of articles on how to read other people’s code, and I am trying to get better at this. I do try to debug and reason out how queries are written that solve problems in the forums. I may break apart queries and try to understand how someone has used a window function or a CROSS APPLY in a certain way. It helps build my skills, but it also helps me learn to better read other people’s code and perhaps carry that skill into the future.

    Steve Jones

  • Republish: Other IDEs

    I was very lucky, and honored, this year to be picked as a part of the Redgate President’s Club. This is our sales award club, which primarily goes to reps, but sales engineers and others are picked. I was one of the wild cards, as I helped on a lot of deals last year, so today I’m in Cambridge meeting with product people and execs.

    While I’m over there, you get to re-read Other IDEs. Leave a comment and let me know if things have changed since I first wrote that. Are you using another IDE?

  • The New Wave of Security Threats

    We’ve had quite a few GDR patches for SQL Server released this year. If I glance at the Build Lists I maintain, I see Sept 2025, Nov 2025, Jan 2026, and Mar 2026 GDR patches. That seems rather frequent as the history of builds for recent versions has often seen them without any GDR, out-of-band patches. Just CU after CU every other month.

    That pattern of rare security updates might be changing for lots of software, not just SQL Server. There was an article recently that noted AI tools might start exposing lots of bugs, including security holes, in software that has been around for years. Someone recently used AI found bugs in both PostgreSQL and MariaDB that have been around for years. They are patched, so if you run those platforms, make sure you patch things. The information is out there and someone is looking to take advantage of it.

    Anthropic built a new model, Mythos, which has not been released publicly. It’s been given to a few customers who have used it in testing, and it seems that it might be more capable than expected at finding bugs. Hopefully, we will find out how good it is soon and lots of companies can use it to examine software. It’s certainly a danger as hackers and criminals might use it, but I believe that (responsible) information disclosure is better for everyone.

    This is also a good reminder that you need to patch your systems. I certainly get wary about updating on day 1, but I do try to patch without too much of a lag. There are no shortage of zero-day attacks, but I also weigh the risk of instability from patches of questionable quality. Many vendors do a great job of patches and upgrades most of the time, but “many” and “most” aren’t “all”, so I prefer to let others test early. Someone has to apply the patches on day 1, but I don’t want it to be me.

    Security is getting harder, it’s getting more burdensome, and it’s becoming more important. At the same time, lots of people are building better security with new tools, including AI. Just make sure you apply those patches to take advantage of their work.

    Steve Jones

  • There’s Too Much to Learn

    I remember getting started on SQL Server and trying to upskill myself in the mid-1990s. At that time, my employer was running a SQL Server 4.2 instance for a third-party application, but we wanted to rewrite our internal bespoke sales app to run on SQL Server. We were upgrading from Foxpro to Visual Foxpro and looking to move from shared dbf files to a SQL Server. There was a new release of SQL Server 6.5 during our development, and I wanted to learn more about it. I purchased Inside SQL Server 6.5 and read the entire thing, getting prepared to finish development and then manage a new platform in production.

    I had updated copies of that book as SQL Server released new versions until SQL Server 2005. When that came out, there weren’t one, but rather 4 books to cover the Inside SQL Server details (Programming, Query Tuning, T-SQL, and The Storage Engine). A similar thing happened with the SQL Server Bible, which grew in size to over 1400 pages for the 2012 version. It was a backache in a book if you put it in with your laptop.

    Since then, the growth of the Microsoft Data Platform, which includes SQL Server, has been incredible with lots of changes not only to the box/on-premises product many of us install, but to the related systems in Azure. The SQL variants, Fabric, Power BI, Azure Data Factor, and more. It feels like there is way too much to learn  I know I can’t keep up, and I expect most people feel the same way.

    Coping with the load and the accompanying imposter syndrome is hard. It’s hard on your psyche and it’s hard when others in your organization, especially your boss, expect you to understand how to work with T-SQL, even when they might refer to SQL Server in one request and SQL Database in Fabric in another. They might even expect that you know “everything database-related”, including how to troubleshoot their Azure PostgreSQL Flex server performance issue.

    AI can help, as can some strong Google skills and an eye that spots the information you need. Whether to do actual work or help guide an AI LLM along a path. I would argue that improving your ability to differentiate what’s better from what’s worse is becoming even more important in the age of vibe coding. Even if you aren’t a YOLO, let-Claude-Code-do-it’s-thing, others are and they’ll call you when they don’t get the results they want.

    Or when their system performs poorly against your database system. Who knows how many implicit conversion issues or RBAR pieces of code an LLM will write. There’s a lot of that sample code out on the Internet, and much of that code goes into training these models.

    I don’t have a magic solution for keeping up, other than build the habit of learning. Practice new techniques, play with code, conduct experiments in the things that plague your environment, or that you see others working with. I don’t mess with Hyperscale much as I don’t see it with customers, but I do see other technologies, like System-versioned tables. So I spend time there, learning what works well and what doesn’t. Those are the skills that help me keep up with the knowledge I need to work with LLMs and humans.

    Steve Jones

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

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