Change is inevitable for most of us. The jobs we hold, the places we work, the people we know, even our families grow and change over time. As I get older and live longer, I've learned to accept, appreciate, and flow with changes. I might resist, delay, embrace, or anticipate tomorrow, knowing there is always a positive and negative side to things.

This week, one of my colleagues retired. Annabel has been a part of Redgate nearly as long as I have, and we've worked together for many years. If you've ever attended a Redgate event, live or online, she likely had a part to play in the planning, organizing, execution, financing, and every other part of the process.

Read the rest of Changes, Happiness, and a Few Tears

For a while, I kept seeing that the cost of writing code was approaching zero. So many people felt that with an AI LLM, the costs would go way down to produce software. I'm not sure that's true. In fact, some companies are finding they spend more on AI tokens than salaries.

However, the ability to produce more code, experiment with ideas, or generate proof of concepts has gone up. Whether it's worth the cost or not depends on the engineer, but some organizations are finding that they can try more things than they would ever had time to try in the past. The time of engineers was the constraint, and if you can afford the cost, AI LLMs can relieve that time pressure.

Read the rest of Follow Your Hunch

Both as a DBA and developer, I've had plenty of immediate, this-is-broken, fix-it-quickly issues. Usually, I, or someone else, wrote some bad code and somehow got it deployed. I mean, I do test things, and I would (probably) never change code after I'd tested it to fix that one little annoying thing, like the formatting. I'd (almost) never do that, and I'm sure you wouldn't either.

Yet somehow bugs slip in at times.

Those are the acute issues, and they can be hard to fix at times, but often we can reproduce the problem in development and build a fix. Sometimes we even spot the issue quickly and just fix it in production. I'm sure you never do that, but I have had that experience myself a few times.

Read the rest of The Slow Growing Problems

Bjarne Stroustrup is the creator of C++. I read a few of his books and alternately loved what he'd done and hated having to write C++ code in university and at a few jobs. I found it tedious and hard, though arguably better than C once you had a decent set of classes structured. BTW, I love his website, the basic text view of the world, which is how I have built a few sites on my own.

I caught an interview with him and this short response on AI and coding. He had this quote: "Senior developers are already retiring rather than deal with it." He doesn't love the results from AI, which is fine. And it's not what I want to talk about today.

Read the rest of Would You Retire Rather Than ...

I ran across a statement that seems exciting to me as someone that has written a lot of code in their career. It said: "Many of the "modern" software practices of the last decade were early adaptations to this shift, even if we didn't articulate them that way. Immutable infrastructure. Stateless services. Containers. Blue-green deployments. Infrastructure as code. These ideas all share a common premise: never fix a running thing. Replace it."

These are a few sentences in this piece on the death and rebirth of programming. That's how a lot of software developers have viewed the world during the last decade and we've seen a lot of software advances in that time. The very successful developers and teams, who often speak at conferences and publish papers have adopted many of these practices. Serverless, containers, lots of tests allowing continuous deployment of new objects into complex environments that scale to levels many of us never thought possible. These are the very high performances talked about in the State of DevOps report every year.

Read the rest of The Data Model Matters

Lots of people move to the cloud; it's common. In fact, it's very common to hear customers who are being asked to migrate their workloads to a cloud vendor for a variety of reasons. You might not agree, but often there is some reason to move to the cloud. Sometimes it's even moving from one cloud to another, just because one of the big three (AWS, Azure, GCP) seems more attractive this year than the one from last year.

When you move, do you size your system for the peak? 80% of the peak? Perhaps there is another goal for which you design. Do you worry about ever being under-provisioned and letting customers have a slower system? Or do you ensure you never hit the peak, which increases costs?

Read the rest of Over or Under Provisioned

One of the things I used to emphasize in talks about DevOps is that no modern software of any significance is built by one person. Everything takes a team, so the foundation of version control becomes extremely important. We need a way to coordinate work across multiple individuals and communicate what changes are being made. This requires a strong foundation, and that starts with version control.

In 2026, that hasn't changed, but what has changed is the makeup of the team. No longer do I need a bunch of humans. In today's world, with extremely powerful AI LLMs, we can have a team of AI agents that write code, often at a pace far exceeding that of human teams. However, they still need to coordinate and communicate and ensure their changes mesh together.

Read the rest of The New Software Team

You still need DBAs (that know how to back up systems and test restores). If you think you don't, or if you manager does, then perhaps they ought to read this piece on how an AI agent deleted a production database. This wasn't the case of an agent just running around with sysadmin access to all resources, or a lack of tests that allowed bad code to flow through a CI/CD process.

This was a system design that had a hole in it. An API call to change infrastructure that could change both staging and production. Not something an AI set up, but humans did. A hole from both PocketOS and the API vendor that allowed the AI agent to make the same type of mistake we've seen humans make. A mistake of not double checking, not verifying, not following the rules of getting a second set of eyes, even a second set of virtual eyes, on the code that could drop resources.

Read the rest of Limit the Blast Radius

I wonder how many of you have tried vibe coding something with an AI tool. If you haven't, I certainly recommend it. I've been a bit amazed with a few of my AI Experiments, including my loading of a lot of inconsistently formatted data into a database for USD$5.

To be clear, there's plenty of vibe coding that might not be production-ready, but have you ever been handed code from a human developer you didn't think was production-ready? Or deployed code like that? Certainly, AI could exacerbate the situation, but it can also spark ideas, ease (and speed) development in small ways, and tackle the backlog of things your org needs.

Especially small tools.

Read the rest of What Can AI Really Do?

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.

Read the rest of There's Too Much to Learn