My coworker rewrote all my code, what should I do?

Table of Contents

Dear Robert,

The short answer is — stop getting attached to your code. Now lets continue to a more detailed explanation.

I understand that coming back to find your codebase entirely rewritten has been a tough pill to swallow. It’s a situation many of us have faced at some point in our careers, and while it’s never easy, there are important lessons to be learned here.

First off, it’s crucial to remember that the code we write at work doesn’t belong to us. It belongs to the company. This is a hard truth that takes time to accept. Regardless of how attached you get to the code, how creative you are, how in love you get with the lines that you write — the code is a tool that is used to bring the company some form of value, it’s not your baby that you need to caress.

As you mentioned your coworker is also your senior in terms of experience overall and probably at the company as well. Their decision to rewrite your code, while shocking, was likely made in the project’s best interest, leveraging hindsight and insights that weren’t available when you first wrote the code. You’re saying the code did what it needed to do, but it might be that the senior developer is trying to standardize the way the API endpoints are being developed, and your was next on the list.

I do understand the frustration, and I think the best approach would’ve been to notify you and tell you that it needs to be refactored and improved — but you were on vacation for a month, calling you and asking about your code would go against the company policy. So assume they had their best interest at heart when a) they did not want to disturb you on your sick leave and b) they wanted to improve the codebase overall.

Seeing your work replaced can feel personal, but it’s not. Your situation is actually a golden opportunity for learning. Your coworker, with more experience, has shown a different approach to solving problems. Instead of dwelling on the feeling of loss, try to understand the rationale behind the changes. Set up some 1:1s with them, ask them some question regarding their decisions, maybe it will be more clear to you why the decision was made? Don’t approach this from a negative side. Why was a model-view-controller-repositories structure chosen? What benefits does it bring? This is your chance to dive into these concepts, which might seem daunting but are fundamental to growing as a developer.

I suggest reaching out to your coworker for a detailed discussion. Ask them to walk you through the changes and the reasons behind them. It’s about understanding the larger picture, including company strategy and technical debt reduction, which often influence such decisions.

For the senior development you can suggest improvements to communication. Propose regular check-ins or code reviews with your team. This ensures that everyone is on the same page and that you’re involved in the evolution of the project, even when decisions are made in your absence.

Remember, every developer has had their code criticized or replaced at some point. It’s a normal part of the job. What separates good developers from great ones is the ability to learn from these experiences, to not take them personally, and to use them as stepping stones for improvement.

You mentioned feeling overwhelmed by the new codebase. That’s understandable. But don’t let it hold you back. Set small, achievable goals for yourself. Each piece of the new structure you understand is a victory. And don’t hesitate to ask for help. If your coworker has taken the lead on this, they should be willing to guide you through it.

Finally, detach from your code. You are not your code. It’s a tool, not a reflection of your worth as a developer. Your ability to adapt, learn, and grow is far more valuable than any single piece of code you write. Embrace this as an opportunity to expand your skills and knowledge.

In conclusion, while this situation is challenging, it’s also a powerful opportunity for growth. Approach it with an open mind and a willingness to learn. The skills and insights you gain from this experience will be invaluable as you continue your journey in software development. Eventually you will be the one who’s refactoring someone elses code while they have a month-long sick leave, and the cycle will continue, so keep that in mind next time you think of refactoring.

Cheers,
Vadim