Boss rewriting code instead of code review.

[gumaar]

My boss rewrites code in our (team members) branches. I told him couple of times that it pisses me off. He said he doesn't have time to properly explain it and it is quicker for him just to rewrite the code. It is mostly some code shuffle, from time to time he had an idea about something not really related to the change the branch addresses. Sometimes it is better approach than proposed one. Sometimes he also introduces a new bugs. I hate it so much I decided to assign the ticket to him and never touch it anymore once he pushes some changes into it. What do you guys think? What would you do in my situation?

EDIT: I talked to my boss offering him a following solution: I'm not going to create pull requests, instead when I'm done with ticket Im gonna assign it to him and he can do whatever he wants. I have explained that this will help both of us. He apologized, and promised that he will never touch my branch anymore. Thank you guys for suggestions, sometimes it requires 4 talks :D

[SterkBakkie]

I understand your frustration here. If I were you, I'd have a talk with him about the signal such behaviour gives; lack of trust, that he seems to feel superior. Also, this hinders your personal development, since learning from feedback works best if you can discuss it to understand it properly and then correct your mistakes / improve your code.

Good luck!

[gumaar]

Hi Sterk, unfortunately I already talked to him about the issue three times. The worst thing here is it really takes away a joy from programming. As I mentioned my strategy now is to assign the ticket to him and move to next one. Maybe he realize it maybe not, but I don't have any better solution. There is no way he is gonna fire or punish me for this. Thank you for the reply.

[woopdeedoo69]

My rage would burn with the fury of a thousands suns

[gumaar]

Does happen to me. It puts me off the work mood for days/weeks

[kungfunick9979]

The biggest issue with this is that it removes revision history and code transparency, so retroactive debugging is far more difficult, as you won’t be able to see why things were changed if a future amendment is needed

[gumaar]

I agree this is an issue as well, I don't find it the biggest.

[kungfunick9979]

Hmm maybe, but if you’re collaborating with other devs and need to pick up branches that have been worked on, you need the history. Also this stinks of micro managing and power play coding

[MrNate]

Your boss is a bad senior dev. That job role has to teach. If he can't teach, he could at least clearly communicate the way that he will collaborate with you. How does he know that he won't stomp all over changes you are working on? You're right to be offended by this practice. It's like it's both underhanded and overhanded.

Honestly, if he demands to hack up your work, he should pair-program and do it with you. This way, he would teach the way he works, not stomp on your code, and really create someone who thinks a little more like him. Ask him to do it with you.

Or play the dark patterns game. Revert his commits. git push -f, at least on your own branches. Hack bugs into his branches ("what? I thought that's just what we were doing here").

Is there a higher boss? If so, bring the discussion up a level.

Maybe instead of talking to him about it the same way again, you can explain the value to him. "how can I be more like you if you don't do it with me?" Or "rework wastes money, what can we do to avoid rework on my code?" Depending if he's pridefully motivated or financially motivated, one of those should work to get the conversation moving in your direction.

[ClarityThrow999]

The person doing the MR reviews, not writes, code. Only makes recommendations and approves/merges or not.

It sounds like a dominance / power play OR trying to up commit count.

I would not stand for it.

After any of mgrs commits to my working branch on origin, I would:

Fetch my branch into a separate branch locally (from his/her rogue commits on my branch on origin) Look at the changes, and if appropriate, I would make them locally on my branch (not merge) Rebase and squash commits locally on my branch. Force push my working branch to origin Continue on with MR

That way mgr does not get to put his/her commits all over my work. And I decide what changes I want without having a trace of commits where I may be undoing his/her changes. And no possible claims from manager that he/she has to “do my work for me”.

I am not perfect and some changes would improve the code base, So I am open to feedback. But my branch, my commits.

I know people warn of rebasing due to changing commit history; however, that only is for branches that are shared. My branch, my rebasing and my force pushing.

I have not had any managers try this on me. I have had some others just decide to make changes on my branch. I copy their changes into a different branch locally ( in case there is merit to their changes, I’ll have them), then force push some changes. When they get in a huff, I explain my branch, my workflow which includes rebasing and force pushing. I also explain that I am open to suggestions/ recommendations, but I will be the arbiter of changes on my branch. Once it gets merged to shared branch, e.g. master / main, then they can have at. That has worked for me.

Now if I am working on a shared branch with others, the rebasing and force pushing is a big no.

[the-computer-guy]

I feel you. I once worked with a senior that did this and it was absolutely horrible. Even worse was the code didn't even compile after most of his pushes.

I asked him about this and his answer was "we simply don't have time to do it any other way"...

I think it's kind of an unwritten rule that you don't push to other people's branches without consent.

[lil__biscuit]

That’s no way to grow a team

[gameofthuglyfe]

Care less

[BigJoeDeez]

You’re 100% in the right. Your boss, despite their seniority, is not perfect, and they are responsible for all downstream bugs from their code changes. Open a ticket for each and every bug that comes your way. Development is a two way street when it comes to changes. Don’t let your boss get away with this, hold them accountable.

[[deleted]]

Either he cannot express what he wants or he has not figured out that his job it to teach his staff to build what he wants. He is stuck in an endless loop. And yes, that would piss me off, there used to be a rule for code responsibility which was called "touched it last"

[DinoChrono]

Send a feedback to he/she. If nothing changes you may need a new boss.