Voice of the DBA

Category: Editorial

  • Using AI with Data Tasks

    The hot new technology of the year is AI. Between ChatGPT, Copilot, and generative AI, it seems that this is invading the world of computing at an incredible rate. Whether this becomes really useful and valuable or not is something that we will seem over time. There have been plenty of trends in this area in the past that haven’t become as ubiquitous as the hype would lead you to believe.

    I’ve done some light experiments with AI on my blog. To date, I haven’t found this to be that useful, other than a few cases where I basically used an AI to search the web for me. Rather than read a bunch of SSC or Stack Overflow results, the AI summarized things.

    Somewhat.

    I definitely had to test and verify the code more than I feel I’ve done with code posted in a forum. Of course, I do less experimenting because the AI results were a little more targeted to what I needed, rather than my cobbling knowledge and partial solutions together. I’m also not sure which I prefer.

    I would like to use AI for data work, and there is an article that talks about some of the ways that we’ve used AI in the past. Data profiling has made sense, and I can see value here. For data security, I’m not sure how helpful AIs have been. I’ve looked at some products, and I don’t know that I think any of them do a great job of identifying data. They do make it easy for whoever is assigned the task by doing some of the work, but they aren’t a panacea. They make mistakes, just like humans do.

    I do think data observation and looking for anomalies is a place where AI can really shine, but that’s not the data work that many of us do. It matters, but for most of us, this isn’t something we deal with.

    The future of AI was more interesting. The idea of data homogenization, taking data from different sources, and fitting it to a data model is interesting. Of course, the AI can’t make too many mistakes, or the time correcting might overwhelm the time saved. I think we see that now with humans who we ask to ETL data. If they aren’t good at it, or make lots of mistakes, those of us overseeing them might just do the entire job ourselves.

    I know that AIs are still new and immature, and while there is a lot of potential, they feel like junior staffers now, needing more handholding and micromanaging than I like to do. Perhaps they will change our careers and the way we work, but I don’t know how quickly, or even how deeply. Already I find lots of companies putting restrictions on what their employees can do with AI, which makes me think this might be more a targeted, niche technology more than a general, use-it-everywhere solution.

    Steve Jones

  • Taking Advantage of Conferences

    I’ve been very lucky in life to go to many conferences throughout my career. I’ve gone as both an attendee and a speaker, and I have found them to be valuable in helping me continue to grow and thrive in my career. This is across many employers, some of which I don’t think had particularly great benefits. Plenty of people I worked with did not get to attend any conferences, and some of them felt resentful. I understand that, but I think that many employers are willing to invest in training and conferences when there is a return for them.

    I started going to ComNet in DC, as a young professional wanting to learn. It was close enough to drive up and go for the free day and then return home. A few colleagues and I would make the trip once a year and talk with vendors, chat with attendees, and learn more about computer networking. Across a couple of years, we had moved from thinnet and thicknet to ethernet and IPX to IP, and this was a place where those technologies, and many more, were being discussed.

    During (and after) the event, I worked hard and improved my knowledge. I got things done at work. I got extra things done at work. I got my normal work done better. I solved more problems than in the past. Part of this was growing and learning, part was improving my troubleshooting, research, and testing skills.

    Some of it was meeting a few people at a conference I could email later and ask a question.

    As I changed jobs, I moved more into development and data work. I got the chance to go to TechEd and the PDC. I became involved in PASS and started attending the annual summit. I learned a lot in different sessions, and I made a lot of networking contacts with others. Many became friends, and many of them have helped me answer questions since then. I learned to not just attend a conference, but bring something back. Usually knowledge and always some swag to give out to co-workers. A gift for the boss that approved the trip was also a good idea.

    I continue to do this today. I often attend a SQL Saturday and sit in a few sessions. I still learn something that I can write about or help a client with. I might take a moment to ask a speaker a question that likewise gives me knowledge that I can use in my day job. There’s a payback for my employer when they’ve spent money for me to attend. There’s also a payback for my career as I’m always learning something new.

    This fall is the annual PASS Data Community Summit. It’s in-person, which I know limits who can go, but if you’re looking to be a high performer. If you get things done at work and your company values you, perhaps you can make a case that you are the person that will take advantage of a conference. Convincing others that you’re worth investing in, and proving you are, is a good skill to have. Take your best shot at it, and maybe you’ll get the chance to register and come. If not, the worst case is someone says no but learns that you want to drive your career forward.

    PS – Don’t delay. Prices rise on Sep 21.

    Steve Jones

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

  • Republish: Code Building Code

    Today is a Redgate event in Pasadena and I know the day will get away from me. Since I can’t manage the site or respond, you get a republish of Code Building Code.

  • Using Clear Language to Avoid Confusion

    A long time ago a software engineer advised me to try and ensure that I made my interfaces clear to users, especially those that are busy focusing on some other task the software enables. The phrase he used was to make a “Fisher-Price” interface, referring to the toy company that makes big and brightly colored buttons for their toys. The idea being that we didn’t want to cram too many things on the screen or possibly confuse a user.

    As a kid, I watched Mr. Roger’s Neighborhood on television and enjoyed the show. Lots of kids had a similar view, but they might not have known that the main actor took care in choosing his words to convey concepts and ideas to children. In fact, the former producer said that the writers joked that his manner of speaking was its own language, called “Freddish.”

    I saw an article that talks about the care Fred Rogers took in explaining things, with examples of how he made choices in how to communicate with his audience. The piece got me thinking about not only Fisher-Price interfaces, but also the language that we use to communicate with developers when we ask them to build something.

    Often I find in software development that we use a model or a shortcut to represent what we want. We partially describe something, or we assume that the words we choose mean the same thing to us and the other party. This goes both ways, with developers needing to be clear with their clients (and each other) and clients needing to be clear with developers.

    I don’t think I’d advocate for adopting Freddish, but I do think that we ought to pay attention to the words we choose, especially when we find the end result isn’t quite what is expected. Examining where the design went wrong and if we could communicate differently, or more often, earlier in the process to avoid problems.

    Communication is a difficult skill. I find constant examples at work, in my hobbies, even within my family where someone says one thing, but means another.

    To me. To themselves, they feel perfectly clear. Context, innuendo, implication, we depend on these a lot in communications, but those can cause issues when we aren’t very familiar with others. As we move to remote work, as we find less bonds with our co-workers because we don’t see the same body language, as we don’t eat meals together, as we don’t often share a context of work, we need to be more careful about the words we use and find ways to ensure we all are saying the same thing that the other person hears.

    Steve Jones

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