Voice of the DBA

Category: Editorial

  • Container Development Work

    On my new laptop, I only use containers as database servers. I made the decision not to install SQL Server or PostgreSQL and instead work on containers only. I’ve written lightly about this, but I set up docker-compose files to load different instances of SQL Server and PostgreSQL (and others) and batch files to start and stop them. I’ve also set dedicated places on my disk where I can drop backup files and access them from the host.

    It’s 2024. I moved to containers on my laptop exclusively for databases for the first time this year. This is despite the fact that I like containers, am comfortable with them, and find them handy. Moving from installed database server software to containers took a conscious effort, and it took time to configure everything. Really, it took me a bit of time to think about how I’d want to configure my system so that my work in SSMS went smoothly.

    I saw an blog recently from Microsoft on some of the devcontainer work they’ve done. I talked with a few people, who showed me how easy this was to do in ADS or VS Code and ensure your database was included as a part of your project. On one hand I was impressed. On the other, I don’t see many people with projects in ADS/VS Code and the need to spin up/down containers and connect through that tool. Plus, how easy is it to get connected with SSMS or another tool to the container?

    If there is any friction in using a new technology, most of us won’t adopt it. Even if we’re forced, we’ll be upset (and less productive) for quite some time if using something is a hassle. I believe in containers, but spinning one up from go-sqlcmd is far different from easily being able to grab a backup file from a friend and get it restored.

    While I see lots of companies where developers are excited to use containers, I see relatively few where containerized is the default, or even common, method of working with something. I see even fewer where containers are used for database work. Certainly some people use them, but not most.

    Local installs, dev servers, and VMs seem to still be very common. They’re tried, true, and familiar, Most of us like things that are familiar and we fall back to them quickly.

    Do you use containers for anything? Testing out software? Actual work? Are you even allowed to use Docker or something similar to run containers? Maybe less likely, but I’m curious, how many of you actually deploy containers in production and with what tech installed in the containers?

    Let us know today. I think containers have lots of possibilities, but they haven’t caught on as quickly or widely as I would have thought. Primarily because of friction.

    Steve Jones

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

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

  • Fifty Percent

    Most of us will have more than one job in our career. In fact many of us will likely find a new job in the next five years. I hope I’m not in that group, but I recognize that it’s a possibility. We never know when our situation will change, or our employer’s situation will change. That is one reason I recommend you keep your resume up to date and continue to work on improving your skills.

    I saw an office hours short recently from Brent Ozar, in which someone had asked him if they should apply for a job even though they didn’t meet all of the requirements or know all of the desired technologies. Brent recommended the person apply, and his reasoning was that often a DBA (or other data pro) often gets asked to do a variety of tasks in an organization. The DBA job often crosses lots of boundaries and may end up working on a Active Directory issues, reporting, ETL, and more. When A DBA leaves a job, the organization looks for a replacement that can handle that same wide variety of things.

    I think this is good advice, and I usually tell people that if you meet 50% of the requirements, apply. Part of this is Brent’s reasoning, part of it is because I’ve had to write job descriptions, part of it is because I’ve interviewed people. While we often have a standard description, usually I then think about how our technology matrix has changed over time and add items to the job description. If I ask another employee what else we might need in a candidate, more requirements get added. At some point, the job description isn’t realistic anymore and it’s unlikely we’d ever find a person that meets 100% of our desires.

    The other thing I’ve learned in interviews is that sometimes a candidate impresses us and makes the interviewer think about the position differently. Maybe the candidate is impressive enough in some areas that we can ignore their deficiencies in others. Sometimes the candidate might say something that causes me (as the interviewer) to pivot the job slightly to address other possibilities I think of at that moment.

    Job hiring isn’t a meritocracy. It’s a mix of many things, often depending on what the interviewer thinks at that time, how the candidate impresses them, and maybe some restrictions on who they can hire. I’ve seen companies that won’t hire developers without a CS degree, regardless of experience. I’ve seen situations where the hiring manager creates a new position because the candidate is so desirable. I’ve sometimes chosen a weaker technical candidate over a near expert in an area because of soft skills.

    There are lots of variables, and you can’t control them, but you can control a few things. You can work on the way you communicate with others and improve your skills, both verbal and written. You can also showcase your ability to learn and adapt, whether that’s with stories and examples or a blog that you can point to, documenting the work you’ve done on your skills.

    This is a tough time for many tech professionals, but it’s also a time where there are many open positions in lots of companies. Part of this is an mismatch of candidates and opportunities not finding each other. Part is a more discriminating approach from companies who don’t just want people, but talented people, talented in multiple ways including soft skills.

    You never know when you’ll need a new job, so make sure you’re prepared to impress others. Make sure you spend time on your career on a regular basis.

    Steve Jones

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

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

  • Labor Day 2024

    It’s Labor Day in the US, the traditional end of summer for me as a kid growing up in Virginia. This was the last day of summer before school started for me. It was also the day when many of the seasonal businesses closed in Virginia Beach.

    It’s not quite the end of summer for me, but it is a day of Labor. Travel and a strange weather pattern this summer have me behind on ranch chores, plus, the ranch manager AKA my daughter, is on vacation. Today I’ll handle the horse chores and then start fixing, building, and more today. There is always plenty to do, and as my daughter has taken over much of the day-to-day ranch management, she continuously sends me a list of things that need repairing. She’s happy to help, but I have to go over how to accomplish some tasks that she’s never done.

    Hopefully it’s a quiet day for those of you working in technology, with no outages or security incidents and you can start the week slowly.

    For those in the US, hopefully you have a great day off and enjoy a break from your labors.

    Steve Jones

  • Trying New Technology

    I had someone ask me about DuckDB recently. Would I think that’s a good choice for a database? I don’t really know. From their blog and some online research, maybe, but it’s also a minority player in a niche space.

    I had a chat recently with someone that had implemented ArangoDB, a graph database. Why that and not Neo4J I asked them? Someone at the company had tried the database and recommended it. Not a bad reason, as I think experience with tech is important, but it’s not the most important thing.

    As I’ve aged, and maybe matured, I think less about the ability of a technology to work and more about the ability of a technology to be maintained over time. Not by me, but by everyone in my organization. Not everyone, but can anyone working on our staff learn and use it, including the future employees we haven’t yet hired.

    There seem to be no shortage of new niche technologies. I have a few newsletters I subscribe to, and I see new projects and new solutions appearing every day. New tools, utilities, frameworks, even databases. Some of these might be amazing, and incredibly useful, but will they exist in a few years? In fact, that’s a question I ask myself about plenty of Microsoft technologies that appear. Will they really be around in 5 years? Long-term, or at least medium-term, supportability is important.

    I also worry about the training and learning required for new technology. I’ve seen companies that adopt too many products in their tech stack and it becomes hard to hire experienced people. Even if we hire smart people that can learn, we have a lot to teach them. The more we need to teach, the slower they are to be productive. It can be even slower for us to trust them to work independently, especially in a crisis.

    I think that most organizations should limit the number of technologies they use. This could be frameworks, languages, and more, including databases. Don’t add something new just because a developer, DBA, or even executive likes it. Certainly, be careful about changing technologies when the change isn’t adding value to your organization. Every change has costs, every new advantage contains a disadvantage, and every additional thing creates training requirements. Some people might pick things up quickly, easily, and during their off hours. That person might be you, but how many others will be able to do that?

    Not many. That’s been my experience. The world is full of average people, by definition. While the average level (skill, capability experience, etc.) at your organization might be higher than our industry, over time, that will change. As our organizations grow, and as we change staff, we often become more average.

    Our choices, and methodologies, our architecture, and more must survive the average employee, not the high performing ones.

    Every organization ought to limit tech choices. There ought to be a process and way to add new technologies, and employees ought to be able to submit a request, make a case, and have others decide if taking on a new technology makes sense. If so, great, but do so carefully.

    I like seeing new technologies built and adopted, but I also try not to just adopt the latest shiny things. Experiment, in a time-boxed fashion, and make decisions when appropriate, consciously because the benefits outweigh the costs. And not just slightly outweigh the costs, but substantially. In all likelihood whoever proposes the new tech isn’t thinking about the downside, and there will always be more downsides than you can see right now.

    Steve Jones

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

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