How to handle when another dev screwed up a project?












3














I was working in a project and I finished all my tasks.



Another dev started to work in the new tasks.
Now I have downloaded the project and its with some build errors on it.



How can I handle with this?



I should think that the version control is enough to the manager or another one sees who screwed up the project?



Or I should talk to him, asking about the changes he did?



I'm new in this company, and he is too. But he seems to be less skilled than me.



EDIT



I talked to him about the build error and he told me he knows about it but he does not seems to care, because its building and running normally even been all classes red (Android studio things).



Anyway, I have told him that I will make a change about it and I fixed and committed.










share|improve this question









New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 14




    Relax. Talk to him first. Calm and constructive.
    – kiltek
    2 days ago








  • 5




    First you go in person to the other developer and talk to him. Leave out the manager.
    – kiltek
    2 days ago






  • 4




    Shit happens. Next time it could be you checking in some errors. At this point you should think about integration testing and continous integration, which can be used as a counter measurement against build errors in general.
    – kiltek
    2 days ago








  • 2




    @LMaker if everything is red, I would suggest that there are uncommitted changes or a missing reference or a missing DLL which you have to get elsewhere, not necessarily that there is fundamentally something wrong with the project.
    – user1666620
    2 days ago






  • 2




    Mistakes happen. Believe it or not, you will make mistakes that others will find abhorrent. Even brilliant people have off days. So don't get annoyed about people committing code with errors, and learn to accept that humans are imperfect and make mistakes.
    – Gregroy Currie
    2 days ago
















3














I was working in a project and I finished all my tasks.



Another dev started to work in the new tasks.
Now I have downloaded the project and its with some build errors on it.



How can I handle with this?



I should think that the version control is enough to the manager or another one sees who screwed up the project?



Or I should talk to him, asking about the changes he did?



I'm new in this company, and he is too. But he seems to be less skilled than me.



EDIT



I talked to him about the build error and he told me he knows about it but he does not seems to care, because its building and running normally even been all classes red (Android studio things).



Anyway, I have told him that I will make a change about it and I fixed and committed.










share|improve this question









New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 14




    Relax. Talk to him first. Calm and constructive.
    – kiltek
    2 days ago








  • 5




    First you go in person to the other developer and talk to him. Leave out the manager.
    – kiltek
    2 days ago






  • 4




    Shit happens. Next time it could be you checking in some errors. At this point you should think about integration testing and continous integration, which can be used as a counter measurement against build errors in general.
    – kiltek
    2 days ago








  • 2




    @LMaker if everything is red, I would suggest that there are uncommitted changes or a missing reference or a missing DLL which you have to get elsewhere, not necessarily that there is fundamentally something wrong with the project.
    – user1666620
    2 days ago






  • 2




    Mistakes happen. Believe it or not, you will make mistakes that others will find abhorrent. Even brilliant people have off days. So don't get annoyed about people committing code with errors, and learn to accept that humans are imperfect and make mistakes.
    – Gregroy Currie
    2 days ago














3












3








3







I was working in a project and I finished all my tasks.



Another dev started to work in the new tasks.
Now I have downloaded the project and its with some build errors on it.



How can I handle with this?



I should think that the version control is enough to the manager or another one sees who screwed up the project?



Or I should talk to him, asking about the changes he did?



I'm new in this company, and he is too. But he seems to be less skilled than me.



EDIT



I talked to him about the build error and he told me he knows about it but he does not seems to care, because its building and running normally even been all classes red (Android studio things).



Anyway, I have told him that I will make a change about it and I fixed and committed.










share|improve this question









New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











I was working in a project and I finished all my tasks.



Another dev started to work in the new tasks.
Now I have downloaded the project and its with some build errors on it.



How can I handle with this?



I should think that the version control is enough to the manager or another one sees who screwed up the project?



Or I should talk to him, asking about the changes he did?



I'm new in this company, and he is too. But he seems to be less skilled than me.



EDIT



I talked to him about the build error and he told me he knows about it but he does not seems to care, because its building and running normally even been all classes red (Android studio things).



Anyway, I have told him that I will make a change about it and I fixed and committed.







software-industry colleagues software-development developer team-building






share|improve this question









New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited yesterday







LMaker













New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 2 days ago









LMakerLMaker

4491213




4491213




New contributor




LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






