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

24 February 2024

Hello Vadim,

I'm reaching out to you for some advice, as something weird happened, and I'm not sure how to react. Here are the key points

For the past six months, I've been working in my role as a Python Backend Developer, diligently maintaining and extending the Python backend for one of our services for the main product. I was diligently following the guidelines for the code, for the pull requests and deployment in general. Rarely was the code returned from the QAs back to me, only in rare cases, usually all the business requirements have been fulfilled and the code was working as expected.

Enter my coworker: a senior developer with six years of seniority, who also does some managerial multitasking. His main domain is the the java backend and he's a workaholic and a control freak to say the least.

A month ago, I had to take a month-long sick leave / vacation. Upon my return, I was greeted with the news of "some changes" to my code, casually mentioned by my coworker. "Some changes" turned out to be an understatement. My entire codebase was unrecognizable, replaced completely during my absence by the senior dev mentioned above. The endpoints that I have written were returnin different data now with different structure.

"I just switched from json to protobuf" he said. But the reality was far more drastic. My code โ€” meticulously written and documented over half a yearโ€”had vanished, replaced by a new structure that, while probably superior in its modularity and object-oriented approach, left me dazed.

My original code, though perhaps more personal, was efficient and functional. It did what it needed to do. The new code, with its model-view-controller-repositories structure, is undeniably an improvement in many technical aspects. Yet, here I am, feeling demoralized, questioning my abilities, and staring down the daunting task of familiarizing myself with this alien codebase. This experience has thrust me into a bout of impostor syndrome, grappling with the fear that my contributions might not measure up and will eventually be overwritten by others.

So, here I am, turning to you for your thoughts on this situation. Is refactoring someone elses code without their permission fine? How should I react? And, perhaps most importantly, how do you rebuild confidence in your abilities when it feels like the rug has been pulled out from under you?

Warm regards,


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.


Hot! The last couple of years I've been writing about CTO / Tech lead job. I've compiled all my knowledge into a printable PDF. I called it "256 Pages of No Bullshit Guide for CTOs". So if you're interested, take a look.

New! If you're a software engineer looking for a job, I started a Roast my Resume service, where I record a personalized video of me "roasting" your CV, which basically means taking a hard look at your resume as a CTO and commenting on all the good and the bad parts.

  • Hazel

    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.

  • Igor

    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.

  • Ryan Fields

    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.

  • Daisy F.

    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.

  • Ava L.

    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.

  • Mia

    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.