How do I deal with people who throw away my work?



  • I've had a surprising amount of my work lost to merge conflicts from colleagues and I've got so many bugs in my emotional intelligence I'm permanently pissed about it. The first I find out about my code being thrown away is when I'm looking at my code and finding bugs I've fixed before or when somebody tells me the bug I fixed is still there.

    The first couple of times I had this happen in previous jobs I wondered if it was a weirdly passive-aggressive way of telling me I'd done it wrong. Now I intend to treat it as an accident after the numerous times it's happened in my current role, but it still makes me mad because when I get messages from people telling me the bug I said I'd fixed is still there, in this company it later turns into complaints about "performance issues" and an "attitude problem".

    I can't see beyond my desire to burn the entire world down, so I'm asking you guys for input. How do I deal with people who mindlessly throw away my changes without telling me, and how do I learn to stop thinking about them like they're robots programmed to click "take mine"?



  • @shoreline I don't know how to solve the social side of this, I end up feeling similarly aggrieved when this happens.

    You might be able to alleviate part of the problem (that people are doing merges carelessly) if you're in a position where you can add new regression tests at the same time. If, at a fine-grained level, you make sure that everything you modified is tested then that can help nail your changes in place. That does add a lot of tedious test writing to your workload.


  • kills Dumbledore

    If people are regularly doing bad merges that throw away work then the need to be taught how to merge properly. External trainers?

    Clearly, coming in and saying "you idiots keep fucking up your merges. You need to be shown how to do it" (or anything that could be construed as that, which covers much more mild versions) would be counter productive.

    Id say this is a place for a lot of self deprecation. Structure a request more like "I'm sure I'm missing something when it comes to merging code in heavily contested areas. I'm always worried I'm going to overwrite someone else's code by accident. Could we have some sort of training course so we can all learn how to get the best from our tools?"



  • This is where automated tests can be handy, since they should start breaking after the merge errors. This would represent a non-social solution to at least detecting and highlighting the problem. Of course, ideally, your merging colleagues would detect the problem and fix it before they commit the merge, but it sounds like they already don't give a shit, so...

    I have no knowledge of your code base. Is it really very common for multiple people to be working on the same parts? Is there a lead or manager that delegates that work? Are they and others on the project familiar with the problem?

    I hope that you at least report back up the chain what happened. "I fixed it in r123 and then the fix was removed in r324 by John Doe."

    I have recently been subject to similar rages so I definitely sympathize.



  • @shoreline You don't do code reviews? Start.



  • @japonicus said in How do I deal with people who throw away my work?:

    You might be able to alleviate part of the problem (that people are doing merges carelessly) if you're in a position where you can add new regression tests at the same time.

    Yes also this. The odds of them throwing away your fix and the test proving the fix are much lower than either alone.

    But also start doing code reviews. If you're not looking at their merges before they happen, this problem becomes like 30 times worse. EDIT: also if you don't do code reviews, what stops him from just disabling or deleting the failing test?

    Also start keeping your own copy of your changes, if you don't already.



  • While I agree boomzilla 100% - there is also the likelihood that they will throw away your automated tests also :(

    One way to mitigate is to minimize merges! Remove gates, keep them simple (for those cases where branches absolutely need to be used in the first place, have them be quick (why is it more than 30 minutes before your changes are merged in?



  • @thecpuwizard said in How do I deal with people who throw away my work?:

    While I agree boomzilla 100% - there is also the likelihood that they will throw away your automated tests also :(

    Making a mess of merges can be down to incompetence, but if they throw away tests then that's pathological and you've got much bigger problems. I don't think that's likely though. It seems better not to assume malice (if only for your own sanity).

    One way to mitigate is to minimize merges! Remove gates, keep them simple (for those cases where branches absolutely need to be used in the first place, have them be quick (why is it more than 30 minutes before your changes are merged in?

    Avoiding large complex merges sounds great, but requires everyone else to co-operate.



  • Yeah, I was assuming incompetence not malice. If it's intentional then it's someone sabotaging the code and they need to be fired. Either way, this is probably something that needs to be brought to management to correct. If it was a one time thing, then a discussion among peers is appropriate to figure out what happened and avoid it happening again but repeat events require someone with authority to step in.



  • @shoreline said in How do I deal with people who throw away my work?:

    I've had a surprising amount of my work lost to merge conflicts from colleagues and I've got so many bugs in my emotional intelligence I'm permanently pissed about it. The first I find out about my code being thrown away is when I'm looking at my code and finding bugs I've fixed before or when somebody tells me the bug I fixed is still there.

    The first couple of times I had this happen in previous jobs I wondered if it was a weirdly passive-aggressive way of telling me I'd done it wrong. Now I intend to treat it as an accident after the numerous times it's happened in my current role, but it still makes me mad because when I get messages from people telling me the bug I said I'd fixed is still there, in this company it later turns into complaints about "performance issues" and an "attitude problem".

    I can't see beyond my desire to burn the entire world down, so I'm asking you guys for input. How do I deal with people who mindlessly throw away my changes without telling me, and how do I learn to stop thinking about them like they're robots programmed to click "take mine"?

    Use commit history (whatever VCS you use(1), there will be enough history!) to find out (a) if your memory is faulty and (b) if not, who made the commit that unfixed your fix.

    If it's always one particular person, it's manager time, at least for advice on how to handle it.

    If it's more than one person, especially if it's more like "all but two", then you have a systematic failing, and it's manager time.

    Pretty much no matter what you find, with one exception, it's going to end up being manager time. Or recruiter time. Take your pick.

    The one exception? If it's one person, and that person is you. In that case, slap yourself around and stop doing whatever it is. I don't recommend taking that to your manager.

    (1) You do have source control, right? And unit tests / regression tests?(2)

    (2) As suggested, if you have such tests, and your colleagues are breaking them by unfixing your fixes, and they fix the tests by modifying them or removing them, then it's manager time, times two.(3)

    (3) If you *don't have such things, and there is resistance to adding them, then it's recruiter time.



  • @japonicus said in How do I deal with people who throw away my work?:

    regression tests

    @boomzilla said in How do I deal with people who throw away my work?:

    automated tests

    Good idea. I've actually put my notice in to leave this place but I checked and the new place seems more open to, like, actually doing these. I can't (be bothered to) make the change here by my last day (Tuesday) but it makes me feel better about my new place.

    @jaloopa said in How do I deal with people who throw away my work?:

    I'm sure I'm missing something when it comes to merging code in heavily contested areas. I'm always worried I'm going to overwrite someone else's code by accident. Could we have some sort of training course so we can all learn how to get the best from our tools?

    I like it. I mean, I don't think I've thrown other people's code away by accident, but then how would I know? I tend to just put a link to my PR on group chat and tell people I've had conflicts so they should try and spot check any issues. Still "I worry I might make this mistake" is a good place to start. Thanks.

    @boomzilla said in How do I deal with people who throw away my work?:

    I hope that you at least report back up the chain what happened.

    Alas, no I was frightened it would come out like "piece-of-shit waste of space and air 'Derek' dumped my code and I only found out when dumbass 'Paul' told me the bug I'd fixed wasn't fixed", hence my question now. Admittedly I wasn't in a good place emotionally because the talentless lead who got fired for not doing PRs properly managed to get a complaint through that I "refactor things I shouldn't" and the delivery managers who knew the frontend had just been torn apart by non-frontenders and replaced by a backend-run jQuery replacement which after several months didn't compare in functionality or pattern consistency to the original SPA complained about my performance. At least I think those were the guys that complained, the complaints were technically anonymous. I had to extrapolate.

    You're right though, it should be raised.

    @blakeyrat said in How do I deal with people who throw away my work?:

    code reviews

    We did PRs, but I guess those weren't enough.

    @blakeyrat said in How do I deal with people who throw away my work?:

    disabling or deleting the failing test

    Reasons I think low coverage should fail the build. Also linting. Also having CI at all.

    I do appreciate all the input guys, thanks.



  • @shoreline said in How do I deal with people who throw away my work?:

    Alas, no I was frightened it would come out like "piece-of-shit waste of space and air 'Derek' dumped my code and I only found out when dumbass 'Paul' told me the bug I'd fixed wasn't fixed", hence my question now.

    Yeah, without a long history of a common shared belief about those descriptors (and there is one person here who could live down to them) I wouldn't have put it that way. More of a factual thing, preferably in writing.

    @shoreline said in How do I deal with people who throw away my work?:

    I "refactor things I shouldn't"

    Well, that sort of thing is dangerous, especially when you don't have automated tests to find regressions and it definitely can cause merging conflicts. But I suspect you have a different view on what happened and I can't say that you actually did that.



  • IMO merges and conflicts are a fact of life, but extremely complex conflict resolution should be relatively rare. If two people are working on the same lines of code simultaneously too often, it's indicative of a workflow problem where you aren't properly identifying critical paths in a project. There will always be those little conflicts here and there, but if you're encountering merge conflicts to the point where people are stumbling on them routinely, you've got to identify why that's the case. Common reasons:

    a.) You are leaving branches hang for too long. Extremely long-term tasks should be a rarity and only be done for very good reasons. If you do have a long-term branch, merge from trunk often, so you're only dealing with (hopefully) minor conflicts instead of having them snowball into bigger conflicts if you do them more infrequently.

    b.) You have too many monolithic files that require many hands in the pot for otherwise separated tasks. Make sure you are following SOLID principles.

    c.) You are assigning tasks to different people that touch the same code. If you have a set of tasks that involve the same area of code, it's best to just assign them to the same person, since they'll have all the visibility of the moving parts as they are merged together.

    d.) If you can't avoid assigning similar tasks to different people, then get on your preferred mode of communication and talk about it. Someone should let them know that there is the possibility of some toe stepping if you're unaware of it, and be especially wary of merge conflicts. Not that you shouldn't always be wary of them. Whenever I get a merge conflict, I look damn closely regardless of whether I think it's trivial or not because as a rule of thumb, no merge conflict is ever trivial enough to deal with willynilly.

    e.) If you have resolved a-d and you still have problems, do some training. See what people are doing when they merge. If they're blindly just accepting only their changes and dismissing everyone else's, hit them with a clue-by-four.



  • @shoreline said in How do I deal with people who throw away my work?:

    We did PRs, but I guess those weren't enough.

    I mean YOU need to do ALL the code reviews. If the problem is YOUR code is getting deleted, you need to start hitting that "reject" button when you see the problem.

    If your boss complains you're spending too much time on code reviews and not enough time on development work, explain to him why you can't trust anybody else to do code reviews.


  • :belt_onion:

    @shoreline said in How do I deal with people who throw away my work?:

    How do I deal with people who mindlessly throw away my changes without telling me

    Check your changes into source control



  • @japonicus said in How do I deal with people who throw away my work?:

    but if they throw away tests then that's pathological and you've got much bigger problems

    That's when you kick it up the command chain and make it your boss' problem!

    edit: :hanzo:'d


  • Impossible Mission - B

    Merge conflicts are a sign of a project management problem. If you and Bob are both working on the same part of the same code at the same time, and it happens repeatedly, that's the first thing you should be looking to fix. Talk to your PM about that.



  • @boomzilla said in How do I deal with people who throw away my work?:

    I hope that you at least report back up the chain what happened. "I fixed it in r123 and then the fix was removed in r324 by John Doe."

    "I have reverted back to r323; pray I do not revert it any further." :trolleybus:



  • @masonwheeler said in How do I deal with people who throw away my work?:

    Merge conflicts are a sign of a project management problem. If you and Bob are both working on the same part of the same code at the same time, and it happens repeatedly, that's the first thing you should be looking to fix. Talk to your PM about that.

    Sometimes they are unavoidable. Say, adding new message types to a globally used enum. Or refactoring some utility classes.


  • Impossible Mission - B

    @gąska Sometimes, yes. But when it starts happening on a regular basis, as appears to be the case here, that's a sign of bad project management.



  • @anotherusername said in How do I deal with people who throw away my work?:

    @boomzilla said in How do I deal with people who throw away my work?:

    I hope that you at least report back up the chain what happened. "I fixed it in r123 and then the fix was removed in r324 by John Doe."

    "I have reverted back to r323; pray I do not revert it any further." :trolleybus:

    I have done that in the past.



  • @The_Quiet_One outlines a set of best practices that we'd be wise to follow.

    At NodeBB, we don't really tend to make wholesale changes to the entire codebase anymore. Some ambitious pull requests try, but then they conflict out in a matter of minutes, which really sucks for the author.

    Internally, we try our best to ping each other when working on large refactors.

    Hey, is anybody working on flags pages in core? I'm about to start making a lot of changes that might conflict

    Serves a dual purpose:

    • If someone has already started making changes to flags, they can shout out "yes, can you hold off for X hours while I wrap up?", and the other dev does something else for a bit. There are very few reasons for a developer to have to get his changes in ASAP.
    • If someone is intending to make a change, albeit a small one, it's more courteous to wait for the large change to land and then merge your change in, as opposed to the other way around.

    @Shoreline If you're running into repeated situations where your code is overwritten due to a bad merge, then it is indicative of a problem with the other developers not resolving merge conflicts properly. Education is the solution here.

    ... either that, or maybe they need more sleep. There was a week awhile back where I made successive bad merges over and over again, re-introducing bugs left, right, and center. Being aware of that and self-selecting the problem out is important too (in my case, I logged off and made sure to sleep more... after reverting my bad merges, of course)


  • Impossible Mission - B

    @julianlam There was a point where I kept making bad merges several years back. I wasn't sleep-deprived, and I couldn't figure out what was going wrong, until I did a bit of digging and discovered that my 3-way merge tool was misconfigured, displaying the root revision as one of the 2 branches and vice versa. Fixing that fixed the problem.


  • :belt_onion:

    @boomzilla said in How do I deal with people who throw away my work?:

    "I fixed it in r123 and then the fix was removed in r324 by John Doe."

    This. Delivered matter-of-factly. It’s a root-cause analysis, not an accusation.

    In a legacy codebase some things are not testable.


  • Discourse touched me in a no-no place

    @shoreline said in How do I deal with people who throw away my work?:

    I can't see beyond my desire to burn the entire world down, so I'm asking you guys for input. How do I deal with people who mindlessly throw away my changes without telling me, and how do I learn to stop thinking about them like they're robots programmed to click "take mine"?

    We addressed this by taking away everyone's permission to commit to mainline branches. We do our work on a development branch, commit that, check that it passes the tests and other post-commit checks, then get someone else to do a code review and confirm of a merge to the relevant mainline branch. (Some of us actually have the power to commit directly to mainline, and we keep it for where we need to unbreak things rapidly; we follow the standard development pattern normally.)

    In management terms, the commit timeline can be surprisingly useful. Changes to the functionality in mainline (which is what actually counts) are easy to see as merges, and at least with some tools you can also probe the history for individual files to see where a file was modified and so track down what actually happened. You want management to be able to do this without you sitting with them. IME, it's pretty easy to sell them on the benefits of this sort of thing, as you can talk about empowering them to see what their developers are really up to, and I've yet to meet a manager who wasn't curious about that at least some of the time. ;)

    If there's too much wiping out of work, either the tools are seriously wrong or the code layout is seriously bad or the culture is plain old toxic. Bad tools should be fixed or replaced. Poor code layout can be corrected over time if people are willing (usually; it's harder with things like game assets than with code). Toxic workplaces aren't fixable unless the toxicity resigns or gets the boot, and sometimes it is easier to just leave yourself. :(



  • @greybeard said in How do I deal with people who throw away my work?:

    @boomzilla said in How do I deal with people who throw away my work?:

    "I fixed it in r123 and then the fix was removed in r324 by John Doe."

    This. Delivered matter-of-factly. It’s a root-cause analysis, not an accusation.

    In a legacy codebase some things are not testable.

    Yeah. I also own up to my regressions. And I usually just say, "This broke as a result of work for JIRA-1234." Obviously, you can just look at the ticket and see whodunnit.



  • @dkf said in How do I deal with people who throw away my work?:

    In management terms, the commit timeline can be surprisingly useful. Changes to the functionality in mainline (which is what actually counts) are easy to see as merges, and at least with some tools you can also probe the history for individual files to see where a file was modified and so track down what actually happened. You want management to be able to do this without you sitting with them. IME, it's pretty easy to sell them on the benefits of this sort of thing, as you can talk about empowering them to see what their developers are really up to, and I've yet to meet a manager who wasn't curious about that at least some of the time.

    What does that mean in practice? Are they looking at commit messages? Comparing commits to CI results? Examining lines of code?

    My management is...semi-technical. They wouldn't be able to go down to the level of inspecting code.


  • Discourse touched me in a no-no place

    @boomzilla said in How do I deal with people who throw away my work?:

    What does that mean in practice? Are they looking at commit messages? Comparing commits to CI results? Examining lines of code?

    I was thinking about a tool like the github commit timeline or the other informational tools that they provide (particularly since we use github for our code repos, both public and private). Yes, with that you can drill down to actual code, but the wider picture is there as well.



  • @boomzilla said in How do I deal with people who throw away my work?:

    @anotherusername said in How do I deal with people who throw away my work?:

    @boomzilla said in How do I deal with people who throw away my work?:

    I hope that you at least report back up the chain what happened. "I fixed it in r123 and then the fix was removed in r324 by John Doe."

    "I have reverted back to r323; pray I do not revert it any further." :trolleybus:

    I have done that in the past.

    True.

    If it's provably broken because of the newest revision, then that revision broke it.



  • @dkf said in How do I deal with people who throw away my work?:

    We addressed this by taking away everyone's permission to commit to mainline branches

    This. Only two of us can commit to mainline now, and we check in each other's stuff as a double check.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.