I am a software developer planning to leave my current job in December, unless something significant changes. This is entirely because of a single coworker within a small team, whom I think is harming the company and whose actions are making my job harder and at times unpleasant.
So, my question is, what is the professional way to divulge my reasons, if it's possible, so that it has a positive impact on the company, and which reasons should I divulge?
Here are the main categories for why I have decided to leave, with some examples (sorry it is so long, I'm hoping this is useful to others who have seen these behaviors):
- Blame and offloading responsibility. Since I have started this colleague has sought to blame others, often when they were partially responsible. No-one else levels this blame at one another, and I feel this is harming all efforts to create psychological safety and an open engineering culture
Example 1: Colleague B made a configuration change that caused a bug. The configuration was for a service written by difficult colleague, whom had not documented the configuration. In my opinion this was a joint responsibility but no-one should be held accountable. However, difficult colleague brings this up we;; over a year after it occurred, in front of other colleagues, recently completely unprompted.
Example 2: Difficult colleague doesn't follow standard industry practice for code repository management (although hopefully this has changed after two years of asking). Difficult colleague made some changes in a repo he manages, colleague B made some unfinished changes and committed them. Difficult colleague publicly blamed colleague B for introducing unfinished code into a service he wanted to deploy. If the repo had been managed correctly, the unfinished code would not have had an impact.
- Poor software development practices making change difficult. Difficult colleague adopts well-known anti-patterns in his code, is unwilling to change them, and also makes his services difficult to change.
Example 1: We have all adopted test-driven development. Difficult colleague is the only one not writing tests with the explanation that he lacks experience. I spent about four hours showing him how to write tests (with him disagreeing with everything I said). It transpires that one of the anti-patterns difficult colleague has adopted make it impossible to write tests in some places. We now have services that are critical to our software functioning that are a) hard to understand (lack of tests), b) hard to change (lack of tests), and c) hard to write tests for (anti-pattern).
In one case I chose to adopt a design that, whilst not ideal, was chosen solely to avoid making changes to a service he had largely written and had critical bugs in the past.
Business ethics/not following process.
- Not following code review processes. Our company adopts the standard practice of code going through review before being committed to the master branch and deployed. Difficult colleague has been voicerous about people needing to raise PRs sooner than later. I recently came across a service he had written for me to use that had been written on the master branch with no code review process. I confronted the colleague calmly, and he agreed he shouldn't do that, and that he would fix it. The next day I ask when he'd put it in for review, and he spends the next twenty minutes telling me I'm being difficult. Eventually he gives in and spends a couple of minutes putting it up for review.
I later find he has done the same thing elsewhere. I immediately asked our manager to make PRs mandatory on all repositories. I did not divulge the reason.
Deploying live code without monitoring. Difficult colleague has deployed some critical changes and not checked on them the same day, the next day, or even the next week. I accidentally came across critical data losses caused by his changes three months after they were made. It would have taken him minutes to have manually seen these errors, or a little longer to put in automated alerting.
Not reviewing code. Difficult colleague does not take the same time others take to review code. I will frequently see him accept 5+ PRs in quick succession shortly after they have been raised. It is impossible that he has read the code sufficiently, if at all, to understand the changes.
Unequal workload and effort. This has impacted obviously our capacity, but I also find us making design decisions because difficult colleague doesn't want to do X or Y (making someone do something more arduous instead).
Example 1: For the past six months difficult colleague has been tasked with developing an API. This API is something I would expect to see finished within a few weeks (I have worked with others developing something very similar). After six months I have not seen a single line of code or a design document. I looked to see if he had any outstanding code branches, he has none and he has directly written code onto the master branch without review (this is a different repo to the one in the code review example). This repo is also critical for security.
Example 2: We had a tight deliverable recently. Looking at who was assigned what, there were some additional unassigned tasks/services to build. Difficult colleague had a days' work assigned. Other colleagues had about four weeks. We were asked who was willing to do X, Y, and Z. After awkward silence difficult colleague did not volunteer for any of these, which were taken up by other members. During this deliverable difficult colleague did little beyond their one days' worth of work. Everyone else worked long hours and some weekends.
- Strong opinions against standard practice/whilst lacking expertise. We have had very long discussions, a war of attrition, where he was typically on one side of the argument and one or more people on the other. Sometimes he is right (obviously), othertimes he isn't and he won't give in.
Example 1: when our new product was about to be released he argued heavily against putting logging in on core services, saying we didn't have the time. The argument took approximately one hour and got quite heated. We eventually put logging in, which took the person responsible about twenty minutes, and allowed us to discover and rectify critical issues post-release.
Example 2: I have more experience in event-driven systems. However, when I explain the functionality I think we need and the kind of products we should use, he simply says they don't exist, and they can't exist. I have used these products in the past. As a result, I feel that we've gone for solutions that aren't fit for purpose because he won't back down and although we could investigate a solution together, I lack time to investigate on my own.
Example 3: He will derail discussions by stating service X does not work in the way described by a colleague, despite that colleague being the one who has written it. Typically the conversation ends with him saying the service must be wrong then.
- Argumentative/rude nature taking up time and energy, and personal attacks. I have been in many conversations where he will suddenly say of someone's code "it's complete bollocks" with no explanation. This riles the person up (not usually me) and derails the discussion. In other cases he will get personal, for example saying to a colleague "you only got hired because you're other colleague's friend", or when he started having a go at some of my lifestyle choices.
He explains it away saying he gets bored so he likes to get a reaction from people. But it has, in my opinion, harmed our work. Moreover, he has stated he hopes his behavior doesn't cause people to resign, whilst continuing with his behavior.
To be clear, with all of my colleagues and between colleagues I feel that we're able to argue different opinions without issue and as a result come to good solutions. It feels collaborative.
I don't want to tell my managers this before I leave, because I feel that would be holding them hostage and I'd expect them to sack the hostage-taker (myself). I also don't want to be directly responsible for getting someone sacked. Finally, maybe I'm the problem, and so I don't want to give an unbalanced view that could affect decision-making, I'm simply too biased.
At the same time, I have a very small financial interest in the company, and I otherwise enjoy the role, my other colleagues (I think the team is otherwise fantastic) and our product; hence, I want to be honest if it would help the company. However, in the past me and the colleague have had personal problems (largely because of his criticisms), which leaves me to believe my current bosses would put it down to my issues and not his.
