Category: Editorial

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

  • A Kafka Introduction

    I’ve heard of Kafka before. I know it’s an Apache project and you can download or read more at https://kafka.apache.org/. I knew it was a way of moving data around, some sort of ETL tool useful for moving things around. More like a message and queueing system, which is a tool that seems like a great idea, but one that everyone struggles to work with.

    And one that seemed complex. The overview is that Kafka is “a distributed system consisting of servers and clients that communicate via a high-performance TCP network protocol. It can be deployed on bare-metal hardware, virtual machines, and containers in on-premise as well as cloud environments.”

    Would I need that or use it? In a lot of my database work, I’m not sure that it would easily fit into most of the OLTP applications or data warehouse systems. Maybe. Hard to tell. Their description of event streaming and the definition of an event make it seem this is a catch-all system for moving log data around. One that be so open-ended that it ends up requiring a lot of configuration for “my” system.

    Here’s their definition of an event: An event records the fact that “something happened” in the world or in your business. It is also called record or message in the documentation. When you read or write data to Kafka, you do this in the form of events. Conceptually, an event has a key, value, timestamp, and optional metadata headers.

    Recently I watched a Kafka presentation at THAT Conference (which was a fantastic event). In the talk, this sentence caught my eye: “[Kafka is] a pipe to move data from A to B, C, D”. I’ve certainly had that need, and sometimes configuring lots of pipes is work. If you’ve ever worked with replication and the publisher/subscriber model you likely get a twitch in your eye if a ticket is opened to configure a new subscriber. Not because the configuration is hard, but because the ongoing admin can be a pain.

    The talk dives into some of the complexity of designing and implementing a Kafka system. For developers that might write to the stream or read from it, things seem simple. For admins and architects, less so, and I can’t help what happens when a reader goes down. I have nightmares of replication subscribers being down and transaction logs not being reused.

    Kafka doesn’t seem as complex as I thought before, but it certainly doesn’t seem simple or easy. Kafka is not a panacea for moving data around, but it is a well-understood and widely used technology. Those things mean more to me now that I find myself considering the challenges of maintaining a system over time and hiring staff who understand it. It’s something I’d consider using in the future, and maybe something I’d like to experiment with a bit more and learn how it works at a more practical level.

    If you use it, or know more, I’d be interested in how well Kafka has worked for you, either as a developer or admin.

    Steve Jones

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

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