I'm having mixed feelings about a situation in my workplace. I’m getting the impression that a colleague wants to claim my work as his, but I’m also suspecting it might be unfair of me to think so.

We have a software product that needs to be tailored for each costumer. I was in the dev team that created the first version of this product with the help of an external consultant. We had very poor management from non-coder bosses and the small team was made of juniors.

The consultant enforced a mix between strong ownership and collective ownership. Most modules were supposed to be modified only by the responsible person; with very few exceptions. However, there were a few integrating pieces that needed to be modified by everyone (with everyone’s knowledge).

Afterwards, a new project has begun, with no consultant this time, and that initiates a retailoring of the product, where many modules may need very small or no modifications, while a few new modules might need to be created or removed. However, I was assigned to a different project, and is not foreseen that I would be working on this retailoring. My colleagues now have copied all the code files to a new repository, thus the commits I’ve made in the earlier project can be seen only in the old repository (which likely no one will check). We had standards for headers in the files, which included the name of the person doing each relevant modification to a file. But even with small modifications, my colleagues are “resetting” these changelogs, thus removing my name. The same goes for the documentation.

I’m not sure if I should raise a discussion about it, and if I do so, how should I proceed.

One of my colleagues has more than once presented things done with meaningful help of others as his own (he never explicitly claimed to have done it alone, but doesn’t mention whoever was not in the room) and often says “We did A and B” when he should have said “Joe did A and B”. So there is a trust issue on this matter.

The concern I have is that all code I’ve developed in the past years will now be seen as if it was fully developed by my colleagues. The boss having very little visibility and no interest in managing people does not offer a good counterbalance to this concern. I understand the code is the company’s property and not mine, but the impression is that I’ll lose all credit I should have from developing it within the next year. This is more critical on how I would be seen by new employees or by (possibly) a new boss outsourced by the company.

  • I wouldn't worry about it. That type of "each customer has their own product" management will bring this company down, soon enough (I've seen it happen). Credit will be irrelevant. Apr 26, 2019 at 17:04
  • 1
    Have they given any explanation about why they're resetting changelogs? That's the part that seems directly fishy to me - why include changelogs at all if you're going to reset them?
    – Ben Barden
    Apr 26, 2019 at 17:06
  • @BenBarden: They didn't discuss that with me, and I'll take some caution before approaching them. One likely reason is that these logs are mostly important during the specific project when people depend on code to be submitted in a functional manner, but when a new project begins and some third party tools are updated, one expects many things to need some kind of refactoring and unit tests to be re-done. Over this process, information in the log may lose importance. Nonetheless, that still means my name is being erased from pieces of code originally written by me.
    – anon
    Apr 26, 2019 at 17:15
  • 1
    Rule one of code: Never put your ego in the code. It's not yours, it will change and you have no control of that. It will be moved, and you will never have complete control of how it's perceived / used / changed. Apr 26, 2019 at 17:37
  • 2
    Side Note: You should consider pushing for the removal of in-document changelogs altogether, considering version control serves the same purpose, and does so much better. Also, moving a repository via copy/pasting defeats the purpose of any version control.
    – Clay07g
    Apr 27, 2019 at 14:00

5 Answers 5


I’m not sure if I should raise a discussion about it, and if I do so, how should I proceed

In this case you don't do anything.

As you mentioned, the code is the property of the company.

