Timeline for Should I tell someone that their commit caused a regression?
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 21, 2015 at 7:59 | history | edited | Sardathrion - against SE abuse | CC BY-SA 3.0 | deleted 10 characters in body |
| Sep 28, 2011 at 16:42 | comment | added | Jeanne Pindar | I often use pdr's response. Sometimes the person had a good reason. And when they didn't, their answer might still be useful - for instance there might be something in the documentation or in another part of the code that is confusing or misleading. | |
| Sep 28, 2011 at 15:51 | history | made wiki | Post Made Community Wiki by Rachel | ||
| Sep 28, 2011 at 11:32 | comment | added | Mob | Send him a link to this question and the piece of code. | |
| Sep 28, 2011 at 7:36 | history | edited | Sardathrion - against SE abuse | CC BY-SA 3.0 | Edit from comment |
| Sep 27, 2011 at 22:33 | comment | added | KarlP | I want to know when I break things! A nice question from a colleague, asking why I did a change is always welcome, and we will probably both learn something from it... Even if it's just a typo... | |
| Sep 27, 2011 at 21:27 | comment | added | monksy | @Huge, you're implying you fully understand the purpose behind the code. | |
| Sep 27, 2011 at 16:18 | comment | added | zzzzBov | It's also good to let the other programmer know that you expect the same from them, and always check out your ego when you check in your code. | |
| Sep 27, 2011 at 16:11 | comment | added | Hugo | @Sardathrion Better yet, if you can think of a solution, fix it and push to them... -> the question says you've already fixed the bug, and with that knowledge, should you check who caused it and then tell them. | |
| Sep 27, 2011 at 14:29 | history | edited | Sardathrion - against SE abuse | CC BY-SA 3.0 | Comment lighted unclear statement in answer. |
| Sep 27, 2011 at 14:26 | comment | added | Sardathrion - against SE abuse | @monksy: agreed. I edited the main post to clarify thigns. | |
| Sep 27, 2011 at 14:09 | comment | added | monksy | Sounds like you may be reintroducing a new bug. Their fix may have corrected a previous issue that you don't know about. Why not go to them and ask why they wrote the code in the way that they did. It might reveal that there is an odd language/design/vm quirk that it was covering. Going and showing them your ego ["heres how i can do better" won't help them] | |
| Sep 27, 2011 at 13:08 | comment | added | lazyPower | +1 to pdr's response. I love how you passively assign ownership to a potential problem prior to making a potentially accusatory statement. | |
| Sep 27, 2011 at 12:21 | comment | added | Tim Reddy | +1, but I don't think the word "you" is confrontational. There needs to be a clear understanding of ownership. I have personally had people continually commit code that broke the build because they did not understand that they were the ones who caused it. I like @pdr's approach...this statement is non-confrontational yet it has the word "you" in it. | |
| Sep 27, 2011 at 11:11 | comment | added | maple_shaft♦ | +1, It is very similar advice to what my marriage counselor told my wife and I, when having a grievance against what your partner is doing, avoid the word YOU, it is too confrontational. | |
| Sep 27, 2011 at 10:51 | comment | added | c_maker | +1. "Criticise the code, not the person who wrote the code." | |
| Sep 27, 2011 at 9:39 | comment | added | pdr | +1. Personal favourite approach: "Before I go messing with this, was there a reason you did it this way?" | |
| Sep 27, 2011 at 9:21 | history | answered | Sardathrion - against SE abuse | CC BY-SA 3.0 |