Would You Retire Rather Than …

Posted on June 8, 2026 by way0utwest

Bjarne Stroustrup is the creator of C++. I read a few of his books and alternately loved what he’d done with the language 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.

The idea that senior developers, presumably like Mr. Stroustrup, would rather retire than work on codebases that are being changed by AI is interesting. I suspect that in some problem domains, you might hate AI code and not want to deal with it, but would you retire? Is that the answer?

I have known some IT people who retired because they didn’t like their jobs. My wife left tech because it was too stressful, but it wasn’t an easy decision. She’s questioned it a few times, but she had a passion for something else and wanted a new job. I think that in both cases, someone moved towards something rather than away from something. They had another thing they wanted to do in their lives.

I wonder how many of you would really retire or leave your job because you don’t like the work. Most people I know who don’t like the work are looking for something else to do until they retire. I would be sad to hear about someone who is hanging on to a bad job until they retire, especially if retirement isn’t coming soon (like the next 2-3 years). I would also hate to think that some people see AI as making their job so un-enjoyable that they decide to retire earlier than they expected.

I do have a good friend who was close to retiring in his early 60s. He decided it was too soon and took another job after his previous employer was sold and closed their local office. He’s spent a little over a year working remotely and he doesn’t like it. He’s going to retire this year because he doesn’t like the job and doesn’t want to look for a new one. He is close enough to retiring that he’s looking to the future doing less and finding a way to enjoy life without work.

AI might force some people out of the industry, but I think it’s more likely that there are other factors, like a poor work environment, bad management, or some other factor. However, if you disagree, let me know. If you would stop working because you don’t want to deal with data or technology, let me know. As always, if you don’t want to post publicly, message me and I’ll post something anonymously for you.

Steve Jones

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

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

Posted in Blog | Tagged | 2 Comments

Monday Monitor Tips: AI Alert Analysis

Posted on June 8, 2026 by way0utwest

We keep adding new AI capabilities to Redgate Monitor, where it makes sense. Check out this new feature we’ve added for alerts. This is a great addition to help a busy Ops staff cope with a large database estate.

This is part of a series of posts on Redgate Monitor. Click to see the other posts.

Alert Index Analysis

One of the new things we’ve added in Redgate Monitor is an AI analysis of your alerts. This isn’t for every alert. Right now, we have three where this works in preview:

  • Long-running query
  • blocking process
  • Deadlock

This is documented on its own page.

You can see this if you go to the Alerts page and look for a blocking process alert. Here’s a URL, but this repeats regularly, so just find the alert. You should see something like this:

2026-06_0115

If you click on the alert, then you’ll see the details, as shown here. However, to the right is an “AI Analyze Alert” button.

2026-06_0116

If you click that, a blade slides out from the right, and it has some analysis in it. This has a summary at the top. For my session, this had ended, so the summary is nice in that it gives me an overview with the time of the blocking and the statement. There is also a root cause analysis below this. This is something that would help me quickly answer questions from my boss.

2026-06_0117

Further down there is a diagnostic review, which helps you navigate Redgate Monitor to verify things. You should use the AI to help you and still verify what it says. This is a good explanation, but worth double checking. There are also recommended actions below this.

2026-06_0118

It’s a good way to approach a series of alerts, especially in a busy environment where you might have lots of these alerts across different systems.

Summary

AI is a great tool in places, and this is one of those measured approaches from Redgate to use AI where it’s helpful and useful, and does some work for you. Looking across a bunch of similar data and getting patterns, getting some quick insight into timings, that’s useful. This might be especially great when someone calls you with a question and you need a summary.

As always, you should verify the diagnosis and recommendations before you do something, but this does give you a quick place to start fixing chronic issues in your system. I look forward to AI analysis coming to other alerts.

Redgate Monitor is a world-class monitoring solution for your database estate. Download a trial today and see how it can help you manage your estate more efficiently.

Posted in Blog | Tagged , , , | Leave a comment

The Data Model Matters

Posted on June 5, 2026 by way0utwest

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.

At the same time, many people reading about these successes and trying to emulate them struggle. So many customers I know want to use containers, but struggle. Many teams lose control over serverless functions and stateless systems, having issues with immutable infrastructure. They revert, or often combine, older ways of building and deploying software with some of the techniques they read about.

If they struggle with stateless systems, it’s no wonder they struggle with the really, really important stateful ones: the databases.

Databases are state machines. We evolve and grow them. NoSQL systems were developed to try and deal with some of the scale issues with relational systems, but they often push the immediate problems of concurrency and efficiency to the side, invoking eventual consistency and redundant data models that keep multiple copies of data around for quick access. They also defer one of the strengths of relational systems, aggregating lots data, to another system, usually a data warehouse, data lake, or some other architecture.

That works great, though it comes at the cost of more compute, more latency to develop and produce those aggregations, and more cost to store all that data in yet another place. That’s not to disparage those designs. They work well and handle workloads most relational systems couldn’t manage.

However that brings to mind two things. One, perhaps that easy and instant aggregation isn’t as important as we think. After all, often companies at that size never have a view of all their data. It’s changing too often, yet they are successful. Secondly, if you don’t have the funding to manage that complexity (both in machine and human resources), perhaps you ought to focus on what is important in this age of cheap code changing often.

Build a strong data model and write efficient SQL Code.

Steve Jones

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

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

Posted in Editorial | Tagged | Leave a comment

A New Word: La Guadière

Posted on June 5, 2026 by way0utwest

la guadière – n. a glint of goodness you notice in something that you wouldn’t expect, which is often only detectable by sloshing them back and forth in your mind until everything dark and gray and common falls away, leaving something shining at the bottom of the pan – a rare element hidden deep in the bedrock, that must’ve washed there by a storm somewhere upstream.

It is easy at first glance when something sad, distasteful, or otherwise negative occurs to get upset or see a problem. When you think about it, sometimes you feel like there is something good. That blessing-in-disguise that is revealed after your initial reaction fades and you have a moment to consider the situation.

I have often felt that I react to something and think about the negative. That seems like a very human reaction. For example, a customer doesn’t want to spend time changing a process, even though it’s broken. I only think about the negative.

However, if you pause a moment and twist the situation from your view to someone else’s, then la guadiere comes out. A broken process, but a known one, isn’t the worst thing in the short term. It allows other work to get done, people are familiar, and it can be lower stress, even if it requires more effort.

The same thing if you have an issue. A flat tire, broken internet, a broken horse feeder. There’s some la guadiere in there. A flat might let me know my tires need replacing and they’re dangerous, or maybe I haven’t cleaned up around the garage properly. Internet teaches me to prepare more in advance (or take a break). Broken horse feeders let me catch up on some maintenance and maybe improve something before it gets much worse.

Find the good in life, even when it’s bad.

From the Dictionary of Obscure Sorrows

Posted in Blog | Tagged , | Leave a comment