I'm looking for advice on this as this happened to me recently. A co-worker needed a portion of my code to work on his project so I gladly assisted this co-worker but insisted that my code was not complete and was NOT to be distributed to anyone else due to it being incomplete, and I would potentially be blamed for possible errors that occur due to the code not being ready for distribution.

This co-worker took my code and made edits to suit his/her project and immediately took ownership of the entire project including my code saying s/he made this easy-to-use group of functions that will improve the company by all having the same code base. This was topped off with me being emailed saying "Okay, I set up this project that you can insert your code into. Let me know if I can help you." I wasn't sure how to react to this betrayal and stomping on I feel.

I worked a good long time on this code base to help the company out and help improve our coding process making custom functions and all that in C, C++, and other languages the company uses all with very well (at least I think) commented code that told you exactly what each thing did. I just feel betrayed and stabbed in the back. I feel I worked so long on this project just so this co-worker could come in and make a few edits ignore my request to NOT send it to entire company until I finished it and had the nerve to call it theirs.

Question: What would be a good way to react to this and future situations in my career? I've been working at this company for almost 5 years and this is the first time something like this has happened. I thought I could trust this co-worker. Maybe my manager will ask "Well, what have you done in the last x months?"

  • Surely you have some evidence that the code is yours or that you two corresponded with each other about it? I find it hard to believe that there is no trace that you worked on it. – pi31415 Nov 2 '14 at 5:17
  • 3
    Could you confirm whether this was actually your code or the company's code? (i.e. who owns the copyright?) – Philip Kendall Nov 2 '14 at 7:30
  • 1
    @PhilipKendall - Well, the company owns all the code we produce while on the clock or not, but what I mean by "my code" is I was working on it in my free-time (during unpaid meal & breaks) to help the company use a consistent library so when someone occurred we would be able to fix it in one spot instead of dozens of applications. This co-worker knew I was working on this and asked to use some of it's features. I gladly assisted because that is why I spent all that time during my breaks to put in 110% effort to company. Then that co-worker took that code and made it theirs. – Khaltazar Nov 2 '14 at 19:24
  • "my" code ? if its used in a work related project its your employers code is it not. – Neuromancer Jul 3 '18 at 20:22
  • How many hours did you invest in your code? How many hours did your co-worker work on his project? If you work like 10 hours and the guy worked a month, I won't take it personally. – Sebastien DErrico Jul 4 '18 at 13:24

You made a mistake - you did not follow the procedure to release your code.

Normally, you need to follow the code release procedure and notify your manager/supervisor/tech lead when you release the code. You need to tell everybody what your code does and potential bugs and the documentation if available.

Had you done all these, you would not need to ask a question here. Instead, your manager/supervisor can handle this matter. Now, you are upset and don't know what to do.

You learned the painful lesson. What would be a good way to react to this and future situations in your career? Talk to your manager/supervisor/tech lead. You should have the records which indicate that you had done the code, such as version history (you do have CM control, don't you?). Tell them the story and present the evidence. Let the managers handle the matter. It's their job. From now on, always remember, procedures are there for reasons. Please follow them.

If your company don't have the procedures such as how to release the code. Propose to the manager/company to have them in place in case similar things happen again. Why those procedures are important are complicated matters and are out of scope of this question.

  • Our only procedure to release code is when it reaches a point where we achieve 100% of the goals set out to accomplish are met and it passes a QA check of at least 5 other developers when released to get checked. I was still working on the code it was about 80% done with some potential bugs that were not fully tested for yet. The co-worker asked for this code because s/he needed to use a few of them. I clearly let them know it wasn't ready as well as my manager and I still was blamed when the code was mass sent saying it created errors. Thanks for your reply, I'll be more careful in future. – Khaltazar Nov 2 '14 at 19:20
  • 5
    "QA check of at least 5 other developers". How did she get past that QA check? – tymtam Jul 27 '17 at 5:16

From 20+ years in software engineering, I feel the answer to your questions is 'Change your attitude' - try to stop viewing things as 'your code' and think of it as through you are contributing to the 'Organisations code' - it's a group ownership thing and the code you create is indeed not lawfully yours (in most cases!). By forming attachments to pieces of software you're mentally setting up boundaries of what is acceptable, when someone is touching 'your stuff' or impacting you. Sure, you might well be the best equipped to modify a specific class, function, etc but it's not your responsibility to do so, it's down to resourcing decisions by your manager.

By surrendering that possessive mindset you become, in my experience, a much happier, more productive team member who is capable of taking on a far wider variety of tasks across the whole range of software that we, as a team, support.

From that point of view the idea of 'my bit' of code is alien and seems petty in some ways, and almost guaranteed to lead to situations where the coder is hurt or upset by someone else writing, modifying or using something that which is viewed (incorrectly) as their personal possession.

So my answer is: Thank them for the edits and look over those to see if you learn something. In future, develop code recognizing it is not yours nor are you personally responsible for doing anything other than writing great quality code for your employer. Try to contribute to your team as the superb coder you presumably are, rather than risking coming across as jealous or precious.

Hope you get this resolved to where it doesn't bother you

  • 1
    So what you're saying is that the other person can simply take credit for OP's work, and OP just has to shrug it off because "it's for a greater cause"? That can't be right. – Edwin Lambregts Jul 4 '18 at 13:49
  • Agree - the "my code" versus "their code" clearly indicates that there is a mindset to change because it isn't. OP should consider learning how to release version 0.1, 0.2, 0.3 and get feedback because if that had been done this wouldn't be an issue. – Thorbjørn Ravn Andersen Jul 4 '18 at 13:58
  • this is terrible advice and not how anyone gets promoted in the workplace. – bharal Jul 4 '18 at 14:04
  • 3
    @EdwinLambregts Source control will readily reveal who wrote the code. I am not suggesting anything about credit for work but rather writing code without trying to assume ownership of it – Dave Jul 4 '18 at 14:23
  • @bharal Everywhere is different, and we all have very different experiences. I absolutely disagree that this is either terrible advice or that this would impact promotion. Having adult coders who behave as adults, rather than spoiled children is pretty much how most businesses work but of course your mileage will vary – Dave Jul 4 '18 at 14:26

As scaaahu said, follow a procedure (even if it is your own suited to your own needs) and make it a habit.

Keep all correspondence regarding your work and be very clear in wordings, especially on restrictions of use by others.

For it to be "your code" you need to prove in case of legal disputes that you not only did it in your spare time, but also didn't use any company property.

Working on own projects by employees of a company should be done using own equipment, licenses and on non company premises (i.e. public space or at home) to make this as easy and airtight as possible.

Your Answer

