Five Rules For Sucessful Conversations With DBAs

  • Very nice article, I enjoyed reading it. Thanks much.

    Hakim Ali
    www.sqlzen.com

  • Thanks Andy! Indeed, that is already in the works.

  • Drew Copenhaver (9/24/2013)


    I don't often comment, but I absolutely loved this. I wish I'd had it a year ago. I mostly just spend my time lurking in the shadows of this strange and forbidden land, stealing secrets.

    By which I mean: I'm a developer who has started to learn SQL and a bit of database development. I absolutely love it and wish I'd had time for more formal training during college, but that's life. The things you've said here make a lot of sense and I had to learn them (fairly quickly) over the course of the a few months as the DBA is our only other SQL guy. Personally, sitting on the other side of the table (pun intended) from most of you guys, not all developers are evil, database-wrecking monsters. For us it's about providing the customer with the best product they can have, but working well with the DBA and not asking stupid questions or involving managers is the right way to do things. Then again, maybe my experience with SQL has made me a little more protective of the data.

    Good for you Drew! You sound like the kind of developer who I used to like to work with: hard-working, eager to learn, and understanding of our job. Keep up your learning and your good attitude and you'll do just fine interacting with most DBAs. 🙂

  • Cracking article Joshua....

    🙂

  • Awesome write up!!!

  • Joshua Feierman (9/24/2013)


    Drew Copenhaver (9/24/2013)


    I don't often comment, but I absolutely loved this. I wish I'd had it a year ago. I mostly just spend my time lurking in the shadows of this strange and forbidden land, stealing secrets.

    By which I mean: I'm a developer who has started to learn SQL and a bit of database development. I absolutely love it and wish I'd had time for more formal training during college, but that's life. The things you've said here make a lot of sense and I had to learn them (fairly quickly) over the course of the a few months as the DBA is our only other SQL guy. Personally, sitting on the other side of the table (pun intended) from most of you guys, not all developers are evil, database-wrecking monsters. For us it's about providing the customer with the best product they can have, but working well with the DBA and not asking stupid questions or involving managers is the right way to do things. Then again, maybe my experience with SQL has made me a little more protective of the data.

    Good for you Drew! You sound like the kind of developer who I used to like to work with: hard-working, eager to learn, and understanding of our job. Keep up your learning and your good attitude and you'll do just fine interacting with most DBAs. 🙂

    Thank you! ^_^ I do my best to be easy to work with as a developer. I know tech people and geeks are stereotypically hard to work with and I've seen the industry slowly turn some really wonderful, charismatic people into truly difficult curmudgeons, so I do my work as hard as I can to be easy-going.

  • I'm with the other Poster who said 'Collaboration' could be moved to the front.

    DBAs often have the unfortunate position of working on two staffs, Dev, and IT. And often those are quite separate structures in companies. They have to know something about the application, and help diagnose issues such as performance. But unless they were 'collaborating' with the Dev staff up front, they could be handed a mis-designed DB.

    It's important to give them credit for having one foot planted in both camps, and potentially getting split down the middle if something isn't going well!

    It is also important for every company to decide what the "A" really stands for. Is it simply "Administrator" or is it "Analyst" or is it both? Some companies do maintain expertise within a Dev group for example, some don't. Be clear on your understanding, else you might be asking a DBA for things they did not sign up for! In some IT groups they might really only be responsible for backups, installs, and some maintenance scripts, and don't go near the application level.

    Get management in line with what the expectations are.

  • "...believe me, as a DBA I definitely let the nice people get away with more than the not so nice ones..."

    This mindset would result in your termination at every place I've ever worked. Either you are running your business upon standards, and within compliance frameworks, or you aren't.

  • I admit up front I'm an entry-level DBA type. I love this article for so many reasons. First, it suits my mentality and that's one of the main draws towards becoming a 'real' DBA. No, not to be an a$$ but the tinckering and problem solving are too much too resist.

    Second, in that occupational crossover and for the past 15 years, I have had to deal with numbnuts who insist their way is best. More so now as I am not yet established in my new job. There are more reasons, but suffice to say people need to practice substantive logic when they approach a new or changed operational plan.

    Thanks for a great article, I had to share it!

  • If you think you know, then you have become ignorant; you have stopped your own evolution. I agree with most of the above posts: collaboration is number one.

    Recently people have been asking me about how they can solve their communication problems. The best successes are always when both people evolve into a new solution neither has experienced before. This requires both sides to work and change before an emergent idea can solve a new problem. If you can't get the other person involved, then still work on your own evolution.

    My best lesson was from Temple Grandin's book "Animals in Translation": always look for the way to give the fewest rules and still control only what is important.

    Allow as much freedom as possible. Let developers shoot themselves in the foot as long as they can't shoot someone else in the foot.

  • Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.

  • eddie.caplan (9/24/2013)


    Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.

    Agreed. This article is the only 1 star I've ever given on this site.

  • Great article and good learnings for anyone that want to take note I believe. In a role as a project manager I've learned to treat experts in their respective disciplines such as DBAs and SysAdmins in a special way and it always pays off. The customer is not always right, in fact its become the norm for customers to abuse customer service reps on the basis of the "Customer's" expectation (often self-serving) of how a customer should be treated. There lies a lot of truth in "treating others as you would like to be treated" instead of "respond to others how they treat you and then some more for good measure to teach them not to mess with me". IT has many colourful, opinionated, eccentric and all the other labels type of people that the perfect people love to use to judge and describe some of these IT folk. We all have our little pet hates and buttons that can be pressed, get our backs up and put us on defense. Pressed too often by someone expecting "I am the customer and I must get what I want" treatment its actually quite easy to adopt defensive strategies to make the irritation go away and get on with the important stuff.

    Our jobs align with our personality types (another label) and influence our behaviour and any insight from people who have 1st hand experience from both perspectives, as the writer of the article has is, is valuable for consideration and application. Good on ye Joshua for sharing some great insights that very likely the majority of us will consider as valuable.

  • Thanks for a great article!! It is very "touching" :-D.

    In the book "DBA Survivor: Become a Rock Star DBA" by Thomas LaRock, I have read about why DBAs and developers (or actually everyone else) always had arguments. Fundamentally, everyone else don't understand what are we , DBAs, doing. Since everything else that they have control "seems" to be correct, therefore one would start to look at the area that they don't have control. It maybe first starts with 'can you help to check if that is running OK?', or it could turn into 'it must be your fault', depends on the individual.

    Developers don't understand database and how database works (yeap, even some SQL developers, I have to say). Our domain is a dark side for them without much clarity. I would not expected that they will try and gather data/evidence to support their claim, because if they do know how to do that, we are so close to the solution already, and we don't have a job anymore. The same way, we don't understand why they need to work in a particular way to utilize our database from their application.

    Therefore, I think we, as both sides, need to be more tolerant to your fellow workmate. Keep in mind that when one side started to shout, you can't expect the other side would take it silently. Rather, there is a problem to fix, let's fix it together.

    ______________________________________________________________________________________________________________
    Common sense is a luxury - not everyone can afford it.

  • Eric Higgins (9/24/2013)


    eddie.caplan (9/24/2013)


    Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.

    Agreed. This article is the only 1 star I've ever given on this site.

    I haven't, don't and won't consider Developers as supplicants. That is absurd. All I ask for is equality when discussing common themes to achieve a common goal. I understand the architecture and protection of data better than the developer and the developer understands the code and means to achieve his/her aim better than I do.

    That is the reason both parties need to come down off their high horses and understand the need for mutual respect not only for the person stood in front of them but for the skills they bring to the table. The only people that seem to think supplication is the answer are the people that consider themselves to be the centre of everything that is important to the company. Another absurd concept.

    The person that feels the only way to make a point is to shout the other person down is the one whose own self-confidence and knowledge is so meager that they can't construct arguments to make a valid point.

    I close the door on those people.

Viewing 15 posts - 31 through 45 (of 76 total)

You must be logged in to reply to this topic. Login to reply