Voice of the DBA

Tag: career

  • Titles and DevOps Confusion

    Alex Yates has become quite the DevOps consultant in the last few years. I used to work with Alex at Redgate before he left to start his own consulting firm. I hear nothing but good things about his work, and if you are looking for someone to help guide your database development team, he’d be a good choice.

    He wrote a piece on the Octopus Deploy blog about the title of DevOps Engineer and why that doesn’t quite make sense. He essentially notes that this doesn’t really describe what a person does and it might not be a good title. I tend to agree, since DevOps isn’t a thing, per se, but rather a set of guiding principles. While this might include building software, or deploying it, there are titles for those things (build engineer or release engineer). It could include Infrastructure-as-code, but that’s the domain of sysadmins.

    There are any number of titles that have come about in this business, and likely more being created all the time. If you have a new job, often you can finagle your way around some pay structures because after all, if you invented the term, the HR department doesn’t have a pay scale to limit you. I suspect that’s part of the reason someone started calling themselves a DevOps Engineer in the first place and got someone to hire them under that title.

    I suspect titles used to be more descriptive and important in the past, when we had fewer of them and the work that each of us did was more tightly scoped. Throughout my career, I’ve started to see more people doing more types of work all the time. Especially in technology where we usually do the work that needs to be done, often crossing over the duties between job titles when something is broken. Getting a system working often takes precedence over any claims of some task being “my work” or “your work.”

    Titles ought to be somewhat consistent, if for no other reason than to easily allow us to compare the work we do in different organizations and allow us to easily promote ourselves to a new employer. If every organization had different titles, we’d waste a lot of time trying to decide if we wanted a position, as would hiring managers trying to decide if we could do the work. Certainly the we find that a DBA or a Developer moving organizations might have some different tasks, but we have a general idea of what work they should be able to complete.

    I’ve never been too concerned about my titles, though I have worked to become “senior” at different employers. That’s usually a function of proving you can do the work well, across a period of time. Of course, if you get work done effectively and efficiently, the title likely doesn’t matter. Someone, likely many someones, will want to hire you.

    Steve Jones

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

  • Goal Progress for May 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.

    Current Grade: C+

    Again, I’m falling behind and I’ve been a little busy in life, so not doing much outside of work. I read a little, and some SQL Saturday things, but not much coding. I did get some project work done, so it wasn’t horrible, but as I’m winding down volleyball season, that’s eaten up time.

    Reading

    The goal was 4 books (3 non-fiction, 1 tech). Here’s the current progress:

    • Non fiction – Project to Product – 47%
    • Career – TBD
    • Career – TBD
    • Technical – TBD

    Technical Skills

    I’m solving the Advent of Code three times.  I’m also studying for certification. In terms of work here, I did do some coding, but not enough. I’m behind here and #7 is daunting, which slowed me a bit. Same as last month, I tried #7, but got stuck and gave up.

    • 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

    I had a few projects for myself. Most of May was SQL Saturday stuff. So far things appear to be working fine. I did work on my PowerBI report a bit and it looks good so far.

    • SQL Saturday Inc – 90%
    • Support events: I spoke at another event and a user group
    • Speak at the 3 local user groups, at least one live presentation – 0%
    • 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 – 60%
    • 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.

    Overall, SQL Saturday is really set. Incorporated and starting to contact people. Updates here: blog.sqlsaturday.com

  • 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.