2

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?

  • I will edit the post and make that clear. I ment the dev branch which will be deployed to staging. Once this is accepted by the customer the dev branch will be merged to with our master branch and the master branch ends up in production. – Piet Smith Feb 12 '17 at 23:16
  • My boss generally tends to be dismissing of my comments (as in the case with the style checker in his IDE) or dismissive (in case of deployments delay leading to inefficiencies) or pulls rank on me (in case of the restyling). In general I feel that he is less responsive to communication than other (senior) developers I work with. – Piet Smith Feb 12 '17 at 23:21
  • 1
    Too much text, not enough of the actually important details. Who is your manager? Is it this senior developer? Have you tried talking to him or (project) management? Note that specifics around his work (including the staging/deployment process) are irrelevant on this site, you don't need to go into that much detail on that as it usually leads to arguments in the comments and people failing to answer the real question. – Lilienthal Feb 13 '17 at 8:11
  • 1
    Some of the things don't matter. For example, if he turns off a feature of his own IDE, that is his own preference. If you want a style guideline, that's another discussino to be had (you have to make a case for it), but if implemented it should be done in a more sensible way (e.g. a style checking job running on the CI server on commits). – Brandin Feb 13 '17 at 23:34
  • 2
    Possible duplicate of Dealing with a senior colleague not pulling his weight – gnat Feb 20 '17 at 8:11
2

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.

  • 3
    Project development should be handled in sprints, not if they aren't in Agile process, though we recommend it a lot, it's no obligation. A good old V cycle well managed still works nowadays. I do agree with the fact that it is a organization issue, the QA director may not be needed, they could choose themselves the standard and having it enforced by the prject Manager even over the senior. – Walfrat Feb 13 '17 at 15:34
  • I suspect this is a smaller company where the developers are also the business analysts, and the product owners. – UK-AL Feb 13 '17 at 15:44
  • @UK-AL: Quite possibly, and that's always a scary thing... – PeteCon Feb 13 '17 at 16:59
1

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.

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.