Voice of the DBA

Tag: career

  • Do as I say, not as I do

    A common saying from parents, teachers, and many managers, is that you should follow their instructions and not necessarily their behavior. This is a very human thing to do, with many of us struggling to follow the behavior that we ourselves want. Instead, we follow the vagaries of our moods and desires. We do this even as we tell others to do things that we don’t bother to do.

    It’s not just human behavior, but it applies to how many companies deal with their customers. Microsoft talks often about taking advantage of new features in code and using the platform to solve problems. They dislike adding simple “syntactic sugar” (like a numbers table), and instead prefer you build the code to handle some of these simple tasks.

    However, they don’t really follow this advice, as Andy Mallon showed with a recent post on why not to use a couple of their “recommended” stored procedures. They’re not well written for modern code, they have limitations (or bugs), and could be considered a security risk.

    To be fair, I know that changing code in something that works is always dicey, but at the very least, moving from varchar() to nvarchar() shouldn’t break anything. If there are edge cases, then write some tests and rebuild the code to work better. Maybe, more importantly, these procedures ought to model good code, as Microsoft would recommend to their customers.

    There are a lot of places where different products at Microsoft might not use SQL Server well, and I understand. These might be software developers that don’t know a lot about how to perform good data modeling or even how to take advantage of SQL Server code. However, at a company with the resources Microsoft has, I’d expect them to form teams to handle these tasks and then review and suggest changes to software like Dynamics, Sharepoint, etc. Even if they can’t use the latest features in the SQL Server codebase, they ought to model good practices for all versions.

    For many of us, we might act similarly inside a company. Often we write code out of habit, and perhaps, to expeditiously get work completed, even when we know better. Using SELECT *, leaving out error handling, and more are habits that far too many of us embrace, far too often.

    Start making some changes today. If you know there are better practices you should follow, then take the few extra moments to implement them. If you don’t know of good practices, start compiling a list, asking questions, even post an idea or question in the discussion for this editorial. We all could write better code, and that starts with us actually making an effort to model the behavior we might preach to others.

    Steve Jones

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

  • Goal Progress for July 2021

    I set goals at the beginning of the year, and I’m tracking my progress in these updates during 2021.

    As I look at goal progress for 2021, I’m going to follow a similar pattern as last year. I’ll give myself a current grade and report on overall progress in of the areas where I set goals.

    This is a two month update. I forgot to publish June, so here I am including both months together.

    Current Grade: C

    June was vacation month. I spent a few days in the Florida Keys, and then another week in Orlando coaching. In between, I was trying to get work done. Not as much progress as I’d like, especially as a lot of non-work time was spent catching up on chores around the ranch. An unusual level of things to fix.

    July was slightly better, but not a lot. I ended up with a couple trips away from home, lots of chores around the ranch, a business trip, and a bit of stress from a home renovation. As a result, I read a bit but fiction. I also tried to take a bit more time away from the computer.

    In any case, I’m still not pleased with progress for the most part, but I am learning that maintaining steady progress across the year is hard, even with relatively few goals..

    Reading

    The goal was 4 books (3 non-fiction, 1 tech).  I finished one in early July, and found a few more to add to the list. I haven’t been sure what to read, but I found a few career books. Now I need to find a tech book for the second half of the year.

    Here’s the current progress:

    I started with Lights Out as I think it’s easier to read.

    I’ll put a short review of the Project to Product book out in August month as well.

    Technical Skills

    I’m solving the Advent of Code three times.  I’m also studying for certification.

    In terms of work here, I did little with vacations. I should have spent a little time on Azure, but really, I didn’t do much. A little, but not much. For coding, I’ve just hadn’t put in much time. I started on day 7, but got a little stuck, and hadn’t completed the challenge in SQL, which is where I started. I should have started with Python or PoSH, as this is a recursion issue. I also hate recursion, and I’ve been avoiding this.

    For certifications, I started watching some videos, but I find myself getting too distracted with other things. So I’ve not been focused on more programming, which is really a state of where I am in my career. I should have done less here goal wise.

    Update:

    • Certification –  AZ-900 – 5%
    • Certification – DP-200 – 0%
    • Skills – T-SQL – 2020 Advent of Code – 5/25
    • Skills – Python – 2020 Advent of Code – 6/25
    • Skills – PowerShell – 2020 Advent of Code – 5/25
    • Skills – TBD

    Projects

    Little things are moving forward. I did send a note to the 2 groups near me offering to speak. The other one appears to have stopped meeting during the pandemic. I have scheduled a talk at one for August. Not sure about the second.

    I did a little more work on my volleyball report, and started to structure the data store in Excel better to ensure I can easily publish this early next season for the next team. I also started to write about how I’m doing this, so I think this is further along than it was before.

    • SQL Saturday Inc – 90%
    • Support events: I spoke at another event and a couple user groups
    • Speak at the 3 local user groups, at least one live presentation – 15%
    • Help organize a Denver/Colorado event, live or virtual – 20% (more conversations)
    • Complete my Power BI Volleyball report – I know lots of kids will use this, so I need to get it done – 70%
    • SQL Memorial – 90% – I updated this, sadly, as someone passed. I need to move this to straight GitHub Pages and get the custom domain set.

  • Messy Job Descriptions

    I saw a job description recently for a DBA that asked for SQL Server experience, but also “other RDBMSes, like Cassandra and PostgreSQL”. Not sure Cassandra fits there, or why this says like. I’ve seen some other ads that ask for C# or Python. Some asking for MDX/DAX knowledge along with AWS Cloud Formation and programming APIs. Some have a required and optional or “nice to have” sections, but many include a laundry list of technologies and skills. For software developer roles, the list of skills often exceeds what I think any person in the world might know.

    There was a debate about this at SQL Server Central in one of the threads. It seems some people are split on whether this is a problem or a good thing. Quite a few people noted that they wouldn’t apply when there are so many items listed that they don’t have experience in. For others, we wouldn’t hesitate if we had around 50% of the items listed. I’m in the latter category, as I’ve had plenty of friends, and myself, get jobs that might have seemed out of reach based on the description and our skills.

    In my experience, often a job description is put together on the fly and in a hurry, usually by someone that isn’t familiar with the job. They ask others what to include, and we end up with a large list of things that would be nice, but not necessary. The end result isn’t always what the job entails, at least not completely. Often I’ve found as a developer or operations person I might end up lightly touching parts of different roles, but not regularly and not too deeply.

    I don’t know that I think it’s worth effort to tightly define a job for a new hire, as the job requirements can change, and we might adapt a job to the individual. Not completely, but if someone knows more about reporting or BI than HA/DR, we might have them tackle more of that work and only partially work on clusters or AGs. Others might fill in with more HA/DR and less BI work. The reverse also could be true, so should we have a job description that is narrowly defined to DBA work with an HADR focus? Or one for BI? I don’t know, but I learn towards not tightly defining a job description.

    Hiring is a difficult enough process, especially today, without too tightly defining the roles. I do think it’s worth spending time with the team doing the work to list out the necessary skills (and levels) needed to help them, but adding in other items is useful. It casts a wider net, and it helps you as the hiring group, think about what tradeoffs you might make. If someone is weak with replication, and we use it, but they have some strong Azure skills, maybe we accept that. We know we’ll need to train this person on replication, but they might help us better understand the cloud. Perhaps that’s a better choice than someone highly skilled with replication but without a lot of other experience.

    Or maybe not.

    Ultimately, on the hiring side, include what you want. It doesn’t have to be perfect. If you don’t get candidates, then re-examine it, but list what you really need, and separately, what you want.

    On the candidate side, don’t be intimidated. If you get to 45% of the skills, apply. If you hit 75% of the requirements, apply. Maybe even if you’re a little short on those but you have other skills. Use what you know, and what’s been listed, to help you drive the interview. Emphasize your strengths, and convince them you can learn. Ask questions, use “I don’t know, but” often with examples of how you might gain the knowledge or get help. That often is more important than what you have done in the past.

    Steve Jones

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

  • Do We Need to Learn Linux?

    This week we got an announcement about SQL Server in Containers. Microsoft put out a blog noting that the beta program for SQL Server on Windows containers is suspended. They didn’t give any details, citing “ecosystem challenges and usage patterns” as a reason so suspend the program for the foreseeable future.

    Not only that, they noted that they were deleting docker hub images for express and developer, which makes sense from their perspective. They don’t want to support these. From the developer perspective, however, this will break and flow, pipelines, or even local scripts from developers. I understand the desire to delete images, but doing so without any notice doesn’t seem like fair treatment for people using them.

    This means that if you want to run SQL Server in a container in production, you likely have to use Linux. Windocks has an alternative with Windows, but Microsoft not supporting this is disappointing. I think that containers will be the future of database development, as they standardize and simplify how we can get an environment up and running. They also ensure consistent environments between developers, branches, automated systems and more. I think it’s going to take years, but that’s the direction where I think many of us will go over time. Those days of the Developer Edition will be gone, and instead we’ll just run a container.

    I’ve been using Linux containers for a few years, and they make it easy to quickly set up a clean environment with a new instance and a database or two. In that time, I’ve had to use a little Linux at times, but really, I start a container from a command line and then it acts like an instance I’ve installed. There isn’t a reason to actually do much in Linux. At least not for the core database stuff. Most of the ways that you’ll work with a Linux instance as a developer stay the same.

    For system administrators and DBAs, however, you might need to learn more. While setting up an instance on Linux isn’t hard, and easier in a container, if you are called on to work in bash, execute sudo, or some other Linux command, you might want some basic familiarity. Fortunately, you don’t need another workstation as Windows 10 includes a Windows Subsystem for Linux (WSL) that let’s you play around in Linux inside Windows 10.

    I think Linux is fascinating, and it’s evolved in many ways since I first saw it in 1991. Even if it’s not something you expect to use daily, spending a few hours learning how to navigate around and get things done is good for your mind, forcing you to learn a bit. The San Diego TIG did a series a few years ago, and you might go through those meetings or pick up a book and spend some time playing around with something new. You never know when this might be required in your career and a little familiarity could give you a jump start in the future.

    Do we need to learn Linux? No, but it’s not a bad idea to build a few skills in this area.

    Steve Jones