Voice of the DBA

Author: way0utwest

  • Hardware: Check the Drivers First

    This isn’t a database post, instead, I’m going to talk about my laptop.

    I got an HP Spectre x360 a couple years ago and was using it for work and presentations while traveling. Everything was fine, and then the COVID-19 pandemic shut down travel. I rarely used it across the last year, mostly working on my desktop, or using another laptop I have around. I didn’t sit idle for a year, but I might have used it every 2-3 months for a few hours.

    I know I have updated some software, including Windows in the last year, but a  few weeks ago I picked up the laptop and took it with me on a trip to work. I opened it to get something done and the screen kept flickering, sometimes going dark. I rebooted, and it seemed to do better.

    I used it a few more times across the last few weeks and each time the flicking got worse. It was essentially unusable, and I assumed that the hardware hinge between the keyboard and screen was damaged somehow and causing flickering. I started to go down the support process for repair, but then stopped.

    I’m not sure why, but I searched for “hp spectre screen flickering”. Google auto completed the last word, so I suspected that this was a known issue. I still assumed hardware, but I clicked and read a few posts, like this one.

    The medium answer (we’re past short here) is that the driver for this laptop from HP causes flickering. It acted like a poor connection, but when I downloaded the drivers from Intel and installed them, the flickering stopped.

    Crazy.

    It always pays to do a little research and ask some questions before assuming you know what’s wrong. In this case, I found a solution I never would have thought of: using the generic chip drivers instead of the manufacturer.

  • Tough Interview Questions

    Many of us know that interviewing someone and evaluating their skills is a tough job. There have been all sorts of techniques tried by various companies, some of which require creativity, but many are related to technology and practical skills. All in all, I’m not sure any of these really predict if someone will be a valuable employee.

    I’ve seen a lot of senior technology people lament the quality of the candidates they interview. I suspect some of this is that most of the really talented people aren’t out there interviewing regularly. Instead, there are many people applying for jobs, some with narrow sets of experience that might not match what you are looking for. Some may be applying for jobs that are beyond their skills, hoping to get through an interview and get an offer. Maybe others rub the interviewer the wrong way, and create a negative impression that doesn’t represent how the person might work with others.

    I ran across an article that listed a number of SQL Server interview questions, most of which are aimed at experienced developers. It’s not a long list, but it does cover some topics that aren’t necessarily things that you use often in SQL Server. While I have written an INSTEAD OF trigger, I haven’t often and might not give a great answer for someone that is looking for deep knowledge. I would like to think I can give a decent explanation of what this is and where you might use it.

    Perhaps that’s the intent, however, to see if an experienced person has touched a lot of different features in SQL Server. Maybe this is a breadth more than a depth list? I’m curious if you think that is the case. Maybe you have an opinion you’d like to share on these, or other questions, which might help you determine the experience of a candidate.

    Finding a great candidate for your organization is hard. It doesn’t matter if you are looking for junior people that can grow, or senior ones to lead. Often interviews result in an impression that is a bit of a coin flip. After a year ,you may or may not feel that you made the right decision.

    Steve Jones

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

  • Daily Coping 5 Feb 2021

    I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag. 

    Today’s tip is to write down hopes or plans for the future.

    I sure hope the world gets to a more normal place. In the meantime, I can just dream.

    Recently I was reading Brent Ozar’s Epic Life Quest.  I hadn’t followed this for awhile, so it was nice to catch up and see how things are progressing. Especially with his move to Iceland. It got me thinking about things I want to do. I used to keep a “life list”, but I stopped at some point. My wife and I have both been talking about redoing our lists.

    Here are a few items for my future dreams:

    • Return to New Zealand and hike Milford Sound
    • Hike Machu Piccu – if it opens again
    • Visit Japan and tour around
    • Build a cabinet for the house that my wife allows me to hang
    • Build a cabin of some sort by hand
    • Work for a charity full time

    Hopefully I’ll accomplish a few of these in the coming years.

  • Do it. Try it. Fix it.

    “Do it. Try it. Fix it.” – Sam Walton

    That quote is interesting, and while I don’t think Sam Walton was thinking about software, this is the loop that I, and many others, follow. We see a problem, and we try some things. If they work, we move on, if not, we fix things.  At least, that’s the approach most of us would like to take when we see an issue. Sometimes management gets in the way of us following a simple process.

    The key part of that quote is the first part, the part Sam Walton talked about was acting in some way. Doing something, making a positive move towards improving something. Many of us want to take action, especially when we see a problem. Again, however, management can get in the way if the problem isn’t prioritized.

    There’s one part in DevOps and software development that comes after the “fix it.”. We need to ensure we don’t repeat that type of mistake. This means that when we find a solution, especially a better pattern of building something, we share it. We use the feedback loops and learning ideas in DevOps to ensure others in our organization don’t need to do their own “Do it. Try it, Fix it” loop and repeat our work.

    One of the hardest things to convince smart (or very busy) developers to do is change their work habits and patterns to implement something new. While it can slow things down, or create other work, in the long, or even medium term, we can all be more productive if we take the time to share what we’ve learned. We also need to take the time to learn what others share.

    Of course, proving your way is better can be a challenge. You need to be sure of yourself, gather evidence, and learn to present a convincing reason why someone else should change. If you can do that, you will have more success.

    Steve Jones

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