My coworker rewrote all my code, what should I do?
Question
Answer
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
More questions from users:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
7 Comments
In my experience, letting go of being attached to my code made collaborating much easier. I realized code is always evolving, and what matters is how it contributes to the project, not who wrote it. Talking with colleagues about why changes were made helped me see the bigger picture and learn. It’s more about improving the team’s work than individual ownership.
I had a time when my code got totally scrapped and rewritten by a more seasoned team member. At first, it stung, felt like all that effort went into the bin. But honestly, looking at the bigger picture, it was a move that made sense. The project benefited from a cleaner, more efficient codebase. It pushed me to level up my skills. The key I learned is to detach a bit from the work. Code is part of a bigger team effort. Getting feedback and embracing change really speeds up personal growth and improves the project. So yeah, it’s tough but super worth it in the end.
Absolutely resonate with the notion of detaching from one’s code. It’s something I had to learn the hard way early in my career. Viewing code as a collective effort rather than a personal masterpiece does wonders for both personal growth and project outcomes. It’s also essential that we foster environments where learning from each other, especially from those with more experience, is encouraged and seen as an opportunity to improve. And yes, communication is crucial; being proactive about seeking feedback and understanding decisions not only helps with current projects but sets a positive precedent for teamwork and project management.
When my (subjectively) structured code was drastically altered by a more senior colleague, it initially felt like my hard work was dismissed. However, when i approached them, asking about the rationale behind those changes — they explained everything step by step, especially around improving API efficiency and maintainability. so it went well for me, I learnt a lot, so i don’t think you should worry if someone rewrites your code, there must have been a reason.
When I first had a chunk of my code rewritten by a more experienced dev, it hit hard. I spent hours on what I thought was a clever solution, only to find it replaced by something far more absracted. It was a tough pill to swallow. Now, I approach my projects with the mindset that code is transient, always ready to evolve or be replaced.
Letting go of personal attachment to code can be hard, but it’s crucial for growth. Treat every change as a learning opportunity and always aim for what’s best for the project. Embrace collaboration, and remember, staying adaptable is key in this ever-evolving field.
I respectfully completely disagree with the answer here. Why would a company want to pay two people to do one person’s job? This indicates massive structural or managerial problems.
According to the writer, his code was functioning perfectly fine. A large refactor should have been discussed for potential ROI before investing the time of an additional developer to complete.
Secondly, if writer’s code was so much of a problem it needed to be refactored this should have been caught during code review. Things aren’t perfect so maybe requirements changed after the fact or this realization came after it was merged. In which case, paragraph 1 still applies.
Lastly, in my opinion, the other developer waiting until writer went in vacation is suspect and bad practice. This refactor should have been done with the acknowledgement and feedback of all stakeholders. What, are we all supposed to be afraid to take vacations in case our co-workers decide to pull some game of thrones moves in our absence?!