Voice of the DBA

Category: Editorial

  • The Art of Commenting

    This week I noticed an article on comments in PoSh over at Simple Talk. It’s a nice look at the topic from Greg Moore and discusses the various ways that you can comment in the language. Since these scripts are often shared in a corporate environment and because they may outlast your tenure, it’s a good idea to include comments in your scripts and functions.

    The idea with PowerShell is similar to what you get from docstrings in Python. Since many people can script and build modules, being able to get some help and understanding of the code is important. Even for the modules I write, I may use them for some time and then put them down. When I go to use the same cmdlet or function again, I might not remember all the parameters or what I was thinking. If you’ve ever had to dig into code to understand what is happening, you quickly learn to appreciate those well documenting help strings.

    You may quickly learn to despise those that don’t write them well or even forget to include them at all.

    Writing a useful comment is a bit of an art. The author often needs to put themselves in the shoes of a less skilled individual, or maybe one that is context switching and needs to quickly understand what the code is doing. Not necessarily exactly how it works, but what it is supposed to do. This helps us decide if we can use the code quickly, or if we might need to dig in further.

    In the article, Greg points out some nice additional comment items, such as requirements for the module to run. These are the types of quick enhancements to code that greatly improve its useability for others. I’d highly recommend everyone learn about comment based help in PoSh, docstrings in Python, and other valuable commenting techniques in your language of choice.

    Learning to write good comments is a valuable skill, one that your team will appreciate. Since most of us work on teams these days, those skills just might make you more desirable for that next promotion or even a new position when word gets out. Practice becoming a good comment writer.

    Steve Jones

  • The Time to Patch

    Microsoft has spent years working on building a reliable and dependable patch process for their software. While some products have had more sporadic updates, SQL Server has moved to a fairly regular schedule. Not quite a predictable “Patch Tuesday” schedule, but you can count on a CU arriving every month or two for SQL Server.

    Most people don’t patch every month, but slowly customers are getting used to regular patches for SQL Server. Microsoft would prefer you use one of their “evergreen” releases, where Microsoft is in control of patching. Azure SQL Database, and Managed Instances are handled this way, but with Azure Arc, you might deploy these inside of your data center and not worry about patching anymore.

    Most of us won’t get there anytime soon, and we will need to patch our instances. This week, I’m wondering about your patching process. Not whether you patch or not, but rather the extensiveness of your patching when you do decide to apply a CU.

    If you decide to patch a particular version in your environment (2016, for example), how long does it take you to patch all your SQL Servers? Do you even get all systems patched, or are there always lingering systems that can’t be updated because of some dependency?

    Maybe one other question might be how long does it usually take you to decide to patch your systems to some level? Or do you just randomly patch instances as needed?

    I am a big fan of leaving systems alone that are running well, but it seems the quality of patches from Microsoft has improved over the years. I’m not quite sure I’m at the point where I want to patch everything to month a CU is released, but I do think a regular process is a good idea, and hopefully it’s one that completes all instances for a version in less than 30 days.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Finding Motivation to Learn

    Monica Rathbun wrote a piece on investing in yourself, which I think is a good way to think about spending time and resources on learning. Every time that you spend some brain power on building or improving your skills, you are investing in your career, and giving yourself another way to drive your career in the direction you want to move.

    There are no shortage of excuses that Monica lists, and I’ve heard most of them. These are certainly hardships for your career, but these are things that many other people face, both in this industry and others. While these could be a short term reason to just grind out work, none is not a good long term excuse. I can accept you not progressing for a few quarters, but I’d hope you learned something new and helpful to put on your resume or CV every year.

    Doctors are constantly reading and learning to keep up in their careers. Lawyers and CPAs often give up weekends on their own to continue learning. Even mechanics, carpenters, electricians, and more are often working through continuing education. Some of it provided or funded by their jobs, some not, but plenty of it takes place outside of work hours. It’s just accepted that growing with your career is the norm.

    Most IT people expect they need to keep learning, but I find so many people are unmotivated to do anything their boss won’t provide, whether that’s time or funds. That’s a mistake, in my opinion, as you are one unexpected event from scrambling to find a new job. Plenty of people in that situation find themselves taking a pay cut, getting a longer commute, or finding more stress in their new position.

    Continued learning won’t necessarily prevent that, but it does increase the chance that you’ll be a more attractive candidate and perhaps have you pick of positions rather than settling for just some job you don’t want. The more you know, the more you can show, the more you document with a project, a blog, or elsewhere, the more likely someone is to want to hire you. Hopefully that means you find opportunities that suit you, rather than are just available.

    Steve Jones

     

  • Looking Back at the Decade

    Today is the last day of 2019, and the last day of the 2010 decade. I’m still somewhat amazed by the fact that we’re entering the 2020s and we still don’t really have flying cars. We’re well past 2001 and 2010, and still not much space exploration, though the growth in computing power and AI/ML likely accounts for the success of rockets that can take off and land and be used again. I’m still impressed by SpaceX. I’m also thrilled that I got to see the first rocket that landed successfully. Actually, we didn’t see much more than a flare light up and then go out, but my son and I were at Cape Canaveral, watching from the causeway on that historic night.

    In the last decade, we’ve seen a number of SQL Server releases. 2008 R2 was released in 2010, and since then we’ve had 5 other releases. Back in 2010, we didn’t have Availability Groups. We had clustering, Database Mirroring, and Log Shipping for HA/DR. We had no in-memory capabilities or columnstore indexes, things we assume are available now, even though not many of us use them. Maybe more surprising, the idea of SQL Server on Linux was still my most popular joke for most of this decade.

    Data became very important this decade, perhaps most notably with the passage of the GDPR in the EU. Whether you think this is a good law or not, it has changed how we view data. No longer is data something that organizations own and humans have no rights against it. I think it’s a good start, and lots of other regions are basing laws on the GDPR. We could do better, and ask for more control, responsibility, and accountability over data, but this is a good start.

    I also think that many people have started to become more data savvy and competent in how they work with database systems. While we see lots of basic and silly questions at SQLServerCentral, I see less of the completely ignorant questions being posted and more often I see complex requirements that are hard to handle in SQL.

    We’ve seen quite a rise in NoSQL database platforms. Neo4J was released in 2007 and MongoDB in 2009, but both have had a lot of growth in the last ten years. We’ve seen Apache Spark and Databricks appear and become integrated with SQL Server, which isn’t something I’d have thought about in 2010. Similarly, the evolution of Azure SQL Data Warehouse and Azure Data Lake are extremely recent. Windows Azure itself was actually released in Feb 2010. Now, it’s a collection of over 600 services that many of you use everyday. AWS has had similar growth to the point where I think many of us do think cloud first for many systems these days.

    SQLServerCentral was in v3 of it’s existence back then. The original ASP site had been rewritten in ASP.NET and then nHibernate when Redgate Software purchased the site. Since then we’ve continued to grow and thrive, adding our popular Stairway Series and continuing to help you learn and solve problems every day.

    T-SQL Tuesday was just getting going, in its first year. We’ve now had 10 years of the blog party happening every month. After a long run, Adam Machanic moved on in life and I now manage the event from tsqltuesday.com. If you haven’t ever participated, it’s a good way to get started with a blog and building a brand for your career.

    Quit a bit has happened since 2010. Data growth is astounding, and continues to increase. Exabytes were surprising back then, but today we talk in terms of ZB, another order of magnitude. I think that provides lots of challenges and opportunities for us to grow as data professionals in the next decade. I’m looking forward to it, and I hope you are as well.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.