However, credit and/or responsibility for is very different. Ultimately, this is up to your manager to recognize who has contributed what. A good manager with some technical background (doesn't have to be an ex coder) will recognize who their key contributors are and will reward them accordingly. A not so good manager, well, won't.

With that in mind, I would not worry about this much. Contribute to your team, continue to grow your skillset ( so you are marketable outside the company ) and carry on with your work.

  • If it really bugs you, you can ask something. Something like, "Hey Fred, I notice you removed all the changelogs. Is there some reason you're doing this? It has a lot of good info that might be useful."
    – Dan
    Apr 26, 2019 at 17:26
  • @Dan: These change logs are actually important mid-project, when modifying some pieces of code may break things that are working elsewhere. When the project restarts, everything is assumed to be broken. There are separate fields for explanations and more useful notes. Thus, I don't really have the "It has a lot of good info" excuse to bring up the topic. I do understand your idea, though, I just think that either they see no problem in doing so (hence I'd have to ask a more blunt question) or they're taking undue credit deliberately, in either case that would be a difficult conversation.
    – anon
    Apr 26, 2019 at 17:42
  • I think your last paragraph is perhaps the most important. Focus on your future. Instead of worrying about whether your name is attached to something you did last year or not, attach your name to quality work right now. And then just keep doing that.
    – dwizum
    Apr 26, 2019 at 19:44
  • Also, if you're using git, unless they're rewriting history, your commits will prove your contributions. It's difficult for them to take that away from you.
    – Malisbad
    Apr 28, 2019 at 10:06

Okay, sorry, but I'm going to answer this as a frame challenge.

You shouldn't bring up a discussion about it, because you're focusing on the wrong issue. The big problem is that your company is trying to move into a 'Silo' model where each piece of code has a steward that is responsible for edits to it.

No. You should be striving for cross knowledge. The Flooster system shouldn't be "Alice's" - it should be a system that multiple people are comfortable editing/compiling/deploying. The Ribble code library shouldn't be "Bob's", anyone in the group should feel comfortable making improvements to it. Because imagine if Alice or Bob leave the company, get hit by a bus, are promoted, whatever. Suddenly you've got swaths of code that nobody feels comfortable about taking care of. After all, those code libraries were Alice's/Bob's.

If I were in your shoes, I'd say something like this to the manager:

I'm a bit worried about cross-training in the group. Since that consultant came, I'm worried that we don't have enough people that know enough of the codebase. I mean, Charlie's been working on the XYZ system - and he's the only one that's touched it. What happens if Charlie leaves? Nobody else knows that system besides him. Same thing with Diane and the ABC system.

... because, honestly, your value to the manager isn't "What code did you write the original release for?" but "What stuff can you help us with moving forward?" - and being able to keep the existing systems running is a huge part of that equation. I'd much rather have an employee that knew all the systems and could make modifications/enhancements to any of them, than one who had only wrote the original version of a subset of them.

  • Yeah I do agree that assigning steward to a code has draw backs. Mostly related to the same one OP faces where someone takes "ownership" and they ensure their product can only be modified or changed by them. It makes it difficult for the company as well as they'd have to pay more to a person due to being "experts" and if that person leaves, it leaves the company stranded. Overall code and products should be open and easily changed by anyone, no ownerships.
    – Dan
    Apr 26, 2019 at 18:03
  • The concern about cross-knowledge is something I had brought up to the manager early on. He acknoledged it, and even said that maybe next time the copied repository could be once again the one I worked with, rather than the current repo if needed be. You said yourself you are answering a "frame challenge", and raised valid points which I believe I have addressed already. A larger concern I have is that if a new boss comes from outside the company by the end of the year, he might be left with the impression I did barely anything in the prior 4 years. (no concerns over the current year)
    – anon
    Apr 26, 2019 at 18:20
  • I don't think that should be a concern, to be honest. A hypothetical new boss is going to base his initial impression on: Performance Reviews, any advice/knowledge that's transferred from the old boss, and talking with everyone among the group. If your performance evals were good, your old boss liked you, and your coworkers think you do a good job? You have nothing to worry about. And, well, if the boss is curious what you did 4 years ago, they'll either consult the performance reviews or simply ask you. :-)
    – Kevin
    Apr 26, 2019 at 18:25
  • @Kevin: Current boss avoids doing performance reviews by all available means. Every year he attempts to submit the reviews directly to HR giving everyone a perfect score. There were times in which the CEO did not allow this, but it has passed more than failed. Thus, performance reviews would by no means be reliable.
    – anon
    Apr 26, 2019 at 20:29