LMaker is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 14




    Relax. Talk to him first. Calm and constructive.
    – kiltek
    2 days ago








  • 5




    First you go in person to the other developer and talk to him. Leave out the manager.
    – kiltek
    2 days ago






  • 4




    Shit happens. Next time it could be you checking in some errors. At this point you should think about integration testing and continous integration, which can be used as a counter measurement against build errors in general.
    – kiltek
    2 days ago








  • 2




    @LMaker if everything is red, I would suggest that there are uncommitted changes or a missing reference or a missing DLL which you have to get elsewhere, not necessarily that there is fundamentally something wrong with the project.
    – user1666620
    2 days ago






  • 2




    Mistakes happen. Believe it or not, you will make mistakes that others will find abhorrent. Even brilliant people have off days. So don't get annoyed about people committing code with errors, and learn to accept that humans are imperfect and make mistakes.
    – Gregroy Currie
    2 days ago














  • 14




    Relax. Talk to him first. Calm and constructive.
    – kiltek
    2 days ago








  • 5




    First you go in person to the other developer and talk to him. Leave out the manager.
    – kiltek
    2 days ago






  • 4




    Shit happens. Next time it could be you checking in some errors. At this point you should think about integration testing and continous integration, which can be used as a counter measurement against build errors in general.
    – kiltek
    2 days ago








  • 2




    @LMaker if everything is red, I would suggest that there are uncommitted changes or a missing reference or a missing DLL which you have to get elsewhere, not necessarily that there is fundamentally something wrong with the project.
    – user1666620
    2 days ago






  • 2




    Mistakes happen. Believe it or not, you will make mistakes that others will find abhorrent. Even brilliant people have off days. So don't get annoyed about people committing code with errors, and learn to accept that humans are imperfect and make mistakes.
    – Gregroy Currie
    2 days ago








14




14




Relax. Talk to him first. Calm and constructive.
– kiltek
2 days ago






Relax. Talk to him first. Calm and constructive.
– kiltek
2 days ago






5




5




First you go in person to the other developer and talk to him. Leave out the manager.
– kiltek
2 days ago




First you go in person to the other developer and talk to him. Leave out the manager.
– kiltek
2 days ago




4




4




Shit happens. Next time it could be you checking in some errors. At this point you should think about integration testing and continous integration, which can be used as a counter measurement against build errors in general.
– kiltek
2 days ago






Shit happens. Next time it could be you checking in some errors. At this point you should think about integration testing and continous integration, which can be used as a counter measurement against build errors in general.
– kiltek
2 days ago






2




2




@LMaker if everything is red, I would suggest that there are uncommitted changes or a missing reference or a missing DLL which you have to get elsewhere, not necessarily that there is fundamentally something wrong with the project.
– user1666620
2 days ago




@LMaker if everything is red, I would suggest that there are uncommitted changes or a missing reference or a missing DLL which you have to get elsewhere, not necessarily that there is fundamentally something wrong with the project.
– user1666620
2 days ago




2




2




Mistakes happen. Believe it or not, you will make mistakes that others will find abhorrent. Even brilliant people have off days. So don't get annoyed about people committing code with errors, and learn to accept that humans are imperfect and make mistakes.
– Gregroy Currie
2 days ago




Mistakes happen. Believe it or not, you will make mistakes that others will find abhorrent. Even brilliant people have off days. So don't get annoyed about people committing code with errors, and learn to accept that humans are imperfect and make mistakes.
– Gregroy Currie
2 days ago










6 Answers
6






active

oldest

votes


















10














You should definitely talk to him about it. Maybe he didn't fully commit all his code/changes, or maybe he committed on accident.



If he did commit everything & was fully aware of doing so, you should ask him about the errors & maybe even offer to help fixing them if he doesn't know how to do so himself.



You can always go straight to your manager if it turns out he just doesn't care about the quality of his code or if you feel like his incompetence hinders you from doing your job.



Calmly talking to him about it should be the first step, you're colleagues after all.






share|improve this answer










New contributor




lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.














  • 3




    One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
    – David Thornley
    2 days ago










  • Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
    – LMaker
    yesterday










  • Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
    – lucid
    yesterday










  • Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
    – Tombo
    12 hours ago





















6















I should think that the version control is enough to the manager or another one sees who screwed up the project?




Perhaps, but that should not be your main concern. You do not want to play the blame game; that will not improve working relations, and certainly won't help to fix the problem.




Or I should talk to him, asking about the changes he did?




Talk to him. Don't blame him. Point out why it's broken, and then ask "how can we fix this?" Emphasize that all you care about is bringing the project to a good end.




I'm new in this company, and he is too. But he seems to be less skilled than me.




So what? It's not a competition. There will be others who are more skilled than you.






share|improve this answer





















  • I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
    – LMaker
    yesterday





















3














Talk to him. Don't run to the manager whenever something doesn't build.



Are you sure your environment is set up correctly? Is there any chance you could be missing something? Double check before approaching your colleague. When you do approach him, I suggest framing the question as a request for help getting the project building.



