9

What is the recommended way to handle with a co-worker who just constantly "preaches" his answer and does not "seem" to view the point of the view of others.

My goal is to figure out how to

  • get this co-worker to just get to the point in his explanation without the fluff
  • when listening to other people's view (either in meetings or code), to also think about what the other party wants. I have other developers who get frustrated working with him or submitting code to shared code repos in which he is the maintainer because it seems to be basically either his way or no way.

Some situation examples

PM: Can you please give me a estimate for feature A?

Co-worker: begins a whole rant about the validity of estimates, why they can't work etc for the next 10 min.

or another

Dev: (in a pull request) I would like to add feature A into this shared library (which co-worker maintains)

Co-worker: Writes a 5 paragraph reply on the philosophy of the shared library and why feature A does not fit it.

My relationship with him is a partly has both a dev lead and a collegue. My role as dev lead though our company tends to maintain a "flat" hierarchy. I personally tend let him to his own devices because he is far more senior/knowledgeable than me as a programmer and he still does deliver results but it a manner where none of the other developers are able to contribute or require a huge learning investment in it.

In general, I do appreciate the point of view that this co-worker provides because he is one of the few developers who is experienced enough with larger systems. He comes from a system admin background but joined our company to get into more app development.

It has caused tension during planning meetings - it could be a culture difference where he came from a more structured sysadmin environments and majority of developers come from where things need to get done fast instead of slow and right. It is a philosophy/culture that I am slowly changing while still keeping in mind that we still have to deal with deadlines that are mostly cannot be shifted for various reasons.

I hope this gets the point across - I know what I want to achieve with this question and what the situation is like. I just can't figured out what is the proper "term" for this.

  • 3
    Welcome to The Workplace! Is there any chance you could make an edit to focus more on what your goal is? It doesn't sound like you're his manager, so explaining what your position is in relation to him, what interaction it is you personally are having trouble with, and what your goal is when dealing with him, it would help get much better answers. Your question as it is seems more like a rant than a practical answerable question and may be put on hold, which is why I suggest the edit. Thanks in advance! – jmac Jan 20 '14 at 8:47
  • Assuming the common usage of the term, you shouldn't be asking one guy for an estimate on an entire feature. – Grimm The Opiner Mar 28 '17 at 14:25
13

I'd like to answer your question from the other side of the fence.

Let's start with this:

...he still does deliver results but it a manner where none of the other developers are able to contribute or require a huge learning investment in it

Why is it that working on his code requires a huge learning investment? Can it be that the "fluff" you want to get him to cut out is actually the things he's trying to tell you to ease you into being able to work with his code. Be honest, has the rest of the team put much time and effort into learning the concepts behind his code?

Regardless of whether you have or haven't you have to realize that if you have a good understanding of how to write good code, it's not possible to write crappy code that less-capable teammates will be able to understand. Even if you try, you're not going to be able to guess what crappy practices they'll understand/agree with and what crappy practices they'll also think are crappy. I say this from experience.

Possible solutions are

  • Not to have a more-capable teammate
  • The more-capable teammate has sole ownership of the code
  • The rest of the team needs to raise their skills

...he came from a more structured sysadmin environments and majority of developers come from where things need to get done fast instead of slow and right.

This is a misunderstanding on your part. Unless the project is only a few days (like 2), good code will always trump bad code for speed of development. I suspect your team just hasn't let him have his head enough where this is apparent, or you're willfully not noticing it (I had this problem with my boss).

MPO is that, since he has more experience than you do, you should turn this around and make sure you're fully hearing what he has to say. I know a lot of time I make recommendations based on the gut feeling of many years of development and I can't always articulate why one approach "feels" like the right thing and the other "feels " like a complete mistake. Ask probing questions and get those things articulated.

He might be dismissing the opinions of others because his experience tells them that they're wrong (but he's too polite to tell them or just doesn't see the point with people who don't listen anyway). It's also possible that your other team members aren't articulating their own positions particularly well. If he's left to choose between his own position, which he understands, and a position that doesn't offer advantages that are clear to him, then guess what he'll do? I know I'm more than happy to bend or compromise when someone gives me a clear argument that shows me where I'm wrong or could do better, but "that's not how we've always done it" doesn't get very far with me.

  • Thanks to all for your reponses. This one has been best one that helped me develop my position on the mattter. At the same time it seems to be a case of that because he has more experience/knowledge we should just follow what he has built and to accept his opinions as gospel. At the same time my thoughts are if we still need to evaluate if it fits the project from other points of view in the team. I will try to balance those two. – user13799 Jan 21 '14 at 5:29
  • 1
    My answer is that everyone involved needs to be better at articulating their position and listening to others. You can only do your side of it--make sure to ask probing questions and make sure to give valid reasons for your side and make sure he addresses them. – Amy Blankenship Jan 21 '14 at 17:25
2

"submitting code to shared code repos in which he is the maintainer"

You should immediately incorporate Collective code ownership, it's a practice from Extreme Programming, see wikipedia. Having someone "own" the code is never a good idea, the knowledge and sense of responsibility should be put on a team, not a person.

"begins a whole rant about the validity of estimates, why they can't work etc for the next 10 min."

He is right, you know. Estimations are extremely difficult, but since they are necessary, you should instead look at collective estimations by playing planning poker or something similar. That way a group will work together to provide an estimate. They tend to be more accurate and also shares knowledge regarding the new feature.

  • 1
    Oh, pish. It's possible to produce accurate estimates if your codebase is clean. – Amy Blankenship Jan 20 '14 at 15:01
  • you should instead look at collective estimations by playing planning poker or something similar And I would be (well rather the PMs) would be happy to do that if he had suggested it instead of simply giving that rant each time. But I make give the PMs a nudge to try that. – user13799 Jan 21 '14 at 5:18
  • 1
    You should immediately incorporate Collective code ownership - what a terrible advice. This never works and there should always be one person who makes the final decision. – red-shield Jan 23 at 6:48
2

I have gone through similar kind of situations where I have had to deal with a preacher of code. Here is what I would suggest:

  • Have a talk with your manager about the possible delays being caused due to the attitude.
  • Don't make it look like a complaint. Instead put it in a way that the manager understands that the attitude is causing difficulty for others.
  • Since the colleague is a senior in terms of programming experience, I don't see how you can directly speak to the person concerned. Hence the apprehensions have to be routed via the managers.
  • Also, sometimes he might be actually adding a lot of value to the team by providing inputs, do listen. Don't dismiss everything.

Remember it's not your job to correct him. You can only act as a messenger regarding the possible conflicts in the team due to the behavior.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.