Other devs change my code, break behaviour and I'm asked to fix "bugs"



  • So I just received a list of bugs that I need to fix.

    I haven't gone through all of them but I found one that someone changed my code for some reason and now it's misbehaving.

    Is this normal for a team of developers? Like something inevitable arising from team cooperation?



  • Generally, yeah. Your code isn't "yours" the moment you commit it to the repository. Breaking it is a WTF, sure, but you're better off dropping the whole concept of "my code is mine, your code is yours".



  • It's normal. I think except those on one-man projects, all of us has experienced this kind of thing before, especially if your code don't comment enough to explain the "subtle requirements" of why you write it this way if it's written in a not-normally-used pattern... some others will eventially be "helpful" to "correct" it for you and breaks the code.



  • @Maciejasjmj said:

    you're better off dropping the whole concept of "my code is mine, your code is yours".

    I don't believe I have such concept.

    Perhaps the phrase my code was misleading.

    Anyway, yeah, someone(persone 1) broke it. Person2 tested it and reported it as a bug.



  • @cheong said:

    if your code don't comment enough to explain the "subtle requirements" of why you write it this way if it's written in a not-normally-used pattern...

    Yes, if.

    @cheong said:

    some others will eventially be "helpful" to "correct" it for you and breaks the code.

    Errm, don't people communicate first?



  • @Ascendant said:

    Errm, don't people communicate first?

    Not always.

    Some of us tend to iron out code that does not follow "standard pattern" if they need to change something on that class. (This is especially true for web developers before the time of jQuery because if anything in the page makes the page renders in quirks mode, javascript can break as some modern DOM properties will be missing) They may not have the time / mood to find out all people who code that part.

    Not to mention that most of the time, the blocks that need to change is formed by layers and layers of changes, maybe each changes consist of 2 - 3 lines of code. I don't think they gonna make the changes if they're required to talk with all the people who touch the code before making changes.

    It could be more feasible to just call a meeting for everyone and change it in front of them, but the manhours needed by the change could be skyracketed this way..



  • @cheong said:

    code that does not follow "standard pattern"

    Yeah, if this happens then the team members can use some time talking so as to figure out why the code author did so in the first place and how to prevent it if it was based on unsound reasons. Like, "Don't do that"? lol

    Well, that's only what comes out of my head.

    But yeah, if you're busy or not in a good mood, I guess you could just iron out.



  • @Ascendant said:

    yeah, someone(persone 1) broke it. Person2 tested it and reported it as a bug.
    It looks like the processes in your company work. The bug got caught in the testing phase.

    I would take the opportunity when fixing the bugs to introduce some automated unit tests and make sure other people will get an early warning when changing code that alters the expected behavior.



  • Yeah that would be nice.

    Person1 changed some code I wrote and actually introduced a bug. The reason why I double quoted the word "bugs" is that when I finished it, the internal devs all tested it and confirmed it worked fine.

    And then for some reason, someone changed the code and that introduced an actual bug.

    Sorry if that was confusing.



  • Par the course to be honest. It's why you invest in unit tests. Helps keep the wolves from the door and if you catch them early enough you can twat the fucker with the unit tests and make them fix it.



  • @DogsB said:

    It's why you invest in unit tests. Helps keep the wolves from the door and if you catch them early enough you can twat the fucker with the unit tests and make them fix it.

    That would be awesome.
    That is, if this company had unit tests.
    Not single one of the companies I have worked ever had unit tests.



  • @Ascendant said:

    I haven't gone through all of them but I found one that someone changed my code for some reason and now it's misbehaving.

    Is this normal for a team of developers? Like something inevitable arising from team cooperation?

    This happens quite frequently. I don't see how this is such a Huge Fuck-up, minor annoyance at best. I usually let the person who fucked the code up in the ass know that they did something to my code and please be careful next time. Works pretty much okay.



  • @stillwater said:

    I don't see how this is such a Huge Fuck-up, minor annoyance at best.

    Yes I know. But the "What's the problem guy" has an attitude of "We are all one team, so whoever fucks up, you shouldn't say anything about it".

    So I wanted some sort of second opinion on this.

    Oh wait, then I should have posted this on General Help perhaps.



  • @Ascendant said:

    Yes I know. But the "What's the problem guy" has an attitude of "We are all one team, so whoever fucks up, you shouldn't say anything about it".

    Blaming/shaming people generally doesn't get you anywhere. But that shouldn't stop you from checking who did it and asking them why.



  • @Ascendant said:

    Yes I know. But the "What's the problem guy" has an attitude of "We are all one team, so whoever fucks up, you shouldn't say anything about it".

    99% of the time it is someone who means well and inadvertently ends up assfucking the code. 1% of the time the person knows it might assfuck things but still goes ahead with as much seriousness as possible, but code ends up assfucked anyhow. Both of these cases would only warrant politely informing the person what they did and how it affects the functionality to at the most , a fake stern warning type thingy. The Guy you are talking about on the other hand needs to be told to go fuck off and die in a car fire or some shit.



  • The Team I work in, everybody has a very accurate picture of who fucks up the most , how they fuck up, and who usually picks up the pieces.

    People who fuck up more get more and more unfuckable pieces of code. And the other group learns to code to avoid potential fuckups by means of making the code clear so that its intent is clear, commenting the code properly blah blah...

    It is all pretty balanced I would say.


  • Fake News

    @stillwater said:

    unfuckable pieces of code

    Every time you think that the universe creates a bigger fucker.



  • I think code like the following is pretty much unfuckable. People usually look at it and don't want to do anything with this shit. Actual method does trivial shit like convert a string to an int or even worse just does string.trim() or some silly stupid stuff.

    //DO NOT TOUCH THIS MOTHERFUCKER. DONT EVEN !!
    Private void MethodNameThatlooksTooImportantandDangerous(){
    ...Do shit here that looks even more ominous 
    }
    //METHOD MAKES SURE THE SUN STAYS WHERE IT IS AND EARTH STILL HAS GRAVITY BLAH BLAH.CHANGES WILL KILL ALL LIFEFORMS AS WE KNOW IT !!!!!!!!!


  • No. If the code point is found to be a performance bottleneck, someone will be assigned to look at do something with it, probably cursing as he/she is doing that.



  • What I often do in cases like this is to make sure I mention in the ticket that it was a regression from the ticket that's linked to the changes. Including when it's my doing. Stuff like this happens.

    I wouldn't get angry about it unless it was something that was happening a lot. We have one person who is notorious for this sort of thing so my tolerance for her bullshit is very low. But honestly, it's usually something I did.



  • 4 posts were split to a new topic: Not Helping Racist Misogynist Privilege



  • @PleegWat said:

    Blaming/shaming people generally doesn't get you anywhere. But that shouldn't stop you from checking who did it and asking them why.

    Of course. Blatantly blaming is simply not constructive.

    I only wanted to see if it was okay to even talk about it(regression?) since the "What's the problem guy" seems to have a problem with even bringing it up.

    If this is something I just have to suck it up because this is what happens all the time and is normal, I will do so.

    But for example, I could simply ask the person who fudged it, why he chose to do so. This is not to blame him but rather actually get an understanding of his intentions. This is what I tried last time with the person who fudged something and the "What's the problem guy". Nowhere close to finger pointing. Yet the guy seemed pretty bothered.



  • @Ascendant said:

    But for example, I could simply ask the person who fudged it, why he chose to do so. This is not to blame him but rather actually get an understanding of his intentions.

    This is important. Otherwise you're likely to break whatever he was doing.



  • @JBert said:

    unfuckable pieces of code

    Every time you think that the universe creates a bigger fucker.

    Because when you're at work, all the universe conspires in fucking your arse.



  • Exactly. I may not know but he may had some directions received from other senior devs or whatever.



  • Source Control IS COMMUNISM!!!!11111



  • @boomzilla said:

    @Ascendant said:
    But for example, I could simply ask the person who fudged it, why he chose to do so. This is not to blame him but rather actually get an understanding of his intentions.

    This is important. Otherwise you're likely to break whatever he was doing.

    This is good advice that gets ignored often so you'll see about 10 reverts in the commit log until they stop being childish and doing their fucking jobs.



  • @Ascendant said:

    If this is something I just have to suck it up because this is what happens all the time and is normal, I will do so.

    ABSO-FUCKING-LUTELY NOT !



  • Yeah, all these senior devs of mine may render me more experienced (or not) but I'm pretty much a junior/newb.

    I still have lots to learn.
    I can learn software engineering through books but I couldn't find common workplace practices in software development from books.

    I think that's usually what I can ask my seniors on break times but you know my seniors. :wink:



  • @Ascendant said:

    I still have lots to learn. I can learn software engineering through books but I couldn't find common workplace practices in software development from books.

    Same here. I am learning one or two new things every single fucking day. Shit I cannot conjure up even in my wildest dreams.



  • So what's the problem? Revert person1's changes and mark the bug as fixed.

    If you're feeling adequately passive-aggressive, add a revert notecomment (nobody will read a revert note) suggesting that if someone wants to edit the code in the future they should probably check with the person who originally wrote it to make sure they understand what it's supposed to do (and how).



  • @anotherusername said:

    comment (nobody will read a revert note)

    A comment in whatever tool you're using for source control or project tracking, not in the code, to be specific.



  • You think people read those?

    I meant in the code.



  • Yes, considering it emails you when you @metion someone.



  • Whoa, what part of 'passive-aggressive' suggested that I thought you should @mention anyone?



  • IDK then, email the entire team then. That sort of comment doesn't really belong in code if it was something where the change breaking something was (mostly) obvious that it would break the code.



  • @Ascendant said:

    And then for some reason, someone changed the code and that introduced an actual bug.

    If we're willing to grant that the other developer is competent, it may be that he was working on a different bit of functionality that interacted with your code in a way he did not expect. Perhaps because he did not understand what your code did.

    This might be a sign that functions are doing too much, or classes have too many responsibilities and manage too much state. Small functions that do just one thing rarely need to be touched by other people, minimizing the chance that someone will introduce bugs from unexpected interactions.

    @Ascendant said:

    But for example, I could simply ask the person who fudged it, why he chose to do so.
    You can't fix the bug without knowing why he changed things. Unless he's out to sabotage the product, he changed the code because he needed it to do something other than what it was doing. He may have accomplished his goal, but in doing so broken your feature. If you just fix your part without understanding why he broke it, you'll likely end up breaking his feature when you fix yours.

    What you need is to have both features working properly, and to do that you'll need to understand what both features are, and what possible interactions there are between them.



  • @JazzyJosh said:

    IDK then, email the entire team then.

    The advantage of the comment in the code is that you don't sign your name to it.

    Well, except in the commit history. But again... nobody reads that.

    @Kian said:

    If we're willing to grant that the other developer is competent

    @Kian said:

    Perhaps because he did not understand what your code did.

    Those two statements are mutually exclusive. A competent developer doesn't change code until he understands what it does. Especially when the person who wrote the code is sitting a few cubes away and might be willing to discuss it with the dev if he'd only ask.

    @Kian said:

    If you just fix your part without understanding why he broke it, you'll likely end up breaking his feature when you fix yours.

    Likely so. Acceptable collateral damage. When he figures out how to talk to the rest of his team and understand what the code does, then maybe he can add features without breaking stuff. Until then, anything he commits that causes more problems than it solves should just be reverted.



  • @Ascendant said:

    I don't believe I have such concept.

    Perhaps the phrase my code was misleading.

    I don't know how you could have rephrased that initial post to imply anything else.

    You see the other programmer as an outside force that messed up something you worked on.



  • @stillwater said:

    And the other group learns to code to avoid potential fuckups by means of making the code clear so that its intent is clear, commenting the code properly blah blah...

    That is a good thing to do, even if you wouldn't have codefuckers.

    Especially when you write a piece of code in a non-obvious way (because you have good reasons), add a few lines of comments to the code explaining why you did it that way.

    That might very well prevent someone from later "helpfully" "correcting" your code without realizing they introduce a bug in the process.
    That someone might very well be you from the future.



  • @anotherusername said:

    Those two statements are mutually exclusive. A competent developer doesn't change code until he understands what it does.

    So a competent developer is one that never introduces bugs? I guess I never worked with one yet. I prefer to define "competent developer" as one that can achieve his goal, even if there is a bit of collateral damage along the way. Not great, but capable of transferring an idea to code.

    @anotherusername said:

    Likely so. Acceptable collateral damage.
    Aside from competency, there's professionalism to consider. Your job is to get the software out the door. It doesn't matter if someone broke your code, you have to fix it without breaking more features. Telling them "do it again" is a waste of time. Talk with them to see why they did it that way, explain what your code did, possibly discuss a solution that meets both your needs together, then implement it and move on. If that requires being the bigger man, then be the bigger man. No one wins a race to the bottom.



  • @Kian said:

    @anotherusername said:
    Those two statements are mutually exclusive. A competent developer doesn't change code until he understands what it does.

    So a competent developer is one that never introduces bugs?

    No, a competent developer is one that doesn't change code until he understands what it does.

    @Kian said:

    Aside from competency, there's professionalism to consider. Your job is to get the software out the door. It doesn't matter if someone broke your code, you have to fix it without breaking more features. Telling them "do it again" is a waste of time. Talk with them to see why they did it that way, explain what your code did, possibly discuss a solution that meets both your needs together, then implement it and move on.

    If it's obvious that they were adding a feature then... maybe. However,

    @Ascendant said:

    changed my code for some reason

    indicates that there wasn't any obvious reason for the change. So... revert.



  • @anotherusername said:

    indicates that there wasn't any obvious reason for the change. So... revert.

    @anotherusername said:

    No, a competent developer is one that doesn't change code until he understands what it does.
    If a competent developer doesn't change code until he understands it, then "the reason for this change is not obvious" is not enough justification to revert it (which is changing the code). Unless you're suggesting he shouldn't try to act like a competent developer.



  • It is, if you originally understood the code, and all the edit did was apparently introduce a bug. The comment on their commit should tell if they thought they were doing something important. And since you're a competent dev, you do read those.

    If someone fucks up your code, which you wrote and which was working, and their commit note doesn't indicate that there was a good reason for it, then you should feel perfectly justified in un-doing whatever they did first, and asking questions later. Questions which should've been answered by checking their commit note, BTW.



  • @Ascendant said:

    I haven't gone through all of them but I found one that someone changed my code for some reason and now it's misbehaving.

    Is this normal for a team of developers?

    It's normal, but the normal process would be to find the ticket documenting that change and file the bug as a regression against it. (If your workplace isn't a complete WTF, the ticket number/link should be in the source control commit message.)

    In most companies regressions are huge deals and handled differently than normal bugs.

    @Ascendant said:

    Like something inevitable arising from team cooperation?

    Well remember, it's was never your code to begin with. You have zero ownership here. So yeah, it happens and you just kind of have to cope with it.



  • @Ascendant said:

    That is, if this company had unit tests. Not single one of the companies I have worked ever had unit tests.

    You could just write them yourself.

    Part of our regression policy is that if any behavior regresses, even once, it's added to a test.

    (A lot of our codebase is ancient and doesn't have unit test coverage; a lot of that is written in such a way that it is, to be generous, nearly impossible to unit test. Thus we don't do the refactoring work needed to make things testable until the need arises. Probably a WTF, but there you go.)


  • SockDev

    Just think, you could have a :black_joker: implementing absurdly :wtf: and unnecessary "solutions" to problems you don't exactly have.



  • @blakeyrat
    @blakeyrat said:

    It's normal, but the normal process would be to find the ticket documenting that change and file the bug as a regression against it. (If your workplace isn't a complete WTF, the ticket number/link should be in the source control commit message.)

    What is this ticket you speak of?

    @blakeyrat said:

    You could just write them yourself.

    Yep. Working on it.

    @anotherusername
    @anotherusername said:

    The comment on their commit should tell

    They don't comment on their commit. Period.



  • For you? It's a mythical creature, like a gryphon or a cthulhu or a jodiefoster.



  • @blakeyrat

    If the tickets you speak of is a bug tracing system, they don't have a bug tracing system to begin with.
    So no tickets for me or you. :stuck_out_tongue:


Log in to reply
 

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