Something along the lines of "I pulled the repo down but it doesn't build. I'm not sure if I set something up wrong, could you help me?"



This will give him the opportunity to see that his change broke the code. You are both new so it is valid to ask for his help setting up regardless! Give him an opportunity to fix it himself first, before escalating something that happens in every software development environment.



If you have version control, which I hope you have, you should be able to see what changes he made. I suggest you talk to your supervisor about setting up some sort of a code review system in the future.






share|improve this answer





















  • Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
    – LMaker
    yesterday



















0















How can I handle with this?




Implement a Pull Request (or whatever you call it) workflow that will allow another dev to review changes before they are added



Developers, even seasoned ones break the build. It sounds like you are not the tech lead. Step up and show the tech lead you'll take point on implementing the (much needed) process.



Go talk to him 1 on 1 about the changes. See if this is a configuration issue on your part. If it is, problem solved.



If not, look at how you can use a workflow to stop this from happening again.



After reviewing how to turn on reviews and auto-builds in your current system, approach the tech lead. Say something like




I've noticed that sometimes people check in changes that break the system, and if we turn on PR reviews, that should go down significantly. We can also build the system every time someone checks in, which should cut down on that too.




Hopefully the tech lead will be overjoyed someone wants to step up and do this. If they vehemently hate the idea, run for your life.






share|improve this answer























  • Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
    – 17 of 26
    2 days ago










  • It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
    – sevensevens
    yesterday



















0














Step 1: Talk to him. Mention that the build is broken, and the last commit on it was his commit, so ask him what happened (it's important to not say "you broke the build!" because a) that's accusatory and b) perhaps his change wasn't actually the change that broke the build, e.g. maybe it was a configuration change, or maybe you forgot about a change you yourself made, etc, in which case you come off looking very abrasive and accusatory).



Step 2: If he is receptive to your statement, work with him to fix it and if he doesn't understand what went wrong, explain it to him. Explaining it to him will teach him how not to make the same mistake again. That's called mentorship and is very important among colleagues, particularly more experienced ones (towards less experienced ones). You will be looked on highly by your superiors if you can productively engage in mentorship.



Step 2a: In the extremely unlikely case that he is not receptive to your statement, then it's time to fight: Double-check your work to make absolutely sure he broke the build, then go to your manager and show him that the build is broken and that the colleague did it. Then it's the manager's problem, not yours, and that's where your responsibility ends.



Step 3: Next time this particular colleague breaks the build, rinse and repeat. If it happens a number of times and you feel it is a pattern of irresponsibility, then you can go to your manager and say "Hey Bob, you know Joe has broken the build a number of times and I've tried talking to him about it, but it just seems he doesn't care, mind talking to him about it?" or something like that. Don't go in aggressive or accusatory; make the issue about breaking the build, not about the colleague. Your manager will decide what the best course of action is from there.






