Voice of the DBA

Category: Editorial

  • Is there a Difference in Virtual Events?

    I’ve been to many SQL Saturdays across the last decade. I know I’m close to having spoken at 100 events, and I’ve enjoyed going to different cities, meeting lots of new people, and enjoy the local atmosphere. I love exercising at University Lake in Baton Rouge before their event. I’ve enjoyed wandering around Memphis to see sites, the music in Nashville is wonderful after a day of speaking. Getting up early and visiting Central Park in NYC or jogging through the city in Oslo are great memories. Evenings in Madison, San Jose, and Sioux Falls, and many other places have kept me entertained.

    Above all the hospitality of organizers and attendees has been wonderful. I still get plenty of warm welcomes from organizers of virtual events, but the local flavor is gone. In fact, I’m not sure that there is a difference between SQL Saturday Salt Lake City Virtual and SQL Saturday Slovenia. Organizers are still sending out gifts, and doing all the things that I’ve appreciated in the past, but it’s not the same.

    In fact, as both a speaker and attendee, I don’t see a difference between virtual events, and I wonder how many of you feel the same way. Are we just having events on different days of the week or different weeks and they all blend together? Is there any event that stands apart from the others, or do you just appreciate having events occurring constantly and weekend and being able to fit them in your schedule.

    I’m torn as to whether there is value in more of these virtual events, other than scheduling. I certainly can see that having SQL Sat Slovenia and SQL Sat Minnesota on Dec 12 makes sense, as the time zones allow people to attend sessions when they are convenient. As a speaker, it would be neat to “speak” at a Slovenian event and a US event on the same day, something I’ve thought to try in the real world. As an attendee, is there a season SQL Sat Plovdic occurs the same day as SQL Sat Slovenie? I’d rather one of them be a week apart since they’re both in the same time zone.

    I do like the accessibility of these events. Many more people can attend at that might not be able to spare the time, or make the trip to a live event. The cost to add more attendees isn’t something organizers worry about, and I could see there being a SQL Saturday on every Saturday throughout the year. That would be amazing.

    It likely doesn’t matter if we allow organizers to link an event to their city, or differentiate it from other events. To me, whether it’s New Stars of Data, GroupBy, SQL Saturday wherever, or any other event, it’s neat that I have lots of chances to watch a live talk and interact with a speaker. It’s still lacking something that a live event has, but I do appreciate the opportunity to tune into a talk and try to learn something when I have the time.

    I do think we need technology improvements to better deliver sessions, speakers need to learn to present differently when the entire screen might not be available, learning to explain what we’re doing, zoom in more, and use bigger fonts. I also think we need some type of mixed recorded/live/camera/chat evolution would make the experience better.

    I’m am thankful that we can continue to run events during this pandemic and find plenty of people to speak. I am even more grateful that I have the chance to continue learning.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Practice Your Skills with the Advent of Code

    It’s that time of year, when the Advent of Code goes live. It started this week, with a few exercises released last week. You can still join in, and even go back and look at previous years (2019, 2018, 2017, 2016) and go through them. It’s a good exercise for your mind.

    To be fair, I’ve never completed the challenge in any year. Usually life gets in the way, and I get distracted. I’ve gotten through 15-20 in some years, but often the time required to work through the complex algorithms gets me a little discouraged. I’m not a 10x programmer, but I try.

    One thing I’ve done most years is to try and work through the problems in multiple languages. Typically my choices have been to try and solve each item three times, using T-SQL, Python, and PowerShell. I find it interesting to compare the languages and see how to handle the test data and also get the solution to work in each environment.

    If you want to stretch your programming mind and have some fun, give the challenge a try. Posting your solutions to a blog or even open a GitHub repo (or other VCS platform). It’s a good way to showcase your knowledge, at whatever level it is. You might even learn something if others comment on your solutions.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Seeking Growth

    The word of the day is na·ive·té:  lack of experience, wisdom, or judgment.

    I used this word in a post, and wound up checking the spelling, since I constantly want to include an “i” instead of an “e” in middle of the word. As I saw the definition, I started to think about what this really means.

    We all experience this at times, after all, how can we gain experience except by working in a field where we lack it. The wisdom and judgment, hopefully come with experience, time, and (not too large) mistakes.

    The thing I’ve found often for myself is that I try to avoid situations where I am naive. I lean towards those places where I have some confidence, some wisdom, and experience. I work on my strengths most of the time. Certainly I’ve seen lots of people embrace that. We polish those things we enjoy, we have success with, and from which we get good feelings.

    When I coach, I see this often. Arguably, this is not the best use of most of your time. You ought to work on those things you don’t do well, those weak points, the places where you are naive. Improve the lower end, and the entire finished product is better.

    Or is it?

    I think you need a balance here. It pays to continue to refine you top skills, but it’s also good to grow and embrace things where you have little skill. Step into areas with the acceptance that you may make mistakes. Grow and learn, and embrace new ways or working, or even refinements to your skills.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • A Technology Collapse

    This past week the Arecibo radio telescope collapsed, with cables and instruments falling into the massive dish. You can see images of the devastation, which saddens me. I doubt this will be rebuilt, though one can keep hope alive. there were reports of failures a month or so ago, with the intent to shut down the telescope, remove instruments, and institute a controlled demolition.

    The facility was featured in a few movies, notably GoldenEye and Contact. The latter is one that first showed me the telescope, which I first thought was a movie magic trick. When I found out this was a real facility, I was amazed that humans could conceive and build such a structure. Even more amazing is that it was built in the 1960s.

    That’s quite a lifetime for a piece of technology. While I’m sure lots of wiring, electronics, computer systems, and more were added or upgraded, the core of this telescope remained the same. The ongoing engineering effort, fitting new capabilities around legacy systems and structures, was likely a study that many would find interesting.

    I don’t know many database systems that have survived that long, but certainly there are some long lived legacy applications. The Sabre reservation system for airlines is one that stands out to me. The history of this one is fascinating, especially as it’s a system I’ve depended on in my travels.

    Many of us that work with databases likely feel that everything we do is a legacy system. The dependencies our objects have on various applications, scripts, reports, and more can limit how much repair, improvement, or replacement we can make to schema.

    There are good techniques for modifying our objects, and helping to ensure we don’t break systems, but we often do need some cooperation and collaboration with application developers to implement those changes. Much of DevOps avoids talking about the database, but we shouldn’t. Instead, we ought to embrace database refactoring patterns, both at the database and application levels, ensuring that our systems can survive for as long as we need them while adapting to the changing requirements of our clients.

    Steve Jones