September 9, 2015 at 12:00 am
Comments posted to this topic are about the item Working with People
September 9, 2015 at 6:51 am
I wholeheartedly agree with you, Steve, on getting along better with our peers at work. Friction between DBAs and the rest of the world is so commonplace, I almost think it has become a truism. I am a developer, but I have worked as a DBA, so I have seen both sides of that fence.
What drove me to respond, however, is the statement that we should:
perhaps...learn a few things about ourselves and how we might adjust our own personality"
Wow. Saying that is, IMHO, extremely incisive and wise. Just like the x-step programs that purport to help people through difficult times, it is widely recognized that self-reflection is an integral step to making our lives better.
I have also heard that the things we detest in others are the things we subconsciously loathe about ourselves. If that's true, then perhaps many DBAs are in need of some reflection and meditation. 😉
In all seriousness, between my stint as a DBA and today, I have made small improvements to my thinking and my interactions with others. I feel that looking within ourselves is a very important first step to a less stressful workplace. Thank you for laying that out in your blog.
September 9, 2015 at 6:52 am
Working with personalities that clash with mine, well I find it exhausting. I am always trying to remember to just pause before speaking, take an extra breath. But I still find myself having to say something like "That wasn't an attack. I was just responding to your statement." That kind of caution stifles the passionate and productive discussions I have come to enjoy and even rely on in IT. To now have to tiptoe around I believe is counterproductive and a disservice to the company I work for. But to keep peace in the workplace I just shut up.
September 9, 2015 at 7:16 am
I think the problem is this:
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.
The idea that developers don't extensively do code reviews or test their work while the other does is a hallmark of why there is conflict to begin with.
People will always be difficult to work with if they always take the approach that they are doing something better than the others even if that's not the intention.
September 9, 2015 at 7:23 am
xsevensinzx (9/9/2015)
I think the problem is this: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.
The idea that developers don't extensively do code reviews or test their work while the other does is a hallmark of why there is conflict to begin with.
People will always be difficult to work with if they always take the approach that they are doing something better than the others even if that's not the intention.
+1
I think you nailed it. 🙂
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
September 9, 2015 at 8:06 am
Many developers want their changes to be deployed quickly, while DBAs want extensive review and testing to be sure that no problems will occur.
I agree that this is inflammatory and only makes things worse. As does the back and forth accusations when something does go wrong. But the reality is that developers are far from the only people that DBAs have a reputation of not getting along with. Further, developers have the same reputation for good reason.
One thing that both DBAs and developers need to get down to is that their real job is to make other people's jobs possible and/or easier. Both need to focus on the main shared problem of providing service. And that those requests for change are NOT the enemy, but rather continued employment opportunity.
September 9, 2015 at 8:50 am
I suspect it's simple ignorance on both sides.
DBAs don't really get it. Developers are all about problem solving. The problem is, developers don't *fully* understand the importance (and difficulty) of maintaining data integrity at the database level either.
I have the curse and the blessing of being the only IT person where I work, and thus I am (among other things) both a DBA and developer.
As a result I think I have a unique advantage over most developers in that I can see (and develop) both sides of the divide, and I have to be the one to decide what the database does and what the front end does.
As a result I'm a FIRM believer in letting the database do all the database work, like referential integrity, business rules (about the data) and basically having the final say on when the persistent data changes.
The front end, well, that's for everything else. 🙂
Of course that means I get to handle all the complexity of both sides, which sucks, but it has put me in the "horses for courses" camp.
After all, garbage in, garbage out, right? And if your data is garbage, you're running a dump, not a database, and the application is just a garbage truck!
September 9, 2015 at 8:53 am
james.jensen1350 (9/9/2015)
Wow. Saying that is, IMHO, extremely incisive and wise. Just like the x-step programs that purport to help people through difficult times, it is widely recognized that self-reflection is an integral step to making our lives better....
Thank you for laying that out in your blog.
I really try to "know myself," for better or worse. Recognize the things you do well or don't do well, or affect you positively or negatively. Whether you can change (or want to) is something else, but at least recognize things.
September 9, 2015 at 8:54 am
Iwas Bornready (9/9/2015)
Working with personalities that clash with mine, well I find it exhausting. I am always trying to remember to just pause before speaking, take an extra breath. But I still find myself having to say something like "That wasn't an attack. I was just responding to your statement." That kind of caution stifles the passionate and productive discussions I have come to enjoy and even rely on in IT. To now have to tiptoe around I believe is counterproductive and a disservice to the company I work for. But to keep peace in the workplace I just shut up.
Ditto. However it's a fine line. You don't want to be too quiet and passive and allow yourself to get moved to situations or positions that don't fit.
September 9, 2015 at 8:55 am
kiwood (9/9/2015)
One thing that both DBAs and developers need to get down to is that their real job is to make other people's jobs possible and/or easier. Both need to focus on the main shared problem of providing service. And that those requests for change are NOT the enemy, but rather continued employment opportunity.
Very true.
September 9, 2015 at 8:57 am
xsevensinzx (9/9/2015)
I think the problem is this: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.
The idea that developers don't extensively do code reviews or test their work while the other does is a hallmark of why there is conflict to begin with.
People will always be difficult to work with if they always take the approach that they are doing something better than the others even if that's not the intention.
I didn't mean to imply developers don't test code or haven't reviewed code. I was merely trying to state developers want their work to be seen by customers. I agree with what I heard Dave Farley say "your code isn't done until the customer sees it."
Developers may well be moving at the correct pace, having tested and reviewed and anything else. It's that DBAs often want their own review, and for good reason. They ultimately bear responsibility for issues in the database. The idea in DevOps is that both work closely together to ensure fast deployment as well as thorough review.
September 9, 2015 at 9:38 am
Steve Jones - SSC Editor (9/9/2015)
xsevensinzx (9/9/2015)
I think the problem is this: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.
The idea that developers don't extensively do code reviews or test their work while the other does is a hallmark of why there is conflict to begin with.
People will always be difficult to work with if they always take the approach that they are doing something better than the others even if that's not the intention.
I didn't mean to imply developers don't test code or haven't reviewed code. I was merely trying to state developers want their work to be seen by customers. I agree with what I heard Dave Farley say "your code isn't done until the customer sees it."
Developers may well be moving at the correct pace, having tested and reviewed and anything else. It's that DBAs often want their own review, and for good reason. They ultimately bear responsibility for issues in the database. The idea in DevOps is that both work closely together to ensure fast deployment as well as thorough review.
I know you didn't mean it that way, but it's pretty common for DBA's as well developers to imply similar thoughts about one another. 😉 It just doesn't help continuing to emphasize it in that context.
Unfortunately, I disagree that code is not done until the customer sees it. Many bankend developers are just that, on the backend lurking in the dark corners where customers don't dare go.
Ideally, the issue is that both sides fail to understand the importance of one another. It's not one side getting it more than the other. It's a failure on both. DevOps is just the band-aid to bridge the gap.
September 9, 2015 at 9:39 am
kiwood (9/9/2015)
One thing that both DBAs and developers need to get down to is that their real job is to make other people's jobs possible and/or easier. Both need to focus on the main shared problem of providing service. And that those requests for change are NOT the enemy, but rather continued employment opportunity.
Excellent observation! However, I have observed that the management structure often doesn't reward (and even penalizes) good service.
A developer may be chastised in some fashion for code deployment being late. The late deployment reflects on the rest of the development team and whatever business group is counting on the functionality. But is the developer also chastised for deploying database code that slowly and insidiously messes up the database in some fashion (integrity, performance, storage)? Probably not. Guess who gets in trouble for that? The DBA group (ie, the DBA's manager).
Meanwhile, the DBA (and the DBA's manager) bear no responsibility for a delayed launch. What's their reward for helping the developer get the code out faster? More risk for the DBA! And are they penalized for a late launch? No, that's the developer's fault.
Do you see where I'm going with this? Most people are working within the incentives they've been given by their immediate management because they value continued employment. It's a rare manager who positively recognizes an employee who is doing what is best for the company but not best for their group.
And I'm not blaming the first-line managers for this state of affairs. They also have managers who set incentives (formal or not) for continued employment. It's my opinion that structural management problems go all the way to the to top, every time. Even if there's a middle-level manager who is clearly incompetent and causing problems, the real responsibility (to let that person go) goes all the way to top. Every time.
Corollary: Just because the responsibility for problems goes all the way to the top doesn't mean one should say so to the people at the top. I have observed that that practice is NOT compatible with continued employment.
September 9, 2015 at 10:16 am
I think the real point was about difficult people, and how to work with them, and how not to be one of the difficult People. There are valid reasons why DBA's insist on data quality. They are the first ones to get called when there is a problem. And the ones who often have to fix the problem.
So, if there is a professional reason to hold your ground, then do so. And if someone has a legitimate reason to push back, don't be a jerk about it, but respect that position.
The more you are prepared, the less you need it.
September 9, 2015 at 10:23 am
Andrew..Peterson (9/9/2015)
I think the real point was about difficult people, and how to work with them, and how not to be one of the difficult People. There are valid reasons why DBA's insist on data quality. They are the first ones to get called when there is a problem. And the ones who often have to fix the problem.
The developer is usually the first one to get called here, and usually the one to fix it, unless it is actually a problem in the way the database was set up.
At least where I'm at this is how it works.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply