Voice of the DBA

Category: Editorial

  • The Team You Want

    Brent wrote about what a good DBA looks like and challenged people to write a testimonial for them. There are some great comments on the post, and some funny ones. It’s worth a read when you need a break from other work. I especially chuckled at the picture Brent used. I think ours was better.

    That got me thinking: what do I want in a team? Or maybe, who do I want in a team?

    I have a great team now, but we are fairly distributed and work independently. I have great co-workers at Redgate, though I don’t often work that closely with any of them. I work often with some of them, for specific things, but usually it’s coordination rather than the tight, back and forth I’ve often had with technical teams.

    I realized at some point in my career that I was often being asked to do the same work. I needed to manage systems. I needed to write and tune queries (or rewrite those for others). I needed to manage security. Most importantly, I needed to find solutions to the constant set of questions, problems, and demands from others in my organization. I learned how to teach myself things, how to research, how to test, and how to talk to others. I became good at clarifying what people needed and then finding a way to meet those needs. I think I turned into part of the Incredible DBA Team, even though often it was a team of just me.

    The characteristics Brent talked about were important to me.

    A little. I have always felt that I could work with others if they want to learn from me and teach me things. They have to want to collaborate and get things done as a team. That led me to worry more about who I worked with than what the job was. If the compensation was good, then the decision to take a job often came down to who would I work with. After all, the work was often very similar.

    Think about your situation. What do you want to see in your coworkers? I’m sure you want people that you get along with and carry their weight. Maybe you want to learn from them. Maybe you want to be able to teach them. Maybe you have specific skills you wish were stronger on your team.

    Leave a comment and let us know what your ideal team looks like. As always, if you want to leave an anonymous comment, send me a PM on the site with what you’d like posted in the discussion.

    Steve Jones

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

  • Rogue Colleagues

    The economy might be good or bad for you right now. Some of that depends on where you live, what your employment situation is like, what your habits dictate about how you live life, and more. No matter what your situation, likely there are people around you that complain about the world and others who think things are fine. There are likely more of the former than the latter, but that’s because humans tend to complain out loud more than they praise.

    When people think there is an economic downtown for themselves, they may be more likely to engage in malicious activities. While I don’t think most data professionals will start to hack other systems, or even their own employer’s systems, there is evidence to support the idea that some might be susceptible to recruitment by bad actors. This piece references some research and warns security groups to be wary.

    There is no shortage of books, or television and movie scripts that might show creative ways to access information, but how can you tell if a colleague makes a simple mistake or they are a bad actor? Clicking on a phishing email could be either one. Not removing anonymous access to an S3 bucket could be either. Losing their credentials through social engineering is something that happens every day. Who’s to say that this happened purposefully?

    I don’t want to second guess the people I work with making mistakes, but I also think these possibilities are why we want to use our computer systems with strong auditing and multiple groups reviewing logs. We might not necessarily stop all activity, but we can often detect it quickly and mitigate the issues. It’s also why DevOps and automated deployments with logging are a good idea. They can limit the problems from both accidents and malicious actors.

    My employer has started to do more education around security and how individuals can avoid accidentally causing issues. We use a lot of automation, and more all the time, that ensures once we know how we ought to patch and update systems, we can do it regularly and confidently. Repeatable, reliable deployments of changes are what we aim for.

    We know they’ll be some mistakes, but we also know that we can quickly identify issues (MTTD) and fix them (MTTR). Even if we get a bad patch from a vendor, we can quickly deploy a “fix” if we get one, or even reinstall and re-patch to lower levels, if needed.

    DevOps, GitOps, and other xxOps aren’t just about getting new features out quickly. They also include the ability to fix problems when the need arises. They don’t prevent rogue actors from causing issues, but they should help you detect and recover quicker than you might expect.

    Steve Jones

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

  • Looking Forward to the PASS Data Community Summit 2023

    I was lucky enough to attend the very first PASS Summit in 1999. It was a brand new event, and while not overly large, it was busy and crowded in the basement of a Chicago Loop hotel. I had the chance to meet Kalen Delaney there and ask her a question. That was the highlight of the trip, but I also learned a lot about SQL Server 6.5 and 7 there, spending all the time I could in sessions and hanging out after each one listening to the questions others asked the speakers.

    Since then, I have been lucky enough to go to most of the Summits. The event has changed a bit, and I look forward to going to see friends each year and re-connect with them. I’ve also loved meeting new people, often those I’ve corresponded with online. Each event has been memorable and exhausting at the same time. It’s a busy week, and I can sometimes feel overwhelmed. However, it’s always felt like it was worth the trip.

    I saw a video from Kendra Little where she talks about what she’s looking forward to this year. She has a few things on her mind: connecting with people, learning from the people who write the software, learning from those that use the software, broadening her horizons, and being a part of the data community.

    My thoughts are similar. Last year I was looking forward to the event in person, but apprehensive with all the commitments I had for Redgate with speaking. This year I’m much less involved, working more on things before the Summit and I’m hoping I can enjoy the experience more with less work during the event.

    For many years I was always excited about the SQL Server Central party. That was a highlight for me and I was sad when the referrals that funded it went away. Perhaps I’ll get find a way to get it back in the future. For now, I want to connect with more people. I want to do this casually in a few ways. From the #sqltrain on Sunday to a few quiet dinners with friends during the week to taking time at night to attend some of the events that various vendors will sponsor, that will be a great chance to bond with friends (new and old) in a social way.

    I also want to connect more professionally with people, which I’ll do in the Community Zone, as Kendra suggests, but also around the convention center. I am planning on not having to rush to many things, which means I’ll have more time in hallways and after sessions to talk tech with speakers and attendees. I’m always amazed by the ways some of you use databases and software, and I find myself learning creative solutions that I might suggest to others in the future.

    The last thing that I’m looking forward to is the chance to motivate a few more people to run SQL Saturday events in 2024. We’ve had some new events in 2023, a few more than 2022, but not nearly as many as we used to see each year. I’m hoping to connect with more community leaders and volunteers to try and get them to consider organizing an event in the future.

    The Summit is a great investment in your career as a data professional, and it can be a good investment for your employer. Make a case, show them you want to learn and grow, and that what you learn there will help you in your job. It’s a park for those of you that bring value to your employer and the can help with retention. You’ll gain knowledge and make contacts that help you on a daily basis.

    I hope to see you in Seattle this November.

    Note: The price goes up Sept 20, so get registered before then.

    Steve Jones

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

  • The IT Jobs AI Can’t Do

    This was a provocative title: 6 ITOps Skills That Will Never Be Automated. In a time when AI use is growing quickly and many people fear for their jobs, it’s nice to see someone writing about areas that AI will struggle to handle.

    Ironically, lots of these articles are written by writers without much technical expertise and who are more likely than others to struggle in the age of AI. If a computer can mimic styles, less writers will be employed. That might be fitting with so many journalists hyping technologies without really understanding them, doing so in a way that creates stress among actual IT professionals.

    The article lists 6 jobs: policy config, incident response, complex scaling, app feedback, ITOps tool deployments, and end-user support. Of these, I’m not sure that app feedback and end-user support are good-paying jobs that many people want, but I know there certainly are people working in these areas who depend on those jobs.

    The others are often jobs that few people do. I do think that these are complex jobs where a computer can’t really take in enough information to do a great job here, but I do think that one smart worker could learn to guide an AI that does a lot of the busy work. Someone could specify a policy from an AI and then ask the AI to tweak it as holes or gaps are identified. I think over time a lot of quick incident response items could be handled by an AI, albeit with a human guiding it. Again, that reduces the need for humans in these roles.

    To me, that’s where the AI revolution becomes scary. AI is a lever to get a lot done. Fewer humans can be used to accomplish tasks with the aid of AIs, which reduces a lot of the labor needed. After all, we know that in any area, there are lots of beginners and advanced beginners doing work. If we can use an AI assistant to help one or two humans, we might remove the need for a dozen others.

    Maybe that’s what a future 10x engineer looks like. Someone that’s way more productive than many others because they’ve leveraged the computer (in the form of an AI) to get a tremendous amount of work done.

    I do think there are likely jobs that AIs can’t easily do, but I also think that a lot of the work in these areas might get copy/pasted between organizations. Policies, scaling choices, and more are things that one human might learn from others and mimic those efforts. With better judgment than an AI, but not as much as if a true expert were coming up with the best solution for a particular situation.

    Unfortunately, most of us don’t come up with optimal solutions, and our organizations run fine with sub-optimal code/policies/decisions/whatever. Will companies get by with very few highly paid people or a few more low ones and accept mediocre software?

    That already happens far too often already. I suspect like most trends, we’ll see quite a few organizations move in this direction. However, I think the human ingenuity will win out and as a few companies realize that the creativity of humans can better target their goals than an AI that merely summarizes other work, the pendulum will swing back.

    Unfortunately, a lot of people will get caught in bad situations as this happens. Work on your skills, technical and soft, and be sure that you are in the best position you can be in as the world embraces and evolves with AI technology.

    Steve Jones

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