Voice of the DBA

Tag: career

  • The Biggest Database Professional Challenges Today

    Today I have a question for you:

    What are the three biggest challenges you face today as a database professional?

    I was asked this recently, and I had some ideas, but I wonder if my challenges are the same ones you face. I don’t want to influence you, but I’m wondering what things cause you stress, headaches, difficulties, or somehow lower the enjoyment of your job.

    Or maybe these are the things that challenge and motivate you to do more. It’s up to you to decide what is a challenge to you as a database professional.

    I think about the challenges I have faced (and would face today) as someone working with data in a few ways. First, there are the actual challenges of working in an organization and dealing with other people/groups/management. Next, I think about technology challenges as well, with how we architect systems, pick tools, and make choices. Lastly, I also think about this in terms of my career and what difficulties I face there. How do I keep my career moving forward?

    There are several ways to look at this. In a general sense with a high-level view or with specific challenges in dealing with technology/people/etc., such as HA latency. Maybe you think about long-term issues or acute firefighting that you are dealing with every week. There are many ways to view the impediments to an endless progression of smooth, quiet, easy workdays.

    Spend a few minutes thinking about what challenges you have and let us know today what those are.

    Steve Jones

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

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

  • T-SQL Tuesday #176: One piece of advice for Past Steve

    I almost missed this month, so this is also a good #SQLNewBlogger post. I thought about it for a few minutes as I ate breakfast at my desk and then knocked this out.

    This is the monthly T-SQL Tuesday blog party. I manage the site at tsqltuesday.com, trying to keep the party going. I have a lot of help from hosts each month running the topic, and I appreciate their efforts. Join in an write, and then host a month. Lots of people have done it.

    Past Advice

    I struggle with this, as I’ve had a great life. I  wouldn’t change anything, given where I am today, 33 years after my first data job. However, knowing I’m not changing my life in some time travel way, this is something I wish I’d have known about in my early 20s.

    Network and help others in the community.

    I’ve done this lightly in my first few jobs, but mostly within organizations. As I’ve grown and changed jobs, I’ve seen tremendous power in people getting together to talk, to get to know each other, to share problems and solutions, to present their knowledge and learnings with others.

    User groups were a core part of this, and out of them grew the PASS organization and Summit, the SQL Saturdays, and the amazing community we have. It’ s far different than other communities, and many of them see it as well. They wish their world was like the data platform world.

    The power of networking is amazing. The rich world that comes from community is something special.

    It’s still there today and it’s worth joining, no matter where you are in your career.

  • What Do You Want to Learn?

    There are lots of resources for learning: articles at SQL Server Central, blogs, user groups, SQL Saturday and other events, conferences, and more. In most of those cases, the editor, author, or speaker is deciding what they want to write about. If you want to learn something different, you need to go search out that information. You can certainly request topics from others, but they may or may not listen to you.

    At least not as an individual.

    Steve Rezhener put together a survey for what topics you’d like to learn about. A few others, including myself, gave him feedback and he’s published this for people to use. It was intended for SQL Saturday organizers and speakers, but it can work well for anyone producing information. I’ve created some shortlinks at SQL Saturday that you can use to take the survey and see the results.

    This is open-ended, and none of the items are required. It’s long, but just answer the items you care about. While it does ask for places you’d attend events, you can answer or leave this blank. I love surveys like this one, since I can pick and choose and don’t have to answer every question.

    I plan on analyzing this data every month or so and publishing a report, which helps me decide what to request or publish here, but also which topics I might speak on in the future or what I might plan a SQL Saturday around. I would love to see more niche events, especially virtual ones. If some of you out there want to be an MVP, run a virtual event on your niche topic. Ping me and I’ll help you get going.

    The results of a survey like this might also help you decide where you should drive your career. If a lot of people are interested in something, likely it’s relevant to their jobs. Perhaps you ought to follow the crowd a bit if you aren’t sure what things might bring opportunities for you in the future.

    If you’d like to see more topics or different choices, drop Steve a note and I’m sure he can add to the form.

    Steve Jones

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

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

  • Poor Database Design Realities

    One of the interesting things that I see at Redgate Software is how idealistic our developers and engineers can be. They often build our database DevOps products with the idea that customers will use well-designed databases. The systems will have primary keys, foreign keys, defaults, constraints, indexes, and more. Developers will use coding standards, and naming conventions, and will understand what data is stored in tables. Not in every case, but often.

    After all, that’s how we build software at Redgate, as teams, sharing information, publishing documentation for others, and following best practices.

    It’s cute and endearing, and unfortunately, not often true. In most cases, I find databases built by developers, accidental DBAs, or even experienced DBAs to be full of inconsistencies, lacking constraints and keys, and even duplicating some indexes and forgetting others. I often joke during one of my presentations that the main thing people should learn is to add primary keys to their tables. However, I’m not really joking.

    During a recent design session on our masking technologies, there was a discussion on masking data in tables without PKs, which is a challenge. We’re working on it, and also on being able to mask PKs themselves, as some people use the PII data as a PK. This could be a tax ID of some sort, but could also be an email address.

    When one of our account executives (Rob Boswell) heard that we were enhancing our capabilities with regards to PKs, he joked that we will soon be “primary key agnostic.”  It was a great line, and in one sense it’s true. In another, it’s sad that we need to design tooling around such poor practices.

    The reality of the world is there is a lot of bad design, bad architecture, and bad code out there. I applaud those who work to improve things in their environment, am saddened by those who don’t (either improve code or their skills), and frustrated by management not supporting efforts to be better. At the very least they should support efforts to teach your staff to code things right the first time, which helps improve future code. The next best thing is to refactor and improve older code, which can help you spend less in the cloud, or run longer with the resources you have on-premises.

    The reality is the reality we are in, but that doesn’t always need to be our future reality. We can change the future, each of us, by learning to write better code and improve how we approach our work tomorrow.

    Steve Jones

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

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