A New Word: Immerensis

immerensis – n.  the maddening inability to understand the reasons why someone loves you – almost as if you’re selling them a used car that you know has a ton of problems and requires daily tinkering just to get it to run normally, but no matter how much you try to warn them, they seem all the more eager to hop behind the wheel and see where this puppy can go.

Most people likely go through this, unless they are very self-centered and narcissistic. Come to think of it, maybe “most” is the wrong description. I find too many people being self-centered already.

In any case, I think lots of us wonder why someone really loves us, especially early in our relationships. We have some self-doubt, we always want to make a great impression on our dates/partners, avoiding showing them the “crazy” inside of us. I know lots of woman who avoid being seen without makeup. I know men who want to be sure they are showered and clean, avoiding having a date see them at the gym.

I think it’s natural as you get closer to someone, as you let yourself be vulnerable to have some fear. Hopefully it’s not the maddening inability of immerensis, but just a manageable “I wonder if they’d like the whole me.”

You should let them in. If they don’t want all of you, they don’t deserve you.

From the Dictionary of Obscure Sorrows

Posted in Blog | Tagged , | Comments Off on A New Word: Immerensis

Database First or Application First

One of the challenges in software development is coordinating database and application changes when one depends on the other. I find many software development teams struggle with this, especially in today’s environments when no one wants to take a system offline. While some companies can stage and manage deployments, many of us find our systems need to keep running 24×7 with minimal outages (if any).

Lots of you work in environments where your software is changing on a regular basis. Plenty of you will either be developing those changes, or managing the systems to which those changes are deployed. You likely will be coordinating with other people (in either case) to deploy a software artifact (C#, Java, Python, etc.) and a set of database changes in order for your clients to use whatever new functionality is being delivered.

My question today is do you deploy database changes first or application changes first. Certainly you can deploy both on the same day or in the same pipeline. However, even if you use parallel pipelines, likely one side will finish first, and you likely have some preferred order for deployments. My question today is what order do you prefer (or is mandated to you).

Maybe you don’t care. After all, with modern coding and feature flags, you can deploy either side first (front end or back end) and not disturb your clients. I’ve seen many successful deployments from organizations both ways. Some like letting application developers deploy their code with expected database changes hidden behind flags. Others want the database to get patched and the software changed later to use the database changes.

Lots of people want everything deployed at once, but if you assume that is the case, I hope you have downtime scheduled, as you can’t usually get everything deployed simultaneously.

I tend to prefer database first, with dark deployed changes that don’t affect the front end. Of course the front end needs to support these dark deployed changes, but that’s easy by just following good coding practices, which aren’t that hard.

Let me know today what you prefer and why. Or if you don’t care and can deploy in either order.

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 | Comments Off on Database First or Application First

How Much AI Code Would You Use?

I saw an article recently that a quarter of the Y Combinator startups have 95% of the code in their repos being AI generated. The article notes that if no other startups had any AI generated code (no idea the likelihood here, then about 24% of their code for startups is GenAI written.

24%

Is that high or low? If you think about all the code you’ve written in the last year, how much of it could be reasonably generated by AI? All the queries, schema changes, test code, dummy data insertions, refactoring to add a column to a table or result set. Could it be AI written?

Let’s assume you practice a bit and you could quickly get some table, view, and sproc code. If I were to ask an AI to add a date column to a table and adjust the view and sproc code, is that useful? If I can move on to another task, or start setting up a prompt to add some test queries (or tsqlt tests) for me, that might make me more efficient. Certainly I’d still have to think of how to model this, but could the AI save time?

There is a lot of code that AIs might not write well. Certainly any dynamic SQL stuff that might be susceptible to SQL Injection worries me. An AI might write this, but so can a human. If the human doesn’t understand this issue, then it doesn’t matter if the AI writes it or the human does.

Except the human can make more mistakes in a period of time with an AI helper than by themselves. At least, I think they will unless they just can copy/paste/search/replace the code themselves. Then maybe they can do the same level of damage to a codebase.

The article has this great quote: “… even if product builders rely heavily on AI, one skill they would have to be good at is reading the code and finding bugs.” That is very true, and it needs to be said to every manager, project leader, and executive. You still need trained, skilled, experienced developers.

This might be even more true for DBAs and ops people using AI to help them write scripts to change infrastructure. Plenty of people do this poorly now, but how many more quick scripts written by an AI will include unintended, insecure, or otherwise problematic code? People need to use the AI as a tool and review the output before using it.

So how much help could you get from an AI in your coding? 24%? 95% Let us know today.

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 | 2 Comments

Back in the UK

I flew overnight and am in the UK this week. It’s a time for me to get into the office and get some facetime with various other Redgaters while I’m over. I usually go a couple of times a year to the office and spend time with co-workers, which I find valuable to build bonds and relationships.

I was chatting with a friend recently who is remote. Most of his data team is remote, but there is a main office in another city. They are debating Return-To-Office guidelines, and they’ve required any new hires to be in the other city.

That’s a concern to this person, and others. Should he consider moving or look for a new job? Is there a lack of growth in this position if RTO becomes mandated. In this case, this person would rather have a remote team that gets together once a year.

Interesting idea, and I’ve seen this in the past when different positions when there were remote teams. It can be expensive, but it can be an investment. I’ll need to think about this and maybe write a piece.

Not much blogging this week, as it’s been a busy time, so I’ll be back next Monday with a set of more regular posts.

Posted in Blog | Tagged , | Comments Off on Back in the UK