I have a situation at work that I’m not sure how to deal with. I’m guessing there are others within the DEV community who have encountered similar situations and so I’m looking for some feedback on how they've dealt with it.
Going anonymous because I really don’t think the names of anyone involved matter and I don’t think anyone is purposefully trying to do anything wrong per se.
Note: I have replaced my colleague's name with the letter "A" for anonymity
Background
Recently, when working on a big new refactor of a feature, I was responsible for doing the first pass/research into how we wanted to implement it. I did so, and then a second colleague, A, joined. A rewrote most of my code because they thought it'd be "simpler" in an alternative format. I’m not entirely convinced the solution was or is better as there have been a lot of edge cases found since, but that doesn’t really matter.
As part of the rework, A built in a bunch of test cases (good) and then has continually pointed to these test cases and their coverage in a “look how amazing my work is” and “there will be no problems” sort of way. I’m all for testing (and admittedly am bad at getting around to implementing them), so I was initially happy with this development.
However, the first time I tried to run the changes A made, I encountered a bunch of errors (even though all the test cases passed). I pointed them out to A, who fixed them. When more stuff was implemented and more of these magical test cases were added, I ran it again I found a bunch of new errors — a process that's been repeated.
So, two obvious conclusions (...at least to me) :
- The test cases are not actually testing the code. They’re using data that doesn’t replicate real use cases and has been sanitized to the point that it’s useless.
- A never actually ran the code outside of confirming that the test cases pass and the service can start. The bugs I've encountered were not edge cases that one may reasonably miss.
The problems haven't ended with the test cases. The new "simpler" version did not do what my original version did. Instead of using my work as a reference, A chose to look at the implementation of the old feature. I told A multiple times the old feature was not an accurate reference because we were making significant changes.
A's implementation ended up not implementing many of the new needed features, while at the same time implementing multiple old features that we no longer want. So I’ve spent a lot of time over the past few weeks catching all these missed pieces and having to get them implemented (again) or removing the pieces we don’t want.
So, it’s not just that the test cases haven’t actually caught any bugs, but that the new solution has been both incomplete, while also doing unneeded work.
During all of this, I’ve generally pointed out these issues directly to A in DMs, keeping them relatively private. However, a result of this is that A has continued to boast about the test cases and his work to the rest of the team, who have continued to be super happy/impressed.
This project has been taking a long time, and I’ve always felt (maybe wrongly) that there’s been a belief that it had been me who has been slowing it down. With the addition of A and some others on the project, it really hasn’t moved any faster (even with these amazing test cases :P), so that has felt like validation that it's not just me.
Anyway, I’m finding that I’m getting increasingly stressed out working on this project. I wanted to use it in an upcoming review to point to the good work I’ve done. But the way it’s been talked about within the team, it feels like most of my work has been dismissed or trivialized, and that A is being seen as the “savior” who came in, fixed it all, and made it way better.
This isn’t the first time that A has acted like something they’ve done is amazing and that others seem to lap it up. It has made for an uncomfortable work environment. A recently was promoted from Junior to Intermediate dev, and I really feel like a lot of this boils down to A’s ego being bigger than A’s actual skills.
Normally, I've been able to push aside and ignore this behavior because my work has been mostly separate. But now it feels like A's work (and attitude) is actively making me look bad.
I keep getting caught up in a "is it actually me who is wrong?" spiral, but then I run the code and find more issues, obvious and fundamental issues — and I find myself getting angry/frustrated all over again!
What I'm wondering...
Does anyone have experience working with colleagues like this? How have you responded? Who do you talk to? The dev? Your manager? Someone else? And how have you talked to these people? What sort of solutions have you found? What's worked? What has NOT worked?
This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usually tough posts to write. Email sloan@dev.to if you'd like to leave an anonymous comment.
Top comments (19)
IMO, the thing to do here is sit down with your project manager and talk this all through. Based on your recounting, it sounds like A is having an actual detrimental effect on the quality of the project that is going unnoticed, and I'm sure your manager would like to know. It's helpful that you have documented some of the issues along the way via your DMs to A, and could pull them up for reference both of what specific bugs they caused and, perhaps more important from a business perspective, how much time (and therefore money/resources) has been spent on cleaning up behind them.
I know this can be a very uncomfortable thing to do, and it can feel (and sometimes be) risky. I don't know how your company is structured, but both large companies I worked for (and several others I know of through friends) split the management hierarchy between project management, those who handle actual development of a specific product and the team(s) working on it, and a different sort of manager who is responsible for working with a few employees as they move through the company, regardless of project (my first company called these "career managers", my second called these "branch managers", another company I know has called them "line managers"). This second management structure exists for exactly these sort of situations, where you might not feel comfortable approaching your project manager initially, because you don't want to create any tension with others involved with the project until you are sure it's worth pursuing; the career manager (or whatever title) is typically not associated with your project, and so can listen to your concerns and give you impartial feedback without any personal stake, but they also are in a position of authority such that they could help you approach the project manager if that is the right thing to do. If your company doesn't have a structure like this, HR would be another option; I would just approach someone in a can-I-bounce-a-problem-off-you sort of way, maybe discuss the situation without naming names initially, and see what happens.
The most important thing that either of these authority figures could help you do, aside from maybe actually mediating the conversation, is help you find the right approach if you do go to your project manager. This sort of thing can feel like a personal attack and can get heated if you present it the wrong way, so an HR rep or an experienced manager should be able to help you craft your complaint in a minimally inflammatory way.
this is a nasty approach, you have a problem with someone how they conduct themselves or what they deliver you bring it to that person first and you discuss it with them. Only afterwards, if there's good reason to do so, should you escalate to management. Be fair to people and treat people respectfully regardless of what they may have done.
Second, if this company seems to treat people with promotions because of outward appearance. You may want to look for another company that values output first above how someone can politically maneuver.
The OP says they've repeatedly brought up these issues to the dev, no?
apologies he did say that. I was speed reading through it and missed that most obvious part for some reason.
At any event, my recommendation here is to follow the process of development and not circumvent that process by "helping" and "fixing" via out of band mechanisms. Problems such as these need to be made visible on the team boards and then they're signaled by testers and you can do proper fixing that way including educating him on how to do it.
That way you're completely transparant to the whole team and issues are clear where they come from and who needs to solve them.
I agree with this method.
Also talking with A beforehand could be helpful.
You are not the first, and will not be the last, to experience this. TIME is your best tool.
Everything we do in software development is documented, from your version control history to your unit test reports. Time will highlight issues with quality as the product evolves and more QA activities are undertaken.
Focus on yourself, be the best you can. Be technically proficient in the tools you use and your product. Do your testing so you create quality/ robust code, do these things and people will see your value.
Don't throw person A under the bus, however much you may want to.
Its your product, voice your concerns but show humility. If you notice problems, have the solutions. Overtime people value this more than an ego than can not deliver.
Disclaimer: I am not a HR specialist, so please take everything I say as an opinion. I would normally refrain from commenting anything outside my domain of knowledge, but the situation in which you are has definitely rung a bell.
Two things I noticed from your presentation:
I'd like to start by stating the obvious: social relationships in the work environment need to strike a balance between the personal and professional domains. It is important that you are able to identify what concerns belong to a particular domain and deal with them using the appropriate tools at your disposal.
Professional Concerns
I understand that you likely wanted to avoid a confrontation at the workplace, and that is a laudable attitude. However, handling professional matters privately with your co-worker via DMs, instead of using one of the various company-established channels for this purpose (PR reviews, meetings, job performance evaluations), created a personal issue for you from what should have been a management problem. Dealing with the situation in a strictly professional manner from now on will go a long way towards restoring the balance.
Personal Concerns
Empathy is a powerful tool available for both domains, but arguably it is also the least commonly used. From what you described, you could have rightfully elicited an empathic response from your co-worker by explaining how you felt about its behavior. You are supposed to act as a team within the company. By discarding your code without consulting you first and boasting about its improvements, it showed little regard for your work and set itself apart as an independent unit. You could likewise examine its response to your criticism, and show empathy where appropriate.
Final Word
Remember, anything you decide to do about this, do so always from a position of serenity, composure, and respect. It seems unlikely that you will be forced to make a hard decision, but if you do, it always helps to keep a cool head.
The above is nothing but observations from an outsider's perspective. I could very well be wrong or have missed the point completely. Please, take it as an honest attempt to help.
This is a pretty common phenomenon observed at workplaces everywhere, irrespective of profession and industry. There's always one, or more, braggers who talk more than they actually work, making mountains out of their moles's worth of work - and unfortunately, the management seems to appreciate that.
Talking with the management may work, or it may not. However, do not stress over this and if you feel the management is not realizing ground facts - better move on with your career.
I seem to be reading a lot of A did work and The work I've done. You're working with the same software. Try doing some actual team work and stop worrying about your personal achievements or A's performance. Software is a team sport. You succeed together and fail together. Try introducing pair programming and mob programming in your organization and you'll see that quality, speed, happiness improves.
Obviously you need to work as a team but you’re not all going to get promoted together based on how well the team does. If people are trying to sell how awesome they are when they’re actually detrimental to the team and the work you need to talk to them and if that doesn’t work talk to your manager. But don’t for a second “stop thinking about your personal achievements”, that is bad advice.
Strong team work exposes posers very quickly. It also levels the playing field because everyone has the opportunity to work on their weaknesses in a safe environment. Of course there’s room for personal achievements there as well. If one person is not cooperating or is just a toxic personality then it’s good to talk with management on how to get that person removed.
But once we start talking about promotions or other personal rewards i can see us going towards a very dysfunctional software shop. A kind of environment where people make themselves irreplaceable by not sharing knowledge.
When we’re payed by someone to create software it’s our job to do what’s best for that someone. At the same time we need to make sure we build good experience for ourselves to be able to justify better titles and salaries. If that deal isn’t working out for either one, it’s time to move on.
Inside the team this is true, but I have seen multiple occurrences where management has no clue. If someone is taking credit for work they aren’t doing or is mischaracterizing their work how is management supposed to know if no one tells them?
Yeah, it sounds like a cultural problem. Work is not transparent enough. Progress is not incremental enough. The people involved are not talking openly enough to each other. Probably not a very healthy environment for growth.
Wow, super long detailed post means you're highly upset. The plane is going down, bail out for a better environment for your own peace.
For me I don't agree with rewriting a code someone else has made without discussing it with him first, even if I find that code needs improvements. So that's a mistake A has made and you need to make it clear for him that it's unacceptable. If he asked you about this before starting and you approved then you participated in this.
Anyway, you should have mentioned this to him or your direct manager once he started committing with a different format that you see is not enough.
Be confident about yourself and your work and most importantly try always to make your point of view heard.
First: if you updated the code and did not add tests for what you did, you were not refactoring; you were pushing code around. A real refactor takes the code as it is, puts it under test, improves it, and verifies (via tests) that the improvement worked. So from the most naive point of view, A took an approach that was better engineering, and you're going to have to take that as a lesson. If A added tests -- putting aside that they're not good enough yet -- A followed better refactoring practice, even if they made errors doing it. You need to look at that and own your mistake first: write tests. If you're not good at it, you need to learn how to do it better.
Let's put that aside for now. How do we address the situation, as described?
As you've described it, you have a set of code that doesn't quite work, but passes its tests. Why is this the case? If the test cases are inadequate, and you know what cases should be there, then you need to get this work into the team's queue.
Whenever a test fails to catch a bug, file a ticket. "foo() should return bar, but returns baz". In the comments on the ticket note that the tests do not cover this case, and the situation or data that triggers the bug. If they do, but the test passes, note that.
You've got to make sure that the failures are documented, explained, and the work that is going to be needed is in the backlog. You've got to make sure that necessary work to take old features is in the backlog. You've got to make sure that the work that's missing is in the backlog. Basically, you have to stop fuming about how it's awful and document it. If you can do code coverage for the tests, you should do that, partly because it will let you ticket untested code, and partially because -- if coverage is poor -- you'll have more grounds for your position.
Once you've got that in place, you need to remember that the point of all this is that the code should work. Not that you are right and A is wrong. Yes, it sucks that A is getting credit for things being great when what you see is different, but unless it's documented, you just look like a complainer who doesn't like A.
Once you have the situation documented, you need to talk to your manager -- I'm assuming you both have the same manager. First you are going to have to swallow your pride and admit that A's adding the tests when you didn't was a good thing for them to do, and that you should have had them in in your version.
Only after that can you say that the problem is that the tests aren't actually exercising the right code paths, because tickets A, B, C, D, ... all show that there are bugs that the tests are not catching. At this point you will need to propose a solution. And that solution is most likely going to be that the team is going to need to devote some time to getting these bugs fixed to improve velocity. And that will probably mean that you will need to work together with A to fix the bugs and make the test suite cover them.
I hope this is just a temporary interpersonal problem. If you work together some, it's possible that you'll both learn from each other. If you've been really careful and honest and neutral (which may be hard) about reporting the bugs, and frame it (to yourself too!) as "we're all trying to make things succeed, these are things in the way we can fix", then you may find it a lot less tooth-gritting to sit down with A and work through the tickets.
One... Thank God for version control. That said.. I tend to be transparent with colleagues who display bad form/behaviour of this kind especially the passive aggressive ones who find it hard to be just be honest. So be clear with them in a polite and honest manner. Eventually they always self destruct and show their true colours and either they play ball or they marginalise themselves till they have to leave the company.
So in short... pull "A" aside and explain that his behaviour is unbecoming and is a bad example for others. Then let him choose how to proceed after that.
The issue is that Peer Review is slowly disappearing to leave place to Manager (or Designer/Client) review. A knows that his job depends on the PR he can do towards people that don't know anything about coding so his focus is not the project.
External companies are especially well trained in such practices that grants them continuity in the projects.
The only thing that worked for me in such situations is leaving.
Everyday..