Voice of the DBA

Author: way0utwest

Car Update: August 2026
It’s been some time since I provided a car update, so I decided to showcase a few things I’ve learned about my cars since the last one. In this post:
- A Second EV: Lucid Gravity
- Efficiency and Tires on the Tesla Model Y
- Serendipity with a Suburban
This is part of a series of thoughts on cars, just for fun. These are my thoughts and opinions based on my experiences.

Our Second EV: Lucid Gravity

We bought a Lucid Gravity after driving it one day. We’d driven a few other EVs and then stopped by the Lucid dealer because we had an hour and it was close. We weren’t expecting to be impressed by the car, but we were. In fact, we immediately stopped thinking of the other cars.

After a few hours of debating it, we bought one in the airport while waiting for a flight. It’s amazing to see how much easier it is to buy from Tesla and Lucid than other deals.

It’s the nicest car I’ve ever owned, and it’s an EV with great acceleration and handling. It’s also got a squashed steering wheel, which I am surprised I like. It’s easy to control and has a nice space to rest my wrists.

There are some weird things with software, and I have already learned how to “reset” the car. It took me a few minutes to get it right, which is weird. I have to press the brake and then press two buttons on the steering wheel. This didn’t fix the issue I was having with switching profiles, but it was an interesting experience to reboot the car.

One of the things I love is the cooled and massaging seats. I might get tired of this over time, but I have a bunch of different settings and there are a few I’ve enjoyed on our drives.

If you think about a Lucid, use my referral link. We’ll both get some credit.
Efficiency and Tires on the Tesla Model Y

In about 4 years of driving the Tesla Model Y, covering almost 60k miles, I had a long term efficiency of around 250Wh/mi. That’s just a bit below the rating for the car. I think I did very well, driving mostly at 45mph and lower in chill mode.

A friend sold me the spare 18” wheels from his Model 3 when he got rid of his car. I put them on mine, mostly because he had better tread than my summer tires. I didn’t think much of this until I checked the efficiency one day.

I was in the 205Wh/mi range with the smaller tires. Now, the software doesn’t have a setting for 18” tires on the MYLR, so I left it at the 19” stock tires, so possibly there is a calculation error, but I got > 10% efficiency improvement from changing wheels and tires. Smaller, lighter tires, but still. That’s crazy.

As we looked for new cars, I was aiming for the smallest tires I could get, both for replacement cost and efficiency.

Serendipity with a Suburban

In 2006, I bought a 2001 Chevy Suburban for $6500. The car had 101,000 miles on it and we were slightly nervous, but with a family of 5, we wanted a car that would carry all of us skiing and on trips. The AC died the next year, but that car has served the family driving all over CO, WY, and NM for many years. Each of my kids had driven it, one even banged into a concrete barrier in the snow.

I felt this was the best car investment we’d made over the years. I sold it in 2026 with 250,000 miles on it. We’ve basically done regular maintenance (oil, brakes, tires) and replaced minor parts across the roughly 150,000 miles we’ve owned it. The car was old, had rust on it, and in the hot CO summers, it was a car my wife used carrying the dogs from client to client.

She wanted something better.

I had been periodically looking for a good deal when I stumbled on a 2010 Suburban with 203,000 miles on it, It was a 3 owner car, no accidents, lots of records of service.

It was listed $6500 (I paid $6200).

I made my wife cut short work one Sat and we drove down to a dealer, getting there just before they closed. A bit of a test drive and we bought it that night. So far, about 8k miles in, it’s performed as well as the old one.

And it has AC.

Still feels like a good deal and a good choice. 20 years later, same price.
August 7, 2026
Are You Working More Hours?

Recently, I noticed my son was coming home later and going to work earlier. He typically works a 9/80 schedule as a software engineer, but at times he might work extra hours on a deadline. His company tries hard to keep employees working a set schedule without overtime. Unless there is a need, after all, this is software. However, when they are on a deadline, management warns people, and they try to manage overtime to reasonable levels to avoid burning out employees.

I asked him if he was extra busy or if AI was encouraging extra hours. He told me this was a short-term project with a few more hours, but mostly the team was decompressing a bit after work. I completely understood that as I’ve spent my share of time with co-workers at theend ofday, sometimes sharing a drink or meal nearby, sometimes just chatting in the office or the parking lot.

