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

Question

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,
Robert

Vadim Kravcenko · Accepted Answer

Dear Robert,

The two-sentence version: the code isn’t your code, and feeling bruised about it is normal. Everything after this sentence unpacks those two facts (and, fair warning, wanders a bit—I’m writing between meetings).

I’ve walked into the office after a week away—laptop still in my backpack, coffee half cold—opened the repo, and realised half my service layer had vanished. That first hit of “who deleted my stuff?” stings. It also wears off quicker than you’d think once you start reading the diffs.

Legally and practically the company owns the bytes. I know you know that, but I still need to type it because I forget myself from time to time (especially when a PR title mentions “total rewrite” of something I spent a weekend polishing). The code is scaffolding for business value—no more sentimental than the Philips head in your toolbox.

You said the rewrite came from someone with more years under their belt. Fine. Still, a wholesale do-over often screams process gap more than it does “heroic cleanup.” Design reviews, pairing, even a five-minute whiteboard session could have surfaced the issues earlier. If none of that happened, the team rhythm needs tuning as much as the codebase. (I could be wrong—maybe there were docs and you just missed them—but nine times out of ten this is a signalling problem, not a talent problem.)

You were on medical leave for a month, company policy says “do not disturb,” and management didn’t want blockers piling up. I get it. Still, a lightweight heads-up in the PR description—“Refactoring Robert’s endpoints to match new pattern, will loop him in when he’s back”—would have taken sixty seconds and saved you the ambush feeling. Worth suggesting for next time.

Now to the practical bit. Consider having a 30-minute 1-on-1 with the senior. Approach it with curiosity rather than grievance. You might say something like: “I noticed you split the handler here—what if we’d broken it one level higher, how would that affect testability?” This can be a concrete, neutral way to invite teaching. The good seniors often take that bait and start diagramming faster than you can open Miro.

If the skill gap turns out wider than you thought, lean into a mentoring setup. Pair-refactor one endpoint together, keyboard swap every 15 minutes. That turns the monologue of a code review into dialogue, and you’ll absorb naming conventions, mental models, the whole invisible layer that rarely makes it into comments.

On the process side, propose a ritual: small design docs before large changes, followed by async comments and a quick call. Nothing heavyweight—two pages is plenty. The goal is to surface “let’s rewrite everything” signals early enough that people can argue before the commit bomb drops.

Every developer I know (myself included) has had code replaced wholesale. The separator is whether you make it a story about betrayal or one about leveling up, though not all situations resolve neatly and some challenges may persist. I’ve flopped both ways; the learning version feels better and, funny enough, gets you promoted faster.

You said the new structure feels overwhelming. Pick the smallest slice—one controller, one repository—read it until the abstractions click, then write a docstring in your own words. Tiny victories accumulate, and you’ll spot patterns sooner than you expect. Ask questions in Slack threads so the answers stay searchable; future-you will thank you.

Last thought: detaching from code doesn’t mean detaching from people. Healthy collaboration—stand-ups, spontaneous design chats, that random “got a minute?” message—prevents surprises. Zero interaction is cheaper in the short run and viciously expensive later; I’ve paid that invoice more than once.

This rewrite won’t be the last time your work gets bulldozed, and someday you’ll be the one swinging the bulldozer. Keep the empathy handy for that moment.

Cheers,Vadim

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

More questions from users:

Worried your codebase might be full of AI slop?

No-Bullshit CTO Guide

7 Comments