I’m off to Las Vegas for a volleyball tournament today. Fingers crossed we have a good weekend, and the team has a good experience. These tournaments can be stressful and tough with teams from all over the country.
They can also be exciting when we win a few matches.
While I’m gone, you get to re-read A Double Failure.
SQL Server Central has been a great success over the last 25 years. We’ve helped a lot of people improve their careers with the Microsoft Data Platform, primarily SQL Server, but we’ve published articles on other aspects of databases, including other platforms. I wrote a bit about the history of the site last month, with a few stories in various pieces. We even got Brian Knight to contribute a piece on what the site meant to him.
Over the years, we experimented with trying to get an SSIS Central or a SSRS Central off the ground. However, we struggled to find other people who would have been willing to partner with us to provide content and answer questions. Eventually, we gave up, though I wish today we’d have pushed forward with a PostgreSQL Central site a few years back.
However, we’re moving forward with AI Database Central next week. This is an experiment that will look to gather lots of articles and news on how AI technology can be used to work with databases. Our goal is to build a site that showcases some of the ways in which AI works well. To handle the load of producing articles, we’ve got a very modern take.
We’re setting up a Clawdbot system that will read existing articles and questions and then produce its own articles based on the knowledge of what AIs have about database technology. For every article here on SQL Server, we’ll get a series of articles that cover the same topic on Oracle, MySQL, PostgreSQL, and MongoDB to start. We’ll turn the AI agents loose on more platforms over time, but our hope is that this will provide an exhaustive body of knowledge that other data professionals and AI agents can use. We’ll even have an MCP server available.
Of course, we will take submissions, which AI agents will edit and provide feedback. We’re also looking to experiment with submissions of editorial topics and ideas, which the AI agent will then use to produce its own content for you to read.
This will likely not work that well, mostly because it’s April 1 and this is an April Fools joke. It could be possible, couldn’t it? Not likely very good, but it could be fun.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
One of the challenges of AI-assisted coding agents is that they tend to produce A LOT of code. Even in refactoring or migration changes, the AIs can work quickly and generate such a volume of code that the process starts to become overwhelming. For pull requests, for CI/CD build systems, and certainly for human reviewers, they can be overwhelmed. This can become a real problem with OSS projects, where submissions can grow exponentially to the point that maintainers stop looking at pull requests. I suspect the same thing might happen in corporate repositories when lots of developers can refactor or submit huge amounts of code produced by AI agents in a fraction of the time it took a year ago.
I was listening to an interview with an experienced software developer and OSS project maintainer who said that he preferred getting a “prompt request” that contained a description of a problem and the specification for a solution that he could submit to his own LLM to get the code. Rather than use an AI to review a code in a PR written by a human or AI agent, a great prompt that can communicates the problem and solution is preferred.
That’s a fascinating idea to me. Specify what you want and let the code owners send it to an AI and get a code response whose quality and focus they can decide to implement, based on their own context provided to an LLM (standards, style, patterns, etc.)
Of course, for open source projects, perhaps the maintainer doesn’t want to spend time managing AI agents or working through quality, but this does allow them to focus on the idea being suggested rather than attempting to review code, test it, judge the quality, and perhaps request changes from the submitter. They can take your idea and implement it. If it’s a simple fix, even better, as the maintainer might get quick help from an AI, using the style of code they are used to (their own).
Software engineering is changing a lot in the age of AI, and this seems to be one of the more interesting things I’ve seen suggested. Not YOLO or vibe-coding, but rather a prompt that suggests the idea and turns contributors into a specification written for the robot coder.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
We do a lot of research at Redgate Software, often contacting customers or Ambassadors and asking questions, getting feedback, and listening to their challenges or criticisms. We take that information and it helps guide us when we build the tools that help you in your job.
Recently, I watched a call with a customer who uses our famous Toolbelt in their job and has for years. In this case, the call was about the value of Flyway and how that might fit in their organization. The person performed a lot of manual work to deploy code changes, and could see the way in which Flyway helps, but wasn’t interested in saving time.
They saw their time as free. I assume their employer felt that way as well.
In my three decades of working in technology, I’ve seen a lot of employees and their management think of their time as free. Management has been happy to have tech workers stay longer at their desk to get things done. How many of you have had to deploy code on nights or weekends?
Perhaps a better question is how many of you have been happy to work nights or weekends? I’ve seen no shortage of IT people volunteer their efforts to work longer or out of hours to get something done. It’s a point of pride or a badge of honor to spend lots of hours working. I know I’ve felt that way in the past. I’m both proud of working 100 hours a week to support a system (for multiple weeks) and saddened that I did that.
I did learn that wanting to overwork myself was a poor idea after spending a year with a blanket and pillow in my desk. I worked overnight or late into the night too many times across a year and eventually decided to look for a new job when I realized that neither my employer nor I was valuing my time.
Many tech people are on salary, which makes it very easy for management to request (or demand) extra hours spent to meet a deadline or minimize the impact on other users who work “normal” hours. This happens to other professionals (doctors, lawyers, etc.), but I’m not sure that’s a good thing.
Working long hours, especially during stressful situations, can teach you a lot. It’s an opportunity to grow and improve your career, but it has lots of downsides. Burnout, mistakes, unhappiness and other negative factors can impact your life and work over time. You ought to value your time, and your employer ought to as well. I learned this when a coworker told our boss he was working the problem until 5 and then needed to leave for a family event. He could work later or come in early the next day, but not everyone needed to stay all evening tonight, and he wasn’t going to do so.
Learn to be more efficient, whether that’s in the work you do, or the people you manage. Learning to save time, use tools, share knowledge, and smooth your processes will build a stronger team over time. People will be more focused, more knowledgeable, and able to get more done in less time.
Invest in things that save time. It’s the one resource we can’t get more of, no matter how much we push on people.
Steve Jones
Listen to the podcast at Libsyn, Spotify, or iTunes.
Note, podcasts are only available for a limited time online.
