Voice of the DBA

Author: way0utwest

  • Continuous Learning

    It seems there’s quite a dichotomy in the technology workforce. On one hand I hear about the Great Resignation where many employees are leaving their jobs because of RTO (return to office) mandates or some other dissatisfaction with their job. On the other, I’ve seen quite a few people who were laid off and are struggling to find new positions. On the third hand, there is no shortage of companies who report they are struggling to find and hire talented people for some positions.

    I don’t quite know what to think, but I do know that employment seems to be harder to come by. If you are looking for a job, I believe you need your own sustainable learning plan. If your organization can’t find qualified talented staff, then the organization definitely needs a continuous learning plan.

    I saw a piece on creating a continuous learning culture, which seems more suited for managers than technology workers, but there are a few good pieces of advice. First, set some goals. I write about this often, and I’ve seen others recommend this as well. Think about where you could improve your skills, and where you see demand for skills, and then start working backward on a plan to gain those skills. Think about where you want to be in 6 months or a year and build a plan to get there.

    Another good piece of advice is to learn within your flow of work, which often means spending a little more time deepening or broadening your skills in an area where you are already working. If you’re writing a query, analyze the plan and reads and see if you could tune it to run more efficiently. Read about those skills and practice them, which deepens your skills. If you don’t know much about query tuning, then broaden your experience and learn about a new operator, new index, new hint, and experiment. Then you have a wider view of what possibilities there are in query tuning.

    More importantly, build the habit of curiosity and experimentation, which is what will help you drive continuous learning throughout your day. It’s good to look at new things, but don’t forget to sharpen your existing skills, practice being better at the work you already do, and find a balance that ensures you are growing while still meeting your other commitments, both at work and away from work.

    There’s an old joke that if you train people they might leave, but if you don’t train them, they’ll stay. For organizations struggling with talent, embrace some investment in current employees, at least those who have potential. Grow them and you might find that the person you’ve been struggling to hire is already working for you. They just needed a little boost.

    Steve Jones

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

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

  • T-SQL Tuesday #181: A Technology Present

    It’s the last T-SQL Tuesday of the year, and it’s amazing to think we’ve gotten to #181. That’s over 15 years of monthly blog parties.

    This month we have a slightly different invite from Kevin Chant. Kevin usually participates in the Festive Tech Calendar, which I’ve never been a part of. He wanted to combine those to together in a crossover, which is an interesting idea. I wonder how it will go.

    In any case, there’s a bit of explanation, but the essential invite is this: My invitation to yourselves is to write about a Microsoft Data Platform announcement that you considered to be as amazing as a present. In other words, something which made you go “wow”.

    It’s a good invite for the end of the year and my answer is below.

    Think about a VCS Diff

    I could say git diff since git has won the VCS battle, but in any tech work, it’s important to be able to tell what things have changed and evaluate if the change is helpful or hurtful.

    Lots of tools, especially visual ones, haven’t always considered this. They’ve often built a tool that doesn’t easily make comparing code easy. The first example of this was DTS/SSIS (SQL Server Integration Services), where this was a visual tool. The configuration was stored in an XML file, but every visual change created a change in the XML, and the structure was fluid enough that it was often hard to determine what changed between versions.

    Microsoft has a lot of tools that did this, including Power BI. However, a preview mode of the code was announced earlier last year. Power BI Developer mode includes Git integration. This gives us a way to edit the file as code, something that should be required of all tech tools. The visual stuff is great, but give us a code option.

    You can enable this in the PBI Desktop options.

    2024-12_0143

    To me, this is fantastic as it enables this to really work as a code tool, which it is. More importantly, as we get changes made by Copilot or other AIs, we need to easily see the differences that exist between versions. That’s important for troubleshooting and governance.

    To me, getting a Power BI project file that works in a VCS is a great present.

  • Grinding Away: Brent Ozar

    Brent Ozar is a very successful DBA/consultant/speaker/business owner in the data platform space. Many of you have likely seen him speak, read his blog, used his sp_Blitz script, or taken one of his classes. He’s achieved a lot and I know many people that would like to get to the place where he is in life. Most of us would love to teach a few classes, do office hours from wherever we are, and custom order a sports car for fun.

    One of the things I’ve enjoyed most about watching Brent move through life is his life quest. You can read this, but I’d recommend scrolling to the bottom (Level 1) and then going up through history. These are various items of achievement, some adventures, some things he had to work through.

    I’ve known Brent a long time. I remember when he started speaking, when his blog started to grow, and I have watched him put in a lot of hard work.

    He’s been grinding for most of his life and only recently slowed down. Before that, he spent a lot of time trying to improve his skills. He worked lots of hours to learn about SQL Server. He got his employer to send him to the SQL Server Ranger class to become a certified SQL Server Master and he studied hard to achieve that. Many of his goals around building his business or speaking to large crowds required investment of time and money to learn how to accomplish the goal.

    And he’s told many of you how to do the things he’s done. He shares lots of thoughts on what has worked for him, some things that didn’t, and given you a blueprint to become a better DBA, consultant, speaker or anything else.

    You just have to do it (and want to do it).

    If you want a good example, one of his early posts is on coding for his class reunion, a volunteer effort. Time spent forcing himself to learn.

  • Why Would You Do That?

    I was listening to someone at Microsoft talk about their product recently. I can’t disclose which one it was, but lots of people use this product and are impacted by changes. The particular thing that caught my attention was that the presenter noted there was a breaking change in the new version for some people. This wasn’t a huge change or one that would affect a lot of people, but it was a breaking change for a few.

    Another attendee asked this question: I would tend to do xxx instead of what you showed, so why would you do this?

    It wasn’t an antagonistic question, but more curiosity. However, it was a good question since any changes that cause breakage can be disruptive to other people. The thing I noticed was that the questioner’s frame of reference was completely different than the presenter’s. The questioner couldn’t imagine writing code in this way.

    As I work with more and more customers, I find that many of them get tunnel vision in that they approach their work or code in one of a few ways and don’t think widely about other approaches. In general, I think that’s a good way to work as we ought to use patterns and avoid anti-patterns in our work. The more we all code in a similar structure and style with the same patterns, the easier it is for any person to maintain the codebase (or infrastructure).

    Of course, we have to be willing to add new patterns when we find them and drop older patterns that no longer work (and perhaps refactor the code). That’s another hard thing for humans to do. We rarely want to let go of patterns and who has time for refactoring?

    At Microsoft, they have to consider lots of different ways to look at code. I saw awhile back one of them writing that building Windows was like ordering pizza for a billion people. You’ll never get it perfect and someone will always be upset. I get that. I couldn’t imagine making changes to something like Windows, where every little thing upsets some group of people and sometimes those are a very loud minority.

    Many of us approach the world in similar ways, and we can appreciate or understand small differences. When we meet someone who sees things very differently, then it becomes hard to reconcile their view with our own. In code, this often means we want to use different patterns than others, which creates a less maintainable codebase.

    Communication continues to be one of the hardest parts of building software (and most endeavors). Part of our communication should be to try and understand others’ points of view, get them to understand ours, and come to a shared understanding of how to approach problems. That shared understanding is what helps us build better teams.

    Steve Jones

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

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