How to react to someone who publishes your code when you told them not to?

Question

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?"

Answer 1

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.

Answer 2

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

Answer 3

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.