How do I tell my manager that he's wrong?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
Recently during code review, my direct supervisor wrote a comment requesting a change on some code I submitted. Normally, that is not a problem (and I understand that is the very point of code reviews), but it turns out that his concern is based on incorrect information.
More specifically, he raised concerns over a certain language feature, and explained why that could be an issue - except that, in fact, the language does not work as he explained. This is supported by language documentation.
My question, then, is how do I explain to him (if at all) that his idea of how the language works is incorrect? Being at least one or two decades junior to him, I don't want to come off as arrogant. I would normally have no problem with sucking it up and making the change (it's as easy as deleting a comma) - but I also feel like that goes against the spirit of a code review.
Not a duplicate of How do I tell a coworker he's wrong?, since this is specifically about telling your seniors they are wrong.
communication
add a comment |
Recently during code review, my direct supervisor wrote a comment requesting a change on some code I submitted. Normally, that is not a problem (and I understand that is the very point of code reviews), but it turns out that his concern is based on incorrect information.
More specifically, he raised concerns over a certain language feature, and explained why that could be an issue - except that, in fact, the language does not work as he explained. This is supported by language documentation.
My question, then, is how do I explain to him (if at all) that his idea of how the language works is incorrect? Being at least one or two decades junior to him, I don't want to come off as arrogant. I would normally have no problem with sucking it up and making the change (it's as easy as deleting a comma) - but I also feel like that goes against the spirit of a code review.
Not a duplicate of How do I tell a coworker he's wrong?, since this is specifically about telling your seniors they are wrong.
communication
If you have a process for rejecting comments made during code review, just follow that.
– Laconic Droid
3 hours ago
@LaconicDroid We do not - as I understand it, code reviews go through a process but are somewhat informal at the office.
– osuka_
3 hours ago
add a comment |
Recently during code review, my direct supervisor wrote a comment requesting a change on some code I submitted. Normally, that is not a problem (and I understand that is the very point of code reviews), but it turns out that his concern is based on incorrect information.
More specifically, he raised concerns over a certain language feature, and explained why that could be an issue - except that, in fact, the language does not work as he explained. This is supported by language documentation.
My question, then, is how do I explain to him (if at all) that his idea of how the language works is incorrect? Being at least one or two decades junior to him, I don't want to come off as arrogant. I would normally have no problem with sucking it up and making the change (it's as easy as deleting a comma) - but I also feel like that goes against the spirit of a code review.
Not a duplicate of How do I tell a coworker he's wrong?, since this is specifically about telling your seniors they are wrong.
communication
Recently during code review, my direct supervisor wrote a comment requesting a change on some code I submitted. Normally, that is not a problem (and I understand that is the very point of code reviews), but it turns out that his concern is based on incorrect information.
More specifically, he raised concerns over a certain language feature, and explained why that could be an issue - except that, in fact, the language does not work as he explained. This is supported by language documentation.
My question, then, is how do I explain to him (if at all) that his idea of how the language works is incorrect? Being at least one or two decades junior to him, I don't want to come off as arrogant. I would normally have no problem with sucking it up and making the change (it's as easy as deleting a comma) - but I also feel like that goes against the spirit of a code review.
Not a duplicate of How do I tell a coworker he's wrong?, since this is specifically about telling your seniors they are wrong.
communication
communication
asked 3 hours ago
osuka_osuka_
5762411
5762411
If you have a process for rejecting comments made during code review, just follow that.
– Laconic Droid
3 hours ago
@LaconicDroid We do not - as I understand it, code reviews go through a process but are somewhat informal at the office.
– osuka_
3 hours ago
add a comment |
If you have a process for rejecting comments made during code review, just follow that.
– Laconic Droid
3 hours ago
@LaconicDroid We do not - as I understand it, code reviews go through a process but are somewhat informal at the office.
– osuka_
3 hours ago
If you have a process for rejecting comments made during code review, just follow that.
– Laconic Droid
3 hours ago
If you have a process for rejecting comments made during code review, just follow that.
– Laconic Droid
3 hours ago
@LaconicDroid We do not - as I understand it, code reviews go through a process but are somewhat informal at the office.
– osuka_
3 hours ago
@LaconicDroid We do not - as I understand it, code reviews go through a process but are somewhat informal at the office.
– osuka_
3 hours ago
add a comment |
3 Answers
3
active
oldest
votes
Be humble.
I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?
Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now taught your manager something in a non-confrontational way.
As an important aside, while you say this is different from our other question, it isn't really: you should be humble with your peers and with your juniors as well.
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
add a comment |
You can simply "ask for more clarity" and show willingness to change but subtly indicating that his concerns are not valid. An email to this effect may help:
You have requested following changes in the code because of so and so reasons. However, my understanding of this language is that this problem will not occur because it instead works this way. I suppose I am missing something but could you please clarify or confirm that my understanding is wrong? If you have few minutes, I can show a demo of this and may be you can point out more specifically what your concerns are.
This way you will at least have a documented proof that you tried to correct him back. If he still insist, you can do whatever he requested and just hope it wont be a problem in the long run.
add a comment |
In reading some of these workplace problems, it brings back old memories where I worked in a SLC, UTAH company, in a manufacturing environment as a programmer. In looking back on it, I burned a bridge which I should of NEVER let happen. It was a bridge that I had to cross many times before. My supervisor was known as the company drunk, but he knew his stuff. He had many problems, but that side of him, was none of my business in the first place.
But NEVER tell your immdiate supervisor that he/she is wrong. NEVER! And never in front of his peers or any of his/her supvervisors. That a strike or nail in your coffin.
But before you runoff at the mouth on him/she being wrong, first take some extra time plus some extra effort(s) on your part and research it all the problems out where he/she 'might' be incorrect in full and provide alternate answers or solutions to solve the problem(s). Notice the careful wordings in the above statement??? Use words like "'might' be incorrect" NEVER 'Wrong'. Have supporting documents and answers to support your theories. After you've done your extra homework, set up a time to meet with your supervisor in a meeting form so that it fits his/hers' schedule, not yours! And go into that meeting with an attitude showing that you are workable, friendly, and happy and SHOW IT! One thing I learned with this past supervisor, he could read my attitude and body language and facial features and voice - know everything about me. And with all this effort and a meeting, you could either loose or win.
As my father would say, your supervisor holds the future of your job within the company you work in. In a sense, you are at his/hers' mercy. Oh, one thing I forgot, DON'T raise for voice for anything! Again, as I look back on this job, I could see places where the bridge was starting to burn. My job as a manufacturing programmer, is just like yours. All my work was reviewed by my supervisor period! And I recieved good marks and bad marks on my work and sometimes I was told to redo my programming work, and it was humbling!
So my advice to you as a from manufacturing environment programmer, It's up to you if you want the job, if you like the job and want to stay - it's up to you and your attitude plays a big part in your job. Remember, you are to make your supervisor look GOOD to everyone!! Enough of my preaching... Now enjoy your job.
New contributor
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f135686%2fhow-do-i-tell-my-manager-that-hes-wrong%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();
}
}
});
});
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Be humble.
I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?
Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now taught your manager something in a non-confrontational way.
As an important aside, while you say this is different from our other question, it isn't really: you should be humble with your peers and with your juniors as well.
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
add a comment |
Be humble.
I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?
Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now taught your manager something in a non-confrontational way.
As an important aside, while you say this is different from our other question, it isn't really: you should be humble with your peers and with your juniors as well.
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
add a comment |
Be humble.
I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?
Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now taught your manager something in a non-confrontational way.
As an important aside, while you say this is different from our other question, it isn't really: you should be humble with your peers and with your juniors as well.
Be humble.
I'm a bit confused here. My understanding was that feature X has property Y. Is there something I'm missing here which means this doesn't work in this case?
Much better to start from the assumption that you are the one that is wrong, rather than the other way round. If you're wrong, you'll learn something; if you were in fact right, you've now taught your manager something in a non-confrontational way.
As an important aside, while you say this is different from our other question, it isn't really: you should be humble with your peers and with your juniors as well.
answered 1 hour ago
Philip KendallPhilip Kendall
53.7k37132163
53.7k37132163
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
add a comment |
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
+1 - This is good advice, but the issue here is that this is very clear cut - when reading the applicable documentation page, it is trivial to conclude that the requested change has no effect. This question really was about how to be humble when correcting a coworker that is tangibly wrong, while not being arrogant. Everyone makes mistakes regardless of seniority, and my concern really is to not come across as "that guy".
– osuka_
1 hour ago
add a comment |
You can simply "ask for more clarity" and show willingness to change but subtly indicating that his concerns are not valid. An email to this effect may help:
You have requested following changes in the code because of so and so reasons. However, my understanding of this language is that this problem will not occur because it instead works this way. I suppose I am missing something but could you please clarify or confirm that my understanding is wrong? If you have few minutes, I can show a demo of this and may be you can point out more specifically what your concerns are.
This way you will at least have a documented proof that you tried to correct him back. If he still insist, you can do whatever he requested and just hope it wont be a problem in the long run.
add a comment |
You can simply "ask for more clarity" and show willingness to change but subtly indicating that his concerns are not valid. An email to this effect may help:
You have requested following changes in the code because of so and so reasons. However, my understanding of this language is that this problem will not occur because it instead works this way. I suppose I am missing something but could you please clarify or confirm that my understanding is wrong? If you have few minutes, I can show a demo of this and may be you can point out more specifically what your concerns are.
This way you will at least have a documented proof that you tried to correct him back. If he still insist, you can do whatever he requested and just hope it wont be a problem in the long run.
add a comment |
You can simply "ask for more clarity" and show willingness to change but subtly indicating that his concerns are not valid. An email to this effect may help:
You have requested following changes in the code because of so and so reasons. However, my understanding of this language is that this problem will not occur because it instead works this way. I suppose I am missing something but could you please clarify or confirm that my understanding is wrong? If you have few minutes, I can show a demo of this and may be you can point out more specifically what your concerns are.
This way you will at least have a documented proof that you tried to correct him back. If he still insist, you can do whatever he requested and just hope it wont be a problem in the long run.
You can simply "ask for more clarity" and show willingness to change but subtly indicating that his concerns are not valid. An email to this effect may help:
You have requested following changes in the code because of so and so reasons. However, my understanding of this language is that this problem will not occur because it instead works this way. I suppose I am missing something but could you please clarify or confirm that my understanding is wrong? If you have few minutes, I can show a demo of this and may be you can point out more specifically what your concerns are.
This way you will at least have a documented proof that you tried to correct him back. If he still insist, you can do whatever he requested and just hope it wont be a problem in the long run.
answered 1 hour ago
PagMaxPagMax
10.1k52648
10.1k52648
add a comment |
add a comment |
In reading some of these workplace problems, it brings back old memories where I worked in a SLC, UTAH company, in a manufacturing environment as a programmer. In looking back on it, I burned a bridge which I should of NEVER let happen. It was a bridge that I had to cross many times before. My supervisor was known as the company drunk, but he knew his stuff. He had many problems, but that side of him, was none of my business in the first place.
But NEVER tell your immdiate supervisor that he/she is wrong. NEVER! And never in front of his peers or any of his/her supvervisors. That a strike or nail in your coffin.
But before you runoff at the mouth on him/she being wrong, first take some extra time plus some extra effort(s) on your part and research it all the problems out where he/she 'might' be incorrect in full and provide alternate answers or solutions to solve the problem(s). Notice the careful wordings in the above statement??? Use words like "'might' be incorrect" NEVER 'Wrong'. Have supporting documents and answers to support your theories. After you've done your extra homework, set up a time to meet with your supervisor in a meeting form so that it fits his/hers' schedule, not yours! And go into that meeting with an attitude showing that you are workable, friendly, and happy and SHOW IT! One thing I learned with this past supervisor, he could read my attitude and body language and facial features and voice - know everything about me. And with all this effort and a meeting, you could either loose or win.
As my father would say, your supervisor holds the future of your job within the company you work in. In a sense, you are at his/hers' mercy. Oh, one thing I forgot, DON'T raise for voice for anything! Again, as I look back on this job, I could see places where the bridge was starting to burn. My job as a manufacturing programmer, is just like yours. All my work was reviewed by my supervisor period! And I recieved good marks and bad marks on my work and sometimes I was told to redo my programming work, and it was humbling!
So my advice to you as a from manufacturing environment programmer, It's up to you if you want the job, if you like the job and want to stay - it's up to you and your attitude plays a big part in your job. Remember, you are to make your supervisor look GOOD to everyone!! Enough of my preaching... Now enjoy your job.
New contributor
add a comment |
In reading some of these workplace problems, it brings back old memories where I worked in a SLC, UTAH company, in a manufacturing environment as a programmer. In looking back on it, I burned a bridge which I should of NEVER let happen. It was a bridge that I had to cross many times before. My supervisor was known as the company drunk, but he knew his stuff. He had many problems, but that side of him, was none of my business in the first place.
But NEVER tell your immdiate supervisor that he/she is wrong. NEVER! And never in front of his peers or any of his/her supvervisors. That a strike or nail in your coffin.
But before you runoff at the mouth on him/she being wrong, first take some extra time plus some extra effort(s) on your part and research it all the problems out where he/she 'might' be incorrect in full and provide alternate answers or solutions to solve the problem(s). Notice the careful wordings in the above statement??? Use words like "'might' be incorrect" NEVER 'Wrong'. Have supporting documents and answers to support your theories. After you've done your extra homework, set up a time to meet with your supervisor in a meeting form so that it fits his/hers' schedule, not yours! And go into that meeting with an attitude showing that you are workable, friendly, and happy and SHOW IT! One thing I learned with this past supervisor, he could read my attitude and body language and facial features and voice - know everything about me. And with all this effort and a meeting, you could either loose or win.
As my father would say, your supervisor holds the future of your job within the company you work in. In a sense, you are at his/hers' mercy. Oh, one thing I forgot, DON'T raise for voice for anything! Again, as I look back on this job, I could see places where the bridge was starting to burn. My job as a manufacturing programmer, is just like yours. All my work was reviewed by my supervisor period! And I recieved good marks and bad marks on my work and sometimes I was told to redo my programming work, and it was humbling!
So my advice to you as a from manufacturing environment programmer, It's up to you if you want the job, if you like the job and want to stay - it's up to you and your attitude plays a big part in your job. Remember, you are to make your supervisor look GOOD to everyone!! Enough of my preaching... Now enjoy your job.
New contributor
add a comment |
In reading some of these workplace problems, it brings back old memories where I worked in a SLC, UTAH company, in a manufacturing environment as a programmer. In looking back on it, I burned a bridge which I should of NEVER let happen. It was a bridge that I had to cross many times before. My supervisor was known as the company drunk, but he knew his stuff. He had many problems, but that side of him, was none of my business in the first place.
But NEVER tell your immdiate supervisor that he/she is wrong. NEVER! And never in front of his peers or any of his/her supvervisors. That a strike or nail in your coffin.
But before you runoff at the mouth on him/she being wrong, first take some extra time plus some extra effort(s) on your part and research it all the problems out where he/she 'might' be incorrect in full and provide alternate answers or solutions to solve the problem(s). Notice the careful wordings in the above statement??? Use words like "'might' be incorrect" NEVER 'Wrong'. Have supporting documents and answers to support your theories. After you've done your extra homework, set up a time to meet with your supervisor in a meeting form so that it fits his/hers' schedule, not yours! And go into that meeting with an attitude showing that you are workable, friendly, and happy and SHOW IT! One thing I learned with this past supervisor, he could read my attitude and body language and facial features and voice - know everything about me. And with all this effort and a meeting, you could either loose or win.
As my father would say, your supervisor holds the future of your job within the company you work in. In a sense, you are at his/hers' mercy. Oh, one thing I forgot, DON'T raise for voice for anything! Again, as I look back on this job, I could see places where the bridge was starting to burn. My job as a manufacturing programmer, is just like yours. All my work was reviewed by my supervisor period! And I recieved good marks and bad marks on my work and sometimes I was told to redo my programming work, and it was humbling!
So my advice to you as a from manufacturing environment programmer, It's up to you if you want the job, if you like the job and want to stay - it's up to you and your attitude plays a big part in your job. Remember, you are to make your supervisor look GOOD to everyone!! Enough of my preaching... Now enjoy your job.
New contributor
In reading some of these workplace problems, it brings back old memories where I worked in a SLC, UTAH company, in a manufacturing environment as a programmer. In looking back on it, I burned a bridge which I should of NEVER let happen. It was a bridge that I had to cross many times before. My supervisor was known as the company drunk, but he knew his stuff. He had many problems, but that side of him, was none of my business in the first place.
But NEVER tell your immdiate supervisor that he/she is wrong. NEVER! And never in front of his peers or any of his/her supvervisors. That a strike or nail in your coffin.
But before you runoff at the mouth on him/she being wrong, first take some extra time plus some extra effort(s) on your part and research it all the problems out where he/she 'might' be incorrect in full and provide alternate answers or solutions to solve the problem(s). Notice the careful wordings in the above statement??? Use words like "'might' be incorrect" NEVER 'Wrong'. Have supporting documents and answers to support your theories. After you've done your extra homework, set up a time to meet with your supervisor in a meeting form so that it fits his/hers' schedule, not yours! And go into that meeting with an attitude showing that you are workable, friendly, and happy and SHOW IT! One thing I learned with this past supervisor, he could read my attitude and body language and facial features and voice - know everything about me. And with all this effort and a meeting, you could either loose or win.
As my father would say, your supervisor holds the future of your job within the company you work in. In a sense, you are at his/hers' mercy. Oh, one thing I forgot, DON'T raise for voice for anything! Again, as I look back on this job, I could see places where the bridge was starting to burn. My job as a manufacturing programmer, is just like yours. All my work was reviewed by my supervisor period! And I recieved good marks and bad marks on my work and sometimes I was told to redo my programming work, and it was humbling!
So my advice to you as a from manufacturing environment programmer, It's up to you if you want the job, if you like the job and want to stay - it's up to you and your attitude plays a big part in your job. Remember, you are to make your supervisor look GOOD to everyone!! Enough of my preaching... Now enjoy your job.
New contributor
edited 1 hour ago
New contributor
answered 1 hour ago
Tom ThorpeTom Thorpe
11
11
New contributor
New contributor
add a comment |
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f135686%2fhow-do-i-tell-my-manager-that-hes-wrong%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
If you have a process for rejecting comments made during code review, just follow that.
– Laconic Droid
3 hours ago
@LaconicDroid We do not - as I understand it, code reviews go through a process but are somewhat informal at the office.
– osuka_
3 hours ago