Voice of the DBA

Category: Editorial

  • Be Wary of Data

    I fly a lot, as you might have guessed if you read my blog regularly. In 2025, I’ve been on 56 United planes as I write this, with about 10 left to go before the end of the year. One of the things United does is sometimes send out a quick “survey” after a flight, checking to see if everything went smoothly. I don’t always fill these out, but recently I decided to give some feedback as I had a great experience.

    I really wanted to just complement the onboard crew, but the survey was quite a few pages (10?) and a lot of questions. I started to try and fill it out, but lost focus after a few pages. This felt like a chore, and I started to just randomly click some of the selections asking me to rate things 1-10. I wasn’t really rating the items; I was trying to get done. Eventually, I bailed on the survey and didn’t complete it, but that got me thinking about the data from these surveys.

    I’m somewhat detail-oriented and I try to do a good job, but I couldn’t finish the survey. How many others just click through things and don’t really give an accurate picture of their feelings?

    A similar situation occurs at work, where we have an HR rating system (Thymometrics), which I really like. Over time, it helps me to keep an eye on how I feel about my job, the company, and my general attitude about work. We get quarterly reminders to fill this out, but I know quite a few people who don’t fill it out at all, or just click on it and save the ratings without thinking about them. Another place data might be suspect.

    At work we get feedback on various product metrics, in addition to uninstall feedback and product feedback, sometimes with a rating that people click. Is that what they really think about their experience or did they just click the first thing they saw? Or did they mis-click the wrong thing, and they can’t change their rating (clicking 2 when they meant 9).

    There is a lot of data that organizations collect from people that is very subjective. Across a large group of users, this should provide some sort of indication of how people feel, but if the sample sizes are small, can you really use this data? I think it’s easy for people in product management, marketing, and sales to view this data as much more accurate than it might be. I know I’m always wary of any outliers when I see feedback, and often I want to know how many people contributed.

    Unless it’s a decently large number (100s at least) and there is a clear trend from many people (> 5%), I tend to discount the data as an outlier and not representative.

    I’m not sure how many of you do this, but critically examine data and be wary of drawing conclusions. Especially when you are getting impressions, feelings, and opinions from others.

    Steve Jones

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

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

  • Republish: Limiting the Ability to Concentrate and Collaborate

    It’s another Monday off for me, this time likely catching up on some fall maintenance before it gets really cold. Plus, I’m gone in the UK next week.

    While I’ve likely doing something with my hands, and concentrating outside, you get to read about doing that inside:  Limiting the Ability to Concentrate and Collaborate

  • The Journey to PostgreSQL (or anything)

    Most of you reading this work in technology, and I assume that you’ve had to learn something new on the job. Technology is constantly evolving, even on our existing platforms. On top of that, we are regularly given tasks that are outside of our current skill sets. Maybe not far outside, but to meet the changing demands of our jobs, we need to learn new things.

    I ran across an interesting post (on a new site) from Brent Ozar. I think that guy writes as much as me, but he wrote this one: Why I Started Using Postgres (And You Might Too). It’s a little provocative, but there are good posts on the site about things Brent learned in PostgreSQL. I won’t go into whether learning PostgreSQL is a good idea.

    The thing that struck me in this post is that Brent knew that this move was a risk. He was worried about moving to a new platform, despite all the reasons he had for doing making the change. I would bet a lot of us are in similar situations. It might not be PostgreSQL we are being asked to learn, but it could be Fabric, Databricks, Python, PowerShell, CosmosDB, or whatever other thing someone in our organization thinks is cool.

    The best sentence in here is this: “I gambled that I’d be able to learn how to do performance tuning quickly enough, …, in time to head off issues.” That’s the attitude I’ve often had in my career when I get requests to do something new.

    I’m willing to bet on myself.

    You should be willing to do so as well. Not bet on me, but on yourself. I know you don’t want to work 80 hours a week to learn, or get stuck trying to solve problems every weekend with new tech. However, I hope you are willing to do that for a week or one weekend. You’re willing to do some reading at night or experimenting during lunch in order to make something work.

    You’re going to have tough times. You’re going to question if you can make something work. Getting comfortable with being uncomfortable (for short periods) is how we grow and learn. It’s how we take leaps forward.

    It’s how we take advantage of opportunities that are in front of us.

    There are always opportunities to make a difference, to effect change, to build something you are proud of or that your organization values. Those stressful times when you drive to make something new succeed and have to learn a new skill in the process, these are the times when you can take advantage of an opportunity.

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

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

  • We Should Demand Better

    I ran across an interesting open letter. Most of these are from individuals, often complaining or lamenting on the way something in the world works, or maybe doesn’t work.

    This latest letter was from the Chief InfoSec Officer at JPMorganChase, a large worldwide bank. This open letter was written to the software suppliers looking to do business with JPMorganChase, especially those in the SaaS area (Software as a Service). The letter opens by noting that SaaS is enabling cyber attackers and asks for three things: prioritize security over features, modernize security architecture, and work with security collaboratively to prevent abuse of connected systems.

    It’s a good letter. It talks about the problems at a high level, but is specific enough to recognize problems. Software is often delivered as a SaaS type application, even when there might be local components. For example, I lament Postman working this way, as it now seems to now require me to be connected in order to work. That’s something I learned while trying to get work done on an airplane, and I couldn’t get to any of my queries as I didn’t have wi-fi, despite the application running locally on my laptop.

    The threat of more attackers is amplified by the connectedness of new systems, new agents, and new protocols that allow a breach to escalate deeply inside systems. This is something we’ve faced in the past, but not at the scale that we face it today. Automation has become embedded in the computing world, not just inside organizations, but also inside hacking organizations. Malicious actors can and do use scripted attacks at a rate that we haven’t experienced in the past.

    I wish that most people purchasing software would prioritize security when making a decision, but often price and expediency outweigh anything else. While I do see many companies asking for security information, too often the requests are at high levels, and vendors can word their answers in a way to satisfy the screen without actually improving their own security coding and architecture.

    I do think the authorization and authentication of users is improving, so I have hope that more patterns and frameworks are published and widely used, and we’ll see more consistent security throughout software. Now, if we can just ensure the authors of those platforms do a good job of security, we might see the request from JPMorganChase come true.

    Steve Jones

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

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