How to deal with a senior developer that might not be beneficial to the quality of our project?

Question

I've been working at my current company for over 2 years now and I thoroughly enjoy working on the current project that I work on. Our project manager on the customer's side is awesome, the customers are amazing and often thank me. I feel responsible for the project and I strive to do the best work possible. I do 80% percent of the work for my current project but the senior developer above me has certain habits that impede the quality of our projects.

To be more specific:

• He turned off the style checker in his IDE because 'it annoyed him'
• He doesn't write tests, at all, there's not a big testing culture in the company but the project has been growing to large to handle without having tests and I would very much like to grow them over time
• He doesn't do code reviews, so most of my code goes to the staging environment and eventually to production without anyone actually checking the code quality of this (the customer does run acceptation and regression tests on the staging environment but code-reviews would still be hugely beneficial and save the customer testing time)
• He does a lot of the communication with the customer but doesn't communicate it to me. I always CC him in e-mails he doesn't CC me in his e-mails to the customer. Often leading to me missing information about the long-term planning despite doing most of the work and having a lot of knowledge about the code base.
• He does the deployment to the staging environment and then communicates towards the customer what can be tested without always letting me know, often leading to tickets coming back to me because the post-deployment application configuration changes have not been applied
• He sometimes fixes tickets in a very 'lazy' way, for example we received a ticked that the contrast in a specific area was low. He fixed it by removing most of the design and changing the font. Technically he fixed the problem but it didn't end up making the project better.
• Deployments to staging often takes days when he is busy with other projects, this is not a big problem because in general we run ahead of the schedule but it still introduces inefficiencies. I've advocated continues deployment but he is heavily against this. Saying that this is a waste of time.
• He sometimes does unnecessary but 'fun' work, e.g he refactored the CSS of a part of our application while a redesign is coming up in a few months

I've given extensive code reviews on his commits before, but my comments were mostly ignored. I've also talked about a few of this issues with him and he is sometimes open to suggestions but other times he pulls seniority on me or does it without communicating about it.

In the end I feel that the quality of the project would benefit from having another second developer on board.

What would be the best way to approach a situation like this?

Answer 1

You don't need another developer, you need a QA Director who should work with the Project Manager to determine the standards to be used on the project, and the processes that all development should run through. That way it becomes less of a 'you against me' situation, and more of a 'the project needs this to happen' situation.

The PM also needs to stress the importance of communication; all major communication with the client should be via the PM in their regular (and minuted) meetings. Developers are expected to develop, not analyze the business case, so shouldn't have to talk to a client regularly (I maybe talk to a client about once every two weeks).

Project development should be handled in sprints, with every sprint release being reviewed. That's where you'll get your chance to mention that code reviews are not timely or effective. Your security people (or at least QA) should also see the code reviews and comments, and should be able to prevent work being committed without the peer comments being addressed on all sides. Code Reviews should also include style reviews, to ensure that the coding standards for the project are met; anyone can turn off a style checker - that's fine - but their code is less likely to pass a Lint test, and therefore should not end up in the repo.

In short; you're making this your problem, when really it's a project organization issue that you're trying to fix. Get the right people in place, and the correct processes will follow.

Answer 2

I think this is more of a team dynamics issue, the most important thing is to check the ego. It's very easy to programmers to step on each other's toes, whether or not the person is senior to you. Instead of implying that it's dumb to not write unit tests, show him the advantages of writing them in your environment. In programming it's very much I don't know what I don't know. For example if I have not had exposure to OOP, I will most likely just dismiss it as 'needlessly complicated', even though it's very important. The book Extreme Ownership goes deep into team dynamics and is helpful for anyone working in a team.