Voice of the DBA

Tag: career

  • Who’s a Good Developer?

    I hear people in all industries and careers say that all of us should hire the best person for the job. We should pick the most qualified person and engage their services. However what’s left out of most of this advice is the most important question: how do you measure the best?

    We talked about this recently in a DLM Workshop led by Ike Ellis. He asked the question: how do you tell who’s a good developer? Think about it for a few minutes. I’m sure you (think you) know who the best developer or DBA is in your company, but how do you know? What’s the measure?

    I suspect you’ll find it to be a very abstract idea. Perhaps it’s like pornography, where you know a good developer when you see them, but if so, then have you always been able to tell a good developer right away? In an interview?

    Embedded in the idea of determining who’s good and who’s not is the idea of ranking. Is there any way to rank one developer over another? I think you might be able to do so, but only in broad ranges. We (as a group) might feel Developer A is better than Developer B, but not necessarily better or worse than Developer C. However, do we have any way of ranking these two that would stand up to outside analysis?

    I don’t have any great ways of measuring one developer v another. A best I think you can trust a developer to get a particular project done, and to the satisfaction of the client. However the trust would be based on previous experience and not any objective measures.

    This isn’t likely to be a problem that we will solve anytime soon, in any industry. I think the best way to gain confidence in someone is to examine their body of work. See how it matches up with the work expected from an individual and then cross your fingers, trusting they continue to perform as expected.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • Working with People

    Many DBAs have gotten the reputation of being difficult to work with. I think some of this is based on the impedance mismatch between developers and DBAs that seems to cause issues in many organizations. Many developers want their changes to be deployed quickly, while DBAs want extensive review and testing to be sure that no problems will occur. This prioritization of stability over enhancements by DBAs does make us seem difficult to managers, PMs, and no shortage of clients.

    As the job of data professional has morphed and matured, many of us that might have been strictly DBAs or developers in the past now often need to work with many other people. We find all types and ranges of personalities that we must deal with, and I would guess many of us find other people difficult to deal with.

    Learning to work with difficult people is a skill itself, and I ran across a piece that talks about a few ways that each of us might work with those we find difficult. Maybe more importantly, if we are perceived as difficult, perhaps we can learn a few things about ourselves and how we might adjust our own personality to work with others, or even perhaps we can give others ideas on how to best interact with us. The piece looks at emotional intelligence (EQ), which isn’t necessarily correlated to any other sort of intelligence, so don’t think a low EQ implies anyone is lacking technical talent.

    Our interpersonal interactions are important. As important as our technical skills, if not more so. Learning more about ourselves and learning how to better work with others are important skills for us that can help ensure we have an enjoyable, as well as successful, career.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Surfing

    How many of you have gotten up before dawn, driven to the coast, gotten on a long piece of fiberglass and paddled into the ocean before turning around to ride back to shore? It’s a great way to start your day, and I’ve been lucky enough to do this many times in my life. I look forward to getting back out there someday in the future.

    Surfing is an interesting sport, because you don’t really get to pick your path. You catch a wave, and begin riding it in, altering your course based on the speed of the water, the height and structure of the wave, and even the way the current is flowing. While you move in the direction you want, your choices are limited.

    This is unlike many other moving sports. While snowboarding you can stop or slow down. In many wheeled activities you can go in almost any direction. Much of the time you have more control over your motion, and can even take a break.

    However waves are unique. They’re few and far between. If you want to slow down, you end up really abandoning that journey, one you’ll never get again. If you paddle back, you’re hoping you’ll get the chance for another fun ride that day. That isn’t always the case.

    I saw someone post a note that working in technology is like surfing waves. As we learn and grow, we often feel that we can’t slow down, or change directions very much. If we’re a SQL Server DBA, we’re riding that wave. Trying to slow our career, or move to another technology means (often) abandoning some of what has worked well for us. We really follow the wave we’ve chosen as often as possible, usually resistant to change.

    You can change, however, and if you want to do so, make some plans and look for a new wave. It will take time; it will require some investment, but it’s possible. Always remember life is short, and we want to work in order to enjoy our lives with friends and family. We don’t want to get stuck working in ways that prevent us from enjoying our lives.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • The Road to Success

    I heard this quote recently from Dan Wood of Northwest Cadence. “The road to success is paved with cobblestones.” The meaning is that as we get better and gain success in those things we attempt, it will be a bumpy road. If you’ve ever driven (or walked) down a cobblestone road, you know what I mean. It’s not a path you’d want to take every day in a wheeled vehicle.

    In other words, we will make mistakes.

    In talking and teaching about software development practices, I think far too many people, myself included, become too concerned about mistakes. We worry about our code being perfect, or we struggle to implement newer features because we lack the confidence to try something new.

    This is one of the reasons I think moving to a well engineered software delivery pipeline is important. The ability to make changes to code quickly, run tests, and deploy smoothly is important. We will make mistakes in our programming. We will have bugs. Even as we improve our ability to write better code, we will make mistakes that we want to fix quickly. Having a smooth process that allows us to deploy new changes, as well as prevent old ones from re-occurring, will separate the great development groups from the average ones.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.7MB) podcast or subscribe to the feed at iTunes and LibSyn.