share|improve this answer





























    0














    This is exactly what build servers are for. They check out the source after each commit and see if it builds and send a mail to whoever broke the build so they can fix the problem.



    Some build servers can even serve out the artifacts built if needed.



    If you don't have one, get one. A good place to start is Jenkins which is very easy to get started with.



    In this particular case, the problem would probably have been fixed before he went home without any need for talking or finger pointing.






    share|improve this answer























    • Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
      – Brandin
      yesterday












    • @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
      – Thorbjørn Ravn Andersen
      yesterday











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "423"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    noCode: true, onDemand: false,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });






    LMaker is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f126083%2fhow-to-handle-when-another-dev-screwed-up-a-project%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown




















    StackExchange.ready(function () {
    $("#show-editor-button input, #show-editor-button button").click(function () {
    var showEditor = function() {
    $("#show-editor-button").hide();
    $("#post-form").removeClass("dno");
    StackExchange.editor.finallyInit();
    };

    var useFancy = $(this).data('confirm-use-fancy');
    if(useFancy == 'True') {
    var popupTitle = $(this).data('confirm-fancy-title');
    var popupBody = $(this).data('confirm-fancy-body');
    var popupAccept = $(this).data('confirm-fancy-accept-button');

    $(this).loadPopup({
    url: '/post/self-answer-popup',
    loaded: function(popup) {
    var pTitle = $(popup).find('h2');
    var pBody = $(popup).find('.popup-body');
    var pSubmit = $(popup).find('.popup-submit');

    pTitle.text(popupTitle);
    pBody.html(popupBody);
    pSubmit.val(popupAccept).click(showEditor);
    }
    })
    } else{
    var confirmText = $(this).data('confirm-text');
    if (confirmText ? confirm(confirmText) : true) {
    showEditor();
    }
    }
    });
    });






    6 Answers
    6






    active

    oldest

    votes








    6 Answers
    6






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    10














    You should definitely talk to him about it. Maybe he didn't fully commit all his code/changes, or maybe he committed on accident.



    If he did commit everything & was fully aware of doing so, you should ask him about the errors & maybe even offer to help fixing them if he doesn't know how to do so himself.



    You can always go straight to your manager if it turns out he just doesn't care about the quality of his code or if you feel like his incompetence hinders you from doing your job.



    Calmly talking to him about it should be the first step, you're colleagues after all.






    share|improve this answer










    New contributor




    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.














    • 3




      One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
      – David Thornley
      2 days ago










    • Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
      – LMaker
      yesterday










    • Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
      – lucid
      yesterday










    • Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
      – Tombo
      12 hours ago


















    10














    You should definitely talk to him about it. Maybe he didn't fully commit all his code/changes, or maybe he committed on accident.



    If he did commit everything & was fully aware of doing so, you should ask him about the errors & maybe even offer to help fixing them if he doesn't know how to do so himself.



    You can always go straight to your manager if it turns out he just doesn't care about the quality of his code or if you feel like his incompetence hinders you from doing your job.



    Calmly talking to him about it should be the first step, you're colleagues after all.






    share|improve this answer










    New contributor




    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.














    • 3




      One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
      – David Thornley
      2 days ago










    • Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
      – LMaker
      yesterday










    • Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
      – lucid
      yesterday










    • Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
      – Tombo
      12 hours ago
















    10












    10








    10






    You should definitely talk to him about it. Maybe he didn't fully commit all his code/changes, or maybe he committed on accident.



    If he did commit everything & was fully aware of doing so, you should ask him about the errors & maybe even offer to help fixing them if he doesn't know how to do so himself.



    You can always go straight to your manager if it turns out he just doesn't care about the quality of his code or if you feel like his incompetence hinders you from doing your job.



    Calmly talking to him about it should be the first step, you're colleagues after all.






    share|improve this answer










    New contributor




    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    You should definitely talk to him about it. Maybe he didn't fully commit all his code/changes, or maybe he committed on accident.



    If he did commit everything & was fully aware of doing so, you should ask him about the errors & maybe even offer to help fixing them if he doesn't know how to do so himself.



    You can always go straight to your manager if it turns out he just doesn't care about the quality of his code or if you feel like his incompetence hinders you from doing your job.



    Calmly talking to him about it should be the first step, you're colleagues after all.







    share|improve this answer










    New contributor




    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    share|improve this answer



    share|improve this answer








    edited 2 days ago





















    New contributor




    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.









    answered 2 days ago









    lucidlucid

    1097




    1097




    New contributor




    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.





    New contributor





    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.






    lucid is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.








    • 3




      One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
      – David Thornley
      2 days ago










    • Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
      – LMaker
      yesterday










    • Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
      – lucid
      yesterday










    • Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
      – Tombo
      12 hours ago
















    • 3




      One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
      – David Thornley
      2 days ago










    • Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
      – LMaker
      yesterday










    • Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
      – lucid
      yesterday










    • Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
      – Tombo
      12 hours ago










    3




    3




    One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
    – David Thornley
    2 days ago




    One of the best developers I ever worked with had a habit, for a few years, of changing things in two places in the repository and committing one.
    – David Thornley
    2 days ago












    Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
    – LMaker
    yesterday




    Yeah, true. But this things need to be in commit description, right? We dont have a crystal ball
    – LMaker
    yesterday












    Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
    – lucid
    yesterday




    Yes but like you said, he's less skilled than you are. He might be new to version control which could mean that this was a case of accidentally committing on the wrong branch, or simply forgetting that he should commit all his changes like @DavidThornley 's example.
    – lucid
    yesterday












    Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
    – Tombo
    12 hours ago






    Agree. Tell him he broke the build and let him fix it. Going straight to the manager won't make you look good to your colleagues in several aspects. It probably won't make you look good to your manager either.
    – Tombo
    12 hours ago















    6















    I should think that the version control is enough to the manager or another one sees who screwed up the project?




    Perhaps, but that should not be your main concern. You do not want to play the blame game; that will not improve working relations, and certainly won't help to fix the problem.




    Or I should talk to him, asking about the changes he did?




    Talk to him. Don't blame him. Point out why it's broken, and then ask "how can we fix this?" Emphasize that all you care about is bringing the project to a good end.




    I'm new in this company, and he is too. But he seems to be less skilled than me.




    So what? It's not a competition. There will be others who are more skilled than you.






    share|improve this answer





















    • I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
      – LMaker
      yesterday


















    6















    I should think that the version control is enough to the manager or another one sees who screwed up the project?




    Perhaps, but that should not be your main concern. You do not want to play the blame game; that will not improve working relations, and certainly won't help to fix the problem.




    Or I should talk to him, asking about the changes he did?




    Talk to him. Don't blame him. Point out why it's broken, and then ask "how can we fix this?" Emphasize that all you care about is bringing the project to a good end.




    I'm new in this company, and he is too. But he seems to be less skilled than me.




    So what? It's not a competition. There will be others who are more skilled than you.






    share|improve this answer





















    • I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
      – LMaker
      yesterday
















    6












    6








    6







    I should think that the version control is enough to the manager or another one sees who screwed up the project?




    Perhaps, but that should not be your main concern. You do not want to play the blame game; that will not improve working relations, and certainly won't help to fix the problem.




    Or I should talk to him, asking about the changes he did?




    Talk to him. Don't blame him. Point out why it's broken, and then ask "how can we fix this?" Emphasize that all you care about is bringing the project to a good end.




    I'm new in this company, and he is too. But he seems to be less skilled than me.




    So what? It's not a competition. There will be others who are more skilled than you.






    share|improve this answer













    I should think that the version control is enough to the manager or another one sees who screwed up the project?




    Perhaps, but that should not be your main concern. You do not want to play the blame game; that will not improve working relations, and certainly won't help to fix the problem.




    Or I should talk to him, asking about the changes he did?




    Talk to him. Don't blame him. Point out why it's broken, and then ask "how can we fix this?" Emphasize that all you care about is bringing the project to a good end.




    I'm new in this company, and he is too. But he seems to be less skilled than me.




    So what? It's not a competition. There will be others who are more skilled than you.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 2 days ago









    AbigailAbigail

    1,6771511




    1,6771511












    • I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
      – LMaker
      yesterday




















    • I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
      – LMaker
      yesterday


















    I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
    – LMaker
    yesterday






    I worked for about 3 years alone, its been difficult to me to work with a team. Thanks for your help
    – LMaker
    yesterday













    3














    Talk to him. Don't run to the manager whenever something doesn't build.



    Are you sure your environment is set up correctly? Is there any chance you could be missing something? Double check before approaching your colleague. When you do approach him, I suggest framing the question as a request for help getting the project building.



    Something along the lines of "I pulled the repo down but it doesn't build. I'm not sure if I set something up wrong, could you help me?"



    This will give him the opportunity to see that his change broke the code. You are both new so it is valid to ask for his help setting up regardless! Give him an opportunity to fix it himself first, before escalating something that happens in every software development environment.



    If you have version control, which I hope you have, you should be able to see what changes he made. I suggest you talk to your supervisor about setting up some sort of a code review system in the future.






    share|improve this answer





















    • Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
      – LMaker
      yesterday
















    3














    Talk to him. Don't run to the manager whenever something doesn't build.



    Are you sure your environment is set up correctly? Is there any chance you could be missing something? Double check before approaching your colleague. When you do approach him, I suggest framing the question as a request for help getting the project building.



    Something along the lines of "I pulled the repo down but it doesn't build. I'm not sure if I set something up wrong, could you help me?"



    This will give him the opportunity to see that his change broke the code. You are both new so it is valid to ask for his help setting up regardless! Give him an opportunity to fix it himself first, before escalating something that happens in every software development environment.



    If you have version control, which I hope you have, you should be able to see what changes he made. I suggest you talk to your supervisor about setting up some sort of a code review system in the future.






    share|improve this answer





















    • Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
      – LMaker
      yesterday














    3












    3








    3






    Talk to him. Don't run to the manager whenever something doesn't build.



    Are you sure your environment is set up correctly? Is there any chance you could be missing something? Double check before approaching your colleague. When you do approach him, I suggest framing the question as a request for help getting the project building.



    Something along the lines of "I pulled the repo down but it doesn't build. I'm not sure if I set something up wrong, could you help me?"



    This will give him the opportunity to see that his change broke the code. You are both new so it is valid to ask for his help setting up regardless! Give him an opportunity to fix it himself first, before escalating something that happens in every software development environment.



    If you have version control, which I hope you have, you should be able to see what changes he made. I suggest you talk to your supervisor about setting up some sort of a code review system in the future.






    share|improve this answer












    Talk to him. Don't run to the manager whenever something doesn't build.



    Are you sure your environment is set up correctly? Is there any chance you could be missing something? Double check before approaching your colleague. When you do approach him, I suggest framing the question as a request for help getting the project building.



    Something along the lines of "I pulled the repo down but it doesn't build. I'm not sure if I set something up wrong, could you help me?"



    This will give him the opportunity to see that his change broke the code. You are both new so it is valid to ask for his help setting up regardless! Give him an opportunity to fix it himself first, before escalating something that happens in every software development environment.



    If you have version control, which I hope you have, you should be able to see what changes he made. I suggest you talk to your supervisor about setting up some sort of a code review system in the future.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered 2 days ago









    CatsunamiCatsunami

    21718




    21718












    • Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
      – LMaker
      yesterday


















    • Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
      – LMaker
      yesterday
















    Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
    – LMaker
    yesterday




    Yeah, I have made a search before "blame" him. I knew exacly where is the error and why is happening. What annoying me its a develop commit thing that are broke
    – LMaker
    yesterday











    0















    How can I handle with this?




    Implement a Pull Request (or whatever you call it) workflow that will allow another dev to review changes before they are added



    Developers, even seasoned ones break the build. It sounds like you are not the tech lead. Step up and show the tech lead you'll take point on implementing the (much needed) process.



    Go talk to him 1 on 1 about the changes. See if this is a configuration issue on your part. If it is, problem solved.



    If not, look at how you can use a workflow to stop this from happening again.



    After reviewing how to turn on reviews and auto-builds in your current system, approach the tech lead. Say something like




    I've noticed that sometimes people check in changes that break the system, and if we turn on PR reviews, that should go down significantly. We can also build the system every time someone checks in, which should cut down on that too.




    Hopefully the tech lead will be overjoyed someone wants to step up and do this. If they vehemently hate the idea, run for your life.






    share|improve this answer























    • Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
      – 17 of 26
      2 days ago










    • It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
      – sevensevens
      yesterday
















    0















    How can I handle with this?




    Implement a Pull Request (or whatever you call it) workflow that will allow another dev to review changes before they are added



    Developers, even seasoned ones break the build. It sounds like you are not the tech lead. Step up and show the tech lead you'll take point on implementing the (much needed) process.



    Go talk to him 1 on 1 about the changes. See if this is a configuration issue on your part. If it is, problem solved.



    If not, look at how you can use a workflow to stop this from happening again.



    After reviewing how to turn on reviews and auto-builds in your current system, approach the tech lead. Say something like




    I've noticed that sometimes people check in changes that break the system, and if we turn on PR reviews, that should go down significantly. We can also build the system every time someone checks in, which should cut down on that too.




    Hopefully the tech lead will be overjoyed someone wants to step up and do this. If they vehemently hate the idea, run for your life.






    share|improve this answer























    • Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
      – 17 of 26
      2 days ago










    • It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
      – sevensevens
      yesterday














    0












    0








    0







    How can I handle with this?




    Implement a Pull Request (or whatever you call it) workflow that will allow another dev to review changes before they are added



    Developers, even seasoned ones break the build. It sounds like you are not the tech lead. Step up and show the tech lead you'll take point on implementing the (much needed) process.



    Go talk to him 1 on 1 about the changes. See if this is a configuration issue on your part. If it is, problem solved.



    If not, look at how you can use a workflow to stop this from happening again.



    After reviewing how to turn on reviews and auto-builds in your current system, approach the tech lead. Say something like




    I've noticed that sometimes people check in changes that break the system, and if we turn on PR reviews, that should go down significantly. We can also build the system every time someone checks in, which should cut down on that too.




    Hopefully the tech lead will be overjoyed someone wants to step up and do this. If they vehemently hate the idea, run for your life.






    share|improve this answer















    How can I handle with this?




    Implement a Pull Request (or whatever you call it) workflow that will allow another dev to review changes before they are added



    Developers, even seasoned ones break the build. It sounds like you are not the tech lead. Step up and show the tech lead you'll take point on implementing the (much needed) process.



    Go talk to him 1 on 1 about the changes. See if this is a configuration issue on your part. If it is, problem solved.



    If not, look at how you can use a workflow to stop this from happening again.



    After reviewing how to turn on reviews and auto-builds in your current system, approach the tech lead. Say something like




    I've noticed that sometimes people check in changes that break the system, and if we turn on PR reviews, that should go down significantly. We can also build the system every time someone checks in, which should cut down on that too.




    Hopefully the tech lead will be overjoyed someone wants to step up and do this. If they vehemently hate the idea, run for your life.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited 2 days ago

























    answered 2 days ago









    sevensevenssevensevens

    10.3k32339




    10.3k32339












    • Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
      – 17 of 26
      2 days ago










    • It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
      – sevensevens
      yesterday


















    • Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
      – 17 of 26
      2 days ago










    • It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
      – sevensevens
      yesterday
















    Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
    – 17 of 26
    2 days ago




    Code reviews are not needed for build breaking changes. Automated builds with email notifications are the solution to that issue.
    – 17 of 26
    2 days ago












    It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
    – sevensevens
    yesterday




    It sounds like they don't have a good process in place anyway, and it's likely easier to turn on PR reviews than set up a continuous integration system
    – sevensevens
    yesterday











    0














    Step 1: Talk to him. Mention that the build is broken, and the last commit on it was his commit, so ask him what happened (it's important to not say "you broke the build!" because a) that's accusatory and b) perhaps his change wasn't actually the change that broke the build, e.g. maybe it was a configuration change, or maybe you forgot about a change you yourself made, etc, in which case you come off looking very abrasive and accusatory).



    Step 2: If he is receptive to your statement, work with him to fix it and if he doesn't understand what went wrong, explain it to him. Explaining it to him will teach him how not to make the same mistake again. That's called mentorship and is very important among colleagues, particularly more experienced ones (towards less experienced ones). You will be looked on highly by your superiors if you can productively engage in mentorship.



    Step 2a: In the extremely unlikely case that he is not receptive to your statement, then it's time to fight: Double-check your work to make absolutely sure he broke the build, then go to your manager and show him that the build is broken and that the colleague did it. Then it's the manager's problem, not yours, and that's where your responsibility ends.



    Step 3: Next time this particular colleague breaks the build, rinse and repeat. If it happens a number of times and you feel it is a pattern of irresponsibility, then you can go to your manager and say "Hey Bob, you know Joe has broken the build a number of times and I've tried talking to him about it, but it just seems he doesn't care, mind talking to him about it?" or something like that. Don't go in aggressive or accusatory; make the issue about breaking the build, not about the colleague. Your manager will decide what the best course of action is from there.






    share|improve this answer


























      0














      Step 1: Talk to him. Mention that the build is broken, and the last commit on it was his commit, so ask him what happened (it's important to not say "you broke the build!" because a) that's accusatory and b) perhaps his change wasn't actually the change that broke the build, e.g. maybe it was a configuration change, or maybe you forgot about a change you yourself made, etc, in which case you come off looking very abrasive and accusatory).



      Step 2: If he is receptive to your statement, work with him to fix it and if he doesn't understand what went wrong, explain it to him. Explaining it to him will teach him how not to make the same mistake again. That's called mentorship and is very important among colleagues, particularly more experienced ones (towards less experienced ones). You will be looked on highly by your superiors if you can productively engage in mentorship.



      Step 2a: In the extremely unlikely case that he is not receptive to your statement, then it's time to fight: Double-check your work to make absolutely sure he broke the build, then go to your manager and show him that the build is broken and that the colleague did it. Then it's the manager's problem, not yours, and that's where your responsibility ends.



      Step 3: Next time this particular colleague breaks the build, rinse and repeat. If it happens a number of times and you feel it is a pattern of irresponsibility, then you can go to your manager and say "Hey Bob, you know Joe has broken the build a number of times and I've tried talking to him about it, but it just seems he doesn't care, mind talking to him about it?" or something like that. Don't go in aggressive or accusatory; make the issue about breaking the build, not about the colleague. Your manager will decide what the best course of action is from there.






      share|improve this answer
























        0












        0








        0






        Step 1: Talk to him. Mention that the build is broken, and the last commit on it was his commit, so ask him what happened (it's important to not say "you broke the build!" because a) that's accusatory and b) perhaps his change wasn't actually the change that broke the build, e.g. maybe it was a configuration change, or maybe you forgot about a change you yourself made, etc, in which case you come off looking very abrasive and accusatory).



        Step 2: If he is receptive to your statement, work with him to fix it and if he doesn't understand what went wrong, explain it to him. Explaining it to him will teach him how not to make the same mistake again. That's called mentorship and is very important among colleagues, particularly more experienced ones (towards less experienced ones). You will be looked on highly by your superiors if you can productively engage in mentorship.



        Step 2a: In the extremely unlikely case that he is not receptive to your statement, then it's time to fight: Double-check your work to make absolutely sure he broke the build, then go to your manager and show him that the build is broken and that the colleague did it. Then it's the manager's problem, not yours, and that's where your responsibility ends.



        Step 3: Next time this particular colleague breaks the build, rinse and repeat. If it happens a number of times and you feel it is a pattern of irresponsibility, then you can go to your manager and say "Hey Bob, you know Joe has broken the build a number of times and I've tried talking to him about it, but it just seems he doesn't care, mind talking to him about it?" or something like that. Don't go in aggressive or accusatory; make the issue about breaking the build, not about the colleague. Your manager will decide what the best course of action is from there.






        share|improve this answer












        Step 1: Talk to him. Mention that the build is broken, and the last commit on it was his commit, so ask him what happened (it's important to not say "you broke the build!" because a) that's accusatory and b) perhaps his change wasn't actually the change that broke the build, e.g. maybe it was a configuration change, or maybe you forgot about a change you yourself made, etc, in which case you come off looking very abrasive and accusatory).



        Step 2: If he is receptive to your statement, work with him to fix it and if he doesn't understand what went wrong, explain it to him. Explaining it to him will teach him how not to make the same mistake again. That's called mentorship and is very important among colleagues, particularly more experienced ones (towards less experienced ones). You will be looked on highly by your superiors if you can productively engage in mentorship.



        Step 2a: In the extremely unlikely case that he is not receptive to your statement, then it's time to fight: Double-check your work to make absolutely sure he broke the build, then go to your manager and show him that the build is broken and that the colleague did it. Then it's the manager's problem, not yours, and that's where your responsibility ends.



        Step 3: Next time this particular colleague breaks the build, rinse and repeat. If it happens a number of times and you feel it is a pattern of irresponsibility, then you can go to your manager and say "Hey Bob, you know Joe has broken the build a number of times and I've tried talking to him about it, but it just seems he doesn't care, mind talking to him about it?" or something like that. Don't go in aggressive or accusatory; make the issue about breaking the build, not about the colleague. Your manager will decide what the best course of action is from there.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 2 days ago









        Ertai87Ertai87

        7,0411720




        7,0411720























            0














            This is exactly what build servers are for. They check out the source after each commit and see if it builds and send a mail to whoever broke the build so they can fix the problem.



            Some build servers can even serve out the artifacts built if needed.



            If you don't have one, get one. A good place to start is Jenkins which is very easy to get started with.



            In this particular case, the problem would probably have been fixed before he went home without any need for talking or finger pointing.






            share|improve this answer























            • Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
              – Brandin
              yesterday












            • @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
              – Thorbjørn Ravn Andersen
              yesterday
















            0














            This is exactly what build servers are for. They check out the source after each commit and see if it builds and send a mail to whoever broke the build so they can fix the problem.



            Some build servers can even serve out the artifacts built if needed.



            If you don't have one, get one. A good place to start is Jenkins which is very easy to get started with.



            In this particular case, the problem would probably have been fixed before he went home without any need for talking or finger pointing.






            share|improve this answer























            • Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
              – Brandin
              yesterday












            • @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
              – Thorbjørn Ravn Andersen
              yesterday














            0












            0








            0






            This is exactly what build servers are for. They check out the source after each commit and see if it builds and send a mail to whoever broke the build so they can fix the problem.



            Some build servers can even serve out the artifacts built if needed.



            If you don't have one, get one. A good place to start is Jenkins which is very easy to get started with.



            In this particular case, the problem would probably have been fixed before he went home without any need for talking or finger pointing.






            share|improve this answer














            This is exactly what build servers are for. They check out the source after each commit and see if it builds and send a mail to whoever broke the build so they can fix the problem.



            Some build servers can even serve out the artifacts built if needed.



            If you don't have one, get one. A good place to start is Jenkins which is very easy to get started with.



            In this particular case, the problem would probably have been fixed before he went home without any need for talking or finger pointing.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited 2 days ago

























            answered 2 days ago









            Thorbjørn Ravn AndersenThorbjørn Ravn Andersen

            3,46811222




            3,46811222












            • Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
              – Brandin
              yesterday












            • @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
              – Thorbjørn Ravn Andersen
              yesterday


















            • Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
              – Brandin
              yesterday












            • @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
              – Thorbjørn Ravn Andersen
              yesterday
















            Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
            – Brandin
            yesterday






            Setting up a build server is a good technical suggestion, but without discussion, team buy in, and discipline, it will not magically cause people to go fix their code. If they are not familiar with the practice, they will consider any e-mails sent to them by the build server as spam and disregard them.
            – Brandin
            yesterday














            @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
            – Thorbjørn Ravn Andersen
            yesterday




            @Brandin Naturally this need political support as part of being put in place. So, get the boss to say "This is how we do it from here on" first.
            – Thorbjørn Ravn Andersen
            yesterday










            LMaker is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            LMaker is a new contributor. Be nice, and check out our Code of Conduct.













            LMaker is a new contributor. Be nice, and check out our Code of Conduct.












            LMaker is a new contributor. Be nice, and check out our Code of Conduct.
















            Thanks for contributing an answer to The Workplace Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f126083%2fhow-to-handle-when-another-dev-screwed-up-a-project%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown











            Popular posts from this blog

            1300-talet

            1300-talet

            Has there ever been an instance of an active nuclear power plant within or near a war zone?