There have been a number of studies and reports that AI is making people work more, not less. The time spent on a variety of tasks, especially those where we are reading or interacting with text, has grown. I suspect there is additional pressure from management as well to get more done since everyone has an AI assistant around. There is also the excitement of tackling new projects, which can lead people to spend more time at work. While I appreciate that AI can be exciting, and you might love it, don’t lose yourself in it at work. It’s still just a tool.

And, of course, there’s the token spend. Some managers are measuring people on the amount of work their AI assistants do, rather than by what gets done. I’ve certainly seen plenty of people using AI to perform busy work just to be seen as using AI tools.

At times, it seems people are using AI to process more information, which they then use AI to summarize. They post these summaries, which grow in number because the AI can produce more of them. Others use their AIs to read these summaries and produce their own summary of what they should be reading. It certainly seems like AI is producing more copies of information, summarized over and over, giving all of us more things to keep an eye on.

That seems silly. While I like AI, I fall into that group that uses it lightly for targeted tasks. I certainly try not to create more reports, summaries, or even emails to send to others, especially large groups of people. We have enough to review without AI creating even more tasks to deal with every week.

Steve Jones

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

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

August 5, 2026
TRY_PARSE Limitations: #SQLNewBlogger
I got a notification from a question I’d posted at SQL Server Central: Getting the Average. A user had posted their repro didn’t work, with no real comment. As a SQLNewBlogger FYI, that type of post shows poor communication and a lack of communication. I see that a lot and it’s a challenge in the modern world.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

A Quick Setup

This was what the user posted:
```
declare @t table
(
    id int identity
  , i int
);

insert @t
select null;

insert @t
select 11;

select avg(try_parse(i as int))
from @t
group by id;
```
This does return an error, as you can see below.

Why?

Well, the TRY_PARSE() docs give part of an explanation. I highlighted this in Yellow, but the relevant text says “only for converting strings”.

Shouldn’t an int convert to a string? No, the precedence rules have int higher than char types. We convert lower to higher, not higher to lower.

SQLNewBlogger

I noticed something, thought for a second why this wouldn’t work, and then checked the docs. I decided to write this up and it was a 5-10 minute post for me. Easy to do and showcasing knowledge.

It helps me remember, might teach someone something, and gives an interviewer something to ask me. Add to your blog with short posts like this (or drop on LinkedIn).
August 5, 2026
Finding Bad Queries

T-SQL Tuesday #200 was in July, hosted by Brent Ozar, and it was a great topic: How do you recognize a bad query? In the age of AI, when lots of people will get queries written by others (people or AIs), how can you easily and quickly review code? Review is already a challenge in the software world, and I am sure it’s going to be even more challenging as people let machines author more database code.

Lots of you might hope that an AI agent will write better code than your average developer, but I don’t know if I’d count on that. There is a ton of poor query examples on the Internet and that’s where AI models are trained. You need some sort of feedback loop, good testing, and strong guidance if you want better query code. I think it’s as likely as not that AIs will produce poor queries just like humans.

Just faster.

How can you recognize poor queries? How do you judge if there are issues? Brent’s roundup shows what a number of people think, and there are some good “quick checks” to use to evaluate your code. The things that people wrote in their blog posts are the types of things that I’d want added to Flyway’s Code Analysis rules to catch problems before they get deployed to production. After all, anything that gets to production usually lives for 10 years (my rule of thumb).

Getting feedback early in the development process is critical. We know from over 50 years of software development that finding problems early is less expansive than finding them later. Whether we use humans or AI agents, we don’t want unnecessary time spent on simple bad code things that we know cause issues. Shift-left is still a challenge, even in the automated era of DevOps and guided AI agent skills. We need reliable, repeatable ways to analyze code and limit the downstream effects of poor quality.

Especially these days, where the volume of changes is overwhelming CI/CD systems. This was a problem already in organizations with too many teams in one codebase. It’s a growing problem in more organizations as users use AI and submit more changes.

Plus wasting time gets expensive. Human labor is slow and spending time on more tokens for rework gets expensive.

Don’t let bad queries flow through to CI/CD systems if you can avoid it. Learn to provide quick feedback early to whoever, or whatever, writes your SQL.

Steve Jones

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

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

August 3, 2026