How do you work with a "difficult" developer? And what if that developer is you?

[TheOtherTimDuncan]

I'm the lead on a project and working with another experienced developer. For context, this project is .Net MVC and uses jQuery and does not use jQuery's deferred or any other promises. And for additional context, this developer and I have argued in the past regarding the use of javascript promises.

For a task that required an ajax request, he used jQuery's deferred. I asked him to remove it and stated the primary reason is because it wasn't used anywhere else in the site, and I wanted to stay consistent with the rest of the code. He has refused stating that I am telling him how to implement the code which is not right.

This developer and I have clashed in the past over similar issues, including a similar refusal. Part of my struggle is I've seen the cowboy mentality affecting other projects in my shop and don't want that happening on a project I'm responsible for. It doesn't help that I know I have OCD and can be a control freak. I keep waffling between giving up, accepting his change then quietly changing it back once he's off this project - an approach I've been taking. Or deciding enough is enough and now is the time to draw a line in the sand. Or accepting that I'm the problem and need to learn how to let this go.

We're a very small shop (7 developers), and I've already also reached out to the boss/owner (who happens to be offsite today) for advice as well.

Do you think I'm being too much of a dictator with my request? Do you have any suggestions on how to work with this developer?

[ghost]

Curious to hear back on how you handled this @TheOtherTimDuncan.

I was much like you for a period in my own career. Over time, I got out of that mode. Now I find it interesting to learn from the approaches other people take. Now, for me, it isn't about getting things done "my way". My way isn't always right, or perfect, as much as I would love to pretend they are. So I look at what might be better for the project and in the long run. To get personal, if a big swathe of developers you would hire later to maintain that code base would use stuff like deferred/other promises, then it would be better to go down that road now rather than later.

[TheOtherTimDuncan]

For the specific issue mentioned above, I ended up refusing to accept his approach, and he eventually changed his code as requested. But this problem to some extent has just gotten worse. I did eventually learn the mistake I was making in taking basically a passive aggressive approach, but I still struggle with this issue in general.

I think the best way to summarize my struggle today is how much value is there in having a consistent approach or style in a code base? And how do you define consistent? I sometimes have a much more junior developer working on my projects, and I've seen her struggle a little sometimes when she hits inconsistencies. I can tell she wants to pick the right way, but she can't always tell which to pick. The example above regarding promises to me is obvious that it is the wrong approach for consistency reasons, and I don't see it as a my-way thing. There's also the fact that as the lead I have to maintain and support this codebase. I hate having those conversations with developers new to the codebase where you have to say "Yeah, umm, well, sorry, don't use that piece of code as an example. Use this other one instead.". But how about variable names? For example, I have an interface named IStorageContext that is used a lot. The common C# convention for a private variable of this type would be _storageContext. And of course that's how the variables are named everywhere. Except in the code written by the same developer as above. He prefers _storage. Could this be defined as a my-way thing? Maybe. But I've also noticed when a different older developer (in his 50's) has worked on some of this code that he follows the existing naming conventions and has stated he tries to be consistent with what he sees.

In the end, I've come to the conclusion that a large part of the problem is respect and culture. I've realized that there is a distinct lack of respect at this shop, and worse, it is both ignored and possibly unseen by the boss. I'm very close to leaving this shop, both to try to find a team where I may fit better but also to try to learn by example how other places do things.

[ghost]

That's a very valid and common struggle. I completely empathize with you. I am currently an independent consultant. And I see what you're talking about with almost every client I work with.

To be fair, I can't think of a single good enough reason why this sort of thing happens. The most common, however, seems to be a general lack of interest in following laid down coding standards. I have tried both approaches: training, and the stick (not literally!). But...

As you say it, it is easier to train a complete newbie into one way of doing things. And a veteran coder will more likely follow whatever they see in existing code bases. Its the folk in the middle that are usually... "trouble" :)