We had standards for headers in the files, which included the name of the person doing each relevant modification to a file. But even with small modifications, my colleagues are “resetting” these changelogs, thus removing my name. The same goes for the documentation. I have to go back and look at the blame or logs and tell the person you got the wrong guy. I did a mass delete of my name from the change log before leaving though.

At my last company we had this policy although later down the road we moved to svn then to git. The problem with this is nobody uses "blame" (I think now it's called praise or something). So when a problem arise, they look at the header change log and just so happens my name is one of the people who modified the file although the file has long since taken new shape or copied to another file.

With that said, I think he might be trying to help you. People copy and paste the header, including all the names to a new file. Now your name is on a new file. So rather than people coming to you asking you questions about a file that you no longer control, now the new people will get asked.

Even if for sinister reasons, no manager is going to look over all the files on a system and determine if you modified it and got the proper credit. In the inverse, what's stopping you from being the bad actor and going into every file to add your name to insure you get credit for things you never did? So I think this concept is flawed. The real question is what's your manager doing to make sure you get credit? During review time is your manager bringing up stuff you did and writing it down? If not, perhaps talk to him about it or find a new place where you are appreciated in the way you feel best.

  • (FYI, "blame" and "praise" are synonyms ---when used as arguments to git, in svn it's called "annotate"--- and they do the exact same thing regardless of the mood of the operator.)
    – KlaymenDK
    Apr 29, 2019 at 7:27

The problem is not that individual X claims code is theirs when it's half yours, or that artefact Y is being overwritten by artefact Z and thus deleting the trail. The problem is that you are working in a company which cares about who wrote the code.

So long as that is the case, you, and others, will experience these problems. You may one day fix a load someone else's code and have it attributed to you, much to a new junior's dismay.

Parallel world

In the company I work for we have no immediate visibility of who wrote the code, nor does anyone dig through git to investigate who is responsible when we find bad code, nor do we give people a hard time when we discover the bad code is theirs (Perhaps they copied it from someone else and tweaked it to make a deadline knowing it was ugly code, but that was still the best decision at the time. Perhaps they told someone they were doing this and planned to refactor but got pulled to another project etc...) Besides, does the responsibility lie with the junior who wrote the code, or the senior who let it through code review?

Needless to say, we have none of the problems you talk about. It's not utopia, but lack of individual attribution does not cause any quality problem that I see, everything goes through code review, we unit test quite extensively, and have dedicated testers.


I think you should initiate a conversation about the value of caring about who wrote what code in the first place, and whether this is beneficial or detrimental to the company.

Isn't there a chance that people won't refactor code because it doesn't have their name on it? Doesn't this create a toxic every programmer for themselves environment? Doesn't this denies the codebase many fixes it could otherwise get? What about people who've left, or who know they will be leaving soon? What tangible benefits are gained from retrospective blame?

If you can initiate a conversation about this, you might find that the net effect of code ownership is not as good for the company as it's held to be.


To offer a counter perspective: Unless I'm misunderstanding, that sounds like professional behaviour that would be considered normal, even expected, in the companies I (used to) work.

  1. Rather than tooting his own horn, he's presenting all work as a team effort ("we" includes everyone who contributed to the code).
  2. He's applying "boy scout principles" to get rid of redundant and outdated comments for files he needs to modify for other reasons. (You do use version control, right?)

Even if that goes against the usual principles at your company, it might be what he's used to from previous jobs. I doubt there's any malicious intent behind it.

How about you simply ask him for his reasons? You might be surprised.

  • The person in question makes a point of saying "I did" when he did the work, but says "we did" even when he had no contribution. So, other people's work is a team effort, but his doings are always his. He once presented an analysis made by a colleague who was in the room making no mention over who developed it, when the boss mentioned that he did it, said colleague asked "he did it?" to which he answered "we did it", and the colleague had to respond "really?", finally he answered "Joe did it". This is his first job other than short internships.
    – anon
    Apr 27, 2019 at 20:43

You must log in to answer this question.