Voice of the DBA

Category: Editorial

  • Working Predictable Hours

    I was listening to Kendra present at Redgate recently and she said this: Working predictable hours makes me better at my job. Actually, she said she was not better at her job by working longer.

    Kendra has been very successful, she’s driven and a bit of a workaholic. I used to think I was, but after spending a few years at Redgate with her, she can outwork me these days. Of course, she has a bit of youth on her side. We both, however, realize that more work isn’t sustainable, or even good for either the employer or employee.

    There is plenty of research that shows working above 50 hours constantly makes you worse at your job, at least when you are doing thought work. For more physical work, your body breaks down, and likely you will struggle with health as you near retirement.

    Kendra has a good list for setting boundaries in her life. Many of these are things that I’ve implemented over the years in my life. In the last few years I’ve gotten rid of many notifications that interrupt life, as well as set Do No Disturb hours on my phone. Rarely have I missed anything important, and I’ve avoided plenty of early am “quick questions” from the UK. Apparently they are as bad at calculating time zones as I am.

    At the same time, I like unpredictable schedules, but fairly predictable hours. I don’t like a rigid schedule, and I try to ensure if I have standing items, they are on a few days so I have flexibility on other days. I like being able to take breaks during the day to go to the gym or work on something around the house. I certainly like the freedom to stop working on a Tuesday if I don’t feel productive and making up time on Saturday or Sunday.

    This past year has really been a very predictable schedule for me and others because we couldn’t go many places. We woke up, walked to another part of our house, worked, and then repeated that over and over. Some of us did a better job of learning to stop working after certain hours, and some did a worse job and spent more time working.

    No matter what type of structure you use, remember that you need to take care of yourself. Your physical and mental health aren’t worth sacrifice for an organization. While you do owe your employer an honest day’s (or week’s) work, you also owe yourself a balance. Do your best work, which also means limiting how much you tackle every week.

    Steve Jones

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

  • Back to Basics

    This week I saw a post from Randolph West that covers binary and hexadecimal. It seemed basic and simple to me, but I’m old. I started learning about binary and hex in high school, where we used to tap our fingers to count in binary. Up was “0”, and down was “1”, and with one hand, you count to 31 (from zero). At the time, I thought it was important to know binary and hex to work with computers.

    These days, I’ve rarely had to deal with binary and hex. They aren’t useless in programming, but they are much less used in these days of GB of memory and large data structures. We don’t encode things as often as we used to. Usually now hex just means I’m dealing with varbinary and need to cast it (or render it in some other way).

    During the last few years, I’ve seen some efforts to get back to basics and publish more information that helps people get started or fill in gaps for areas that someone might have missed. Years ago Ed Leighton-Dick started the SQLNewBlogger challenge. I participated, and continue to write some basic posts every week or two. Grant had his database fundamentals series, and SQLServerCentral has published the Stairway Series for some time, giving people a way to get started in some new area of the data platform.

    I think it’s important that we continue to cover the basics in all aspects of the data platform, as well as other areas. The world of technology is so wide, and new people are always starting their journey in their industry. Even for those of us that have worked with SQL Server or some other area for a long time don’t know everything about the platform. We often have as need to learn more about some niche and need some basics to help us. I think Azure Data Factory as a perfect example of this. Many people who worked with SSIS for years might need a few primers on the differences with ADF to understand a slightly new paradigm. Much of cloud computing needs basics, and constant updates to those pieces.

    I know that the basics are always popular at SQL Saturdays and other conferences. The basics often get the most reads as articles, and I am hopeful that we will continue to see those with knowledge remembering that the basics are often the most important part of learning to build better software and systems for the future.

    Steve Jones

  • Should You Learn R or Python?

    I’ve been working on various skills over the last few years, trying to solve some simple problems in Python and PowerShell, in addition to T-SQL, to continue to improve my skills. It’s an interesting challenge at times, especially when I need to use new features or functions to which I haven’t had exposure in the past.

    I also work with R lightly, as I need to build some Questions of the Day for SQLServerCentral and I try to alternate Python and R questions every week. This has caused me to dig in and try to learn more about the language and how to manipulate data.

    Recently I was reading an essay from a consultant that works with clients using both R and Python. The piece talks about the differences and how these work to solve business problems. If you don’t want to read the entire thing, the comparison starts with the simple “you need both”, though there is more to the story.

    The most interesting part of this for me was that the author notes that while these are good languages in different ways for data analysis, they aren’t great for data preparation and SQL is still required. Either a database like SQL Server or a platform like Apache Spark. Part of the reason is that R and Python aren’t very efficient, and as we work with more data and larger workloads, efficiency matters.

    The other part of the piece I liked was the note that we need to collaborate and our work needs to be reproducible for others. I love having git for moving code around and keeping configuration files in a repository of some sort. It has certainly helped me take advantage of bits that others have written and easily reproduce their work on my system.

    While some of us work with just SQL, I expect that we will get involved with other parts of projects and may need to help troubleshoot or improve code. I find both of these languages interesting and a nice complement to each other. I’ve also learned there are places where I much prefer one over the other, especially with some of the Advent of Code problems. Some are simple in SQL, but others are much more suited to Python. I haven’t tried them in R, but I bet some of them would be well suited to that environment.

    If you have tried either, or have a preference, let us know. What are the advantages or disadvantages of each when you are working in a business?

    Steve Jones

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

  • Hostage Data

    Ransomware continues to surprise me in different ways. Recently there was an incident where data was not only encrypted, but also copied back to the criminals. In this case, Apple was the target through a supplier with the ransom note saying that without a payment, the data would be auctioned off.

    That’s crazy. Not only might you have business issues where you can’t access data, but now you have the stress of the data possibly being released or sold. While not many of us work in organizations where our data would be worth $50mm, it might be worth a significant amount, especially if the data were customer data. This alone might be a good reason to ensure that you have local data already encrypted without the keys present. At least then the criminals couldn’t read your data.

    This doesn’t help with SQL Server and TDE. In that case, the certificate would be inside the local master database, and if someone could attach it and get access to the master database, they could read your databases. If you have an SMK and a DMK, perhaps this might offer some protection, but I don’t think so. This does mean that Always Encrypted might help, unless you have lots of servers or other machines on your network with the certificates, in which case someone might be able to piece together the keys and read data.

    Attacks are becoming more numerous and creative. Having backups might have protected you against some ransomware, but not if copies of your files are sent to criminals. Perhaps the access from servers to the outside world needs to be more reigned in. Not much fun for administrators, but this might be the future of protecting systems.

    The arms race between sysadmins that protect infrastructure and criminals seems to have taken a leap forward here, and I’m not looking forward to the next step.

    Steve Jones

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