Mixing
How can I deal with a coworker who keeps trying to put blame on my shoulders?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
39
down vote
favorite
I have this coworker that I help out very often. One reason he would approach me is that he doesn't have much experience in web applications. However, he is good in his domain.
This person has a pleasant demeanor, but he has this tendency that I don't know how to deal with. Recently this person needed help in a web application based task he was working on and approached me for help (he has done this many times before). I told him what needed to be done and I also told him that he should encrypt values before sending it to the UI.
When he was almost done with his task he told me that he was skipping the encryption, and there was no sensitive data involved, and he started trying to convince me that there was no need for it. I said okay. Later on during his code review he was told by the reviewer that he had to encrypt the values. He then told the reviewer that I agreed it was okay not to encrypt! I know this because his cubicle is close to mine and I overhear everything.
Every time I help him, he says he is going to do the task in a particular way and forces me through an argument into a position where I say okay.
At times he just walks over to my cubicle and tells me what he is doing and at the end he would add, "that is good correct?". Now I don't have time to sit and verify everything he is doing, so I just say yeah. Even on these occasions he uses my name if something goes wrong.
So my questions are:
- How do I tell him that it's his responsibility and not mine, in a polite way?
- If I say yes or okay in an informal conversation, do I really
share the responsibility from that point on? - Is there a way to say that, I am not putting too much thought into
it, but on the surface I don't see anything wrong?
professionalism work-environment colleagues
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
asked May 29 '13 at 15:28
Foo
501269
 |Â
show 5 more comments
up vote
39
down vote
favorite
I have this coworker that I help out very often. One reason he would approach me is that he doesn't have much experience in web applications. However, he is good in his domain.
This person has a pleasant demeanor, but he has this tendency that I don't know how to deal with. Recently this person needed help in a web application based task he was working on and approached me for help (he has done this many times before). I told him what needed to be done and I also told him that he should encrypt values before sending it to the UI.
When he was almost done with his task he told me that he was skipping the encryption, and there was no sensitive data involved, and he started trying to convince me that there was no need for it. I said okay. Later on during his code review he was told by the reviewer that he had to encrypt the values. He then told the reviewer that I agreed it was okay not to encrypt! I know this because his cubicle is close to mine and I overhear everything.
Every time I help him, he says he is going to do the task in a particular way and forces me through an argument into a position where I say okay.
At times he just walks over to my cubicle and tells me what he is doing and at the end he would add, "that is good correct?". Now I don't have time to sit and verify everything he is doing, so I just say yeah. Even on these occasions he uses my name if something goes wrong.
So my questions are:
- How do I tell him that it's his responsibility and not mine, in a polite way?
- If I say yes or okay in an informal conversation, do I really
share the responsibility from that point on? - Is there a way to say that, I am not putting too much thought into
it, but on the surface I don't see anything wrong?
professionalism work-environment colleagues
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
asked May 29 '13 at 15:28
Foo
501269
22
Simple fix, dont let him argue you into saying ok, just drop it and let him do things his own way. Is there a manager you could talk to about this?
– Rhys
May 29 '13 at 15:47
Who conducted the code review? your manager or the client?
– acolyte
May 29 '13 at 17:52
What makes you think it is your responsibility to tell your coworker his responsibilities?
– IDrinkandIKnowThings
May 29 '13 at 17:52
43
Never say okay for something that is not okay. Say, "In my opinion encryption is required; please implement it as you see fit, or discuss with your team." okay is ambiguous. Okay could mean "Look, do whatever you want, just go away, I'm busy" or it could mean "Ah, I see the unassailable logic of your arguments and I agree that it's okay not to use encryption".
– Kaz
May 29 '13 at 21:42
5
Consider doing all this by email, and/or summarizing meetings afterwards. Including your reservations.
– Thorbjørn Ravn Andersen
May 30 '13 at 9:53
 |Â
show 5 more comments
up vote
39
down vote
favorite
up vote
39
down vote
favorite
I have this coworker that I help out very often. One reason he would approach me is that he doesn't have much experience in web applications. However, he is good in his domain.
This person has a pleasant demeanor, but he has this tendency that I don't know how to deal with. Recently this person needed help in a web application based task he was working on and approached me for help (he has done this many times before). I told him what needed to be done and I also told him that he should encrypt values before sending it to the UI.
When he was almost done with his task he told me that he was skipping the encryption, and there was no sensitive data involved, and he started trying to convince me that there was no need for it. I said okay. Later on during his code review he was told by the reviewer that he had to encrypt the values. He then told the reviewer that I agreed it was okay not to encrypt! I know this because his cubicle is close to mine and I overhear everything.
Every time I help him, he says he is going to do the task in a particular way and forces me through an argument into a position where I say okay.
At times he just walks over to my cubicle and tells me what he is doing and at the end he would add, "that is good correct?". Now I don't have time to sit and verify everything he is doing, so I just say yeah. Even on these occasions he uses my name if something goes wrong.
So my questions are:
- How do I tell him that it's his responsibility and not mine, in a polite way?
- If I say yes or okay in an informal conversation, do I really
share the responsibility from that point on? - Is there a way to say that, I am not putting too much thought into
it, but on the surface I don't see anything wrong?
professionalism work-environment colleagues
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
asked May 29 '13 at 15:28
Foo
501269
I have this coworker that I help out very often. One reason he would approach me is that he doesn't have much experience in web applications. However, he is good in his domain.
This person has a pleasant demeanor, but he has this tendency that I don't know how to deal with. Recently this person needed help in a web application based task he was working on and approached me for help (he has done this many times before). I told him what needed to be done and I also told him that he should encrypt values before sending it to the UI.
When he was almost done with his task he told me that he was skipping the encryption, and there was no sensitive data involved, and he started trying to convince me that there was no need for it. I said okay. Later on during his code review he was told by the reviewer that he had to encrypt the values. He then told the reviewer that I agreed it was okay not to encrypt! I know this because his cubicle is close to mine and I overhear everything.
Every time I help him, he says he is going to do the task in a particular way and forces me through an argument into a position where I say okay.
At times he just walks over to my cubicle and tells me what he is doing and at the end he would add, "that is good correct?". Now I don't have time to sit and verify everything he is doing, so I just say yeah. Even on these occasions he uses my name if something goes wrong.
So my questions are:
- How do I tell him that it's his responsibility and not mine, in a polite way?
- If I say yes or okay in an informal conversation, do I really
share the responsibility from that point on? - Is there a way to say that, I am not putting too much thought into
it, but on the surface I don't see anything wrong?
professionalism work-environment colleagues
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
asked May 29 '13 at 15:28
Foo
501269
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
edited Jun 19 '13 at 16:57
IDrinkandIKnowThings
43.9k1398188
43.9k1398188
asked May 29 '13 at 15:28
Foo
501269
asked May 29 '13 at 15:28
Foo
501269
asked May 29 '13 at 15:28
Foo
501269
501269
22
Simple fix, dont let him argue you into saying ok, just drop it and let him do things his own way. Is there a manager you could talk to about this?
– Rhys
May 29 '13 at 15:47
Who conducted the code review? your manager or the client?
– acolyte
May 29 '13 at 17:52
What makes you think it is your responsibility to tell your coworker his responsibilities?
– IDrinkandIKnowThings
May 29 '13 at 17:52
43
Never say okay for something that is not okay. Say, "In my opinion encryption is required; please implement it as you see fit, or discuss with your team." okay is ambiguous. Okay could mean "Look, do whatever you want, just go away, I'm busy" or it could mean "Ah, I see the unassailable logic of your arguments and I agree that it's okay not to use encryption".
– Kaz
May 29 '13 at 21:42
5
Consider doing all this by email, and/or summarizing meetings afterwards. Including your reservations.
– Thorbjørn Ravn Andersen
May 30 '13 at 9:53
 |Â
show 5 more comments
22
Simple fix, dont let him argue you into saying ok, just drop it and let him do things his own way. Is there a manager you could talk to about this?
– Rhys
May 29 '13 at 15:47
Who conducted the code review? your manager or the client?
– acolyte
May 29 '13 at 17:52
What makes you think it is your responsibility to tell your coworker his responsibilities?
– IDrinkandIKnowThings
May 29 '13 at 17:52
43
Never say okay for something that is not okay. Say, "In my opinion encryption is required; please implement it as you see fit, or discuss with your team." okay is ambiguous. Okay could mean "Look, do whatever you want, just go away, I'm busy" or it could mean "Ah, I see the unassailable logic of your arguments and I agree that it's okay not to use encryption".
– Kaz
May 29 '13 at 21:42
5
Consider doing all this by email, and/or summarizing meetings afterwards. Including your reservations.
– Thorbjørn Ravn Andersen
May 30 '13 at 9:53
22
22
Simple fix, dont let him argue you into saying ok, just drop it and let him do things his own way. Is there a manager you could talk to about this?
– Rhys
May 29 '13 at 15:47
Simple fix, dont let him argue you into saying ok, just drop it and let him do things his own way. Is there a manager you could talk to about this?
– Rhys
May 29 '13 at 15:47
Who conducted the code review? your manager or the client?
– acolyte
May 29 '13 at 17:52
Who conducted the code review? your manager or the client?
– acolyte
May 29 '13 at 17:52
What makes you think it is your responsibility to tell your coworker his responsibilities?
– IDrinkandIKnowThings
May 29 '13 at 17:52
What makes you think it is your responsibility to tell your coworker his responsibilities?
– IDrinkandIKnowThings
May 29 '13 at 17:52
43
43
Never say okay for something that is not okay. Say, "In my opinion encryption is required; please implement it as you see fit, or discuss with your team." okay is ambiguous. Okay could mean "Look, do whatever you want, just go away, I'm busy" or it could mean "Ah, I see the unassailable logic of your arguments and I agree that it's okay not to use encryption".
– Kaz
May 29 '13 at 21:42
Never say okay for something that is not okay. Say, "In my opinion encryption is required; please implement it as you see fit, or discuss with your team." okay is ambiguous. Okay could mean "Look, do whatever you want, just go away, I'm busy" or it could mean "Ah, I see the unassailable logic of your arguments and I agree that it's okay not to use encryption".
– Kaz
May 29 '13 at 21:42
5
5
Consider doing all this by email, and/or summarizing meetings afterwards. Including your reservations.
– Thorbjørn Ravn Andersen
May 30 '13 at 9:53
Consider doing all this by email, and/or summarizing meetings afterwards. Including your reservations.
– Thorbjørn Ravn Andersen
May 30 '13 at 9:53
 |Â
show 5 more comments
6 Answers
6
active
oldest
votes
up vote
73
down vote
accepted
The central thing here is when he "forces me through argument into a position where I say okay". The solution is: don't say "okay".
Assuming you are helping him out as a peer and that you are not formally reviewing his code, the next time he says he is going to do something against your advice say "I think it should be done this way but if you want to do it that way it's up to you". If he explains again why he thinks it should be done his way, just repeat your view. Don't let him try to force you into a position where you agree with him - just keep stating that it's his responsibility. Then walk away.
If this is part of a formal review, don't approve his way of doing things if you think its wrong.
If you are questioned later you can say you didn't approve of his way of doing it. (The fact that you haven't been questioned indicates to me that his attempts to stick you with the blame aren't working.)
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
add a comment |Â
up vote
26
down vote
Whenever I have had a coworker who puts blame on me for helping him, I've stopped helping him. No matter how pleasant they are, blaming others is a sign of incompetence or malevolence: they aren't responsible for the failure - you are. It is possible that by using your name to his superiors, he could be setting you up for discipline, or perhaps he grew up believing that any failure could be waved away with a suitable excuse to parents & teachers. If he's setting you up for failure, keep this old joke in mind:
Steve and Mark are camping when a bear suddenly comes out and growls. Steve starts putting on his tennis shoes.
Mark says, "What are you doing? You can't outrun a bear!"
Steve says, "I don’t have to outrun the bear-I just have to outrun you!"
Source.
When dealing with this person in the future, avoid saying "OK". Depending on context, that word is understood to be a social noise that substantially means "I hear you, keep talking." Your coworker only seems to be hearing it as an affirmative blessing. To help mitigate these sorts of communication failures in the future, I recommend reading How to Disagree Without Being Disagreeable. While this book is aimed more at handling hostile language in the workplace, it gives a framework for understanding what the other person is really trying to say.
answered May 29 '13 at 16:54
Tangurena
5,0401936
2
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
1
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
add a comment |Â
up vote
8
down vote
Why does he ask you?
He could be asking you for a variety of reasons. Each will have a different way to deal with them appropriately:
- He is legitimately stuck and you're approachable
- He is a help vampire
- He is looking for someone to defer responsibility when something goes wrong
Generally if it's case 2 or case 3, you shouldn't waste your time (company resources) aiding a horrible habit. But perhaps you're the type of person who can't say no. If that's the case, the following tactic will likely work for you regardless of the reason he's asking.
Give a Man a Fish...
This is the wrong way to help him:
You should encrypt values before sending it to the UI
This teaches him absolutely nothing. It tells him what he should do, but not why he should do it. Here is a parable to demonstrate the principle from another answer:
If you ask me what the current rate between JPY and USD is, I can tell
you (about 95 JPY/USD). If you need to know the same thing again next
week, or next month, and I'm not around, what will you do?
It may be efficient in the short-term to just tell you to use 95, but
long-term if an important part of your work is knowing what the JPY to
USD rate is, it's much better for me to teach you how to figure it out
rather than just telling you the answer.
Now many people may assume this means I should just give you a link
and then it will all be okay because you can find it next time.
Problem solved, right?
What happens if you need to know the rate between USD and EUR? What
will you do then? Of course I can give you another link, but then you
will just have two separate links, and run in to the exact same
problem if another currency is required.
If you guide him through the thought process, rather than just giving the answer, it will have the following effect:
If he is legitimately stuck
It will give him a tool on how to think through the situation on his own, and help him ask fewer questions in the future. You win. He wins. The company wins. And you look like an awesome mentor, which is always good.
If he is a Help Vampire
It will get him to say things like, "Yes, but what's the answer?" or "But I don't have time for this?" in which case you can easily see that he is just mooching off your brains to do his job for him. I would respond to future requests with something like this:
I'm a bit busy working on a project right now, but if you absolutely need help would you mind running it by my boss first?
If he is a responsibility-evader
It will get him to say things like, "What would you choose?" or "Is it okay if I...?" in which case you can understand what he's after. I would respond to future requests with something like:
I can tell you what the concepts are as far as I understand them, but for the specific requirements you'd be better off discussing it with your boss.
The Curse of Competence
The problem with competent people in virtually any workplace is that they think the ability to do more work is a universal benefit. "I can do it better than they can, therefore I should do it" is going to come to bite you in the end.
You can either view this as an opportunity to become a better teacher (rather than a supplier of results), or as an opportunity to become better at saying no. Don't just blindly do whatever work is thrown at you -- with great competence comes great responsibility to use that ability where it will have the greatest impact.
Wasting your time on help vampires will end up having people call in to question your judgment, rather than have people congratulating your talent.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 4 '13 at 1:51
jmac
19.4k763137
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
add a comment |Â
up vote
5
down vote
I am sorry to say this: you're in the wrong here.
You should never say Okay to something that you don't agree with be it in your personal or professional life.
Strong communication is the key for every people related issue you'll have, and brushing off people with an 'Okay', is the opposite of strong communication, you're not communicating your intent, and if you want to remain political about it, you can always communicate a different intent which won't hurt the person.
"If I were you, I'd implement that encryption"
"I don't really have the time to discuss this issue right now, I'm sorry"
answered Jun 2 '13 at 10:22
itaitay
22827
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
add a comment |Â
up vote
4
down vote
This is very profession specific..
But browsing code and reviewing code are two entirely different activities.
When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?
If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.
If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.
Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.
If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.
answered May 30 '13 at 6:55
JustinC
320111
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
add a comment |Â
up vote
1
down vote
This situation needs to be clarified by your supervisor. Get specific expectations about your helping this person with web development. Are you a resource for help (i.e. a glorified Google) or are you responsible for how web apps are developed in your company?
Once you've clarified this with your supervisor make sure your coworker understands the relationship.
If you are a resource, your coworker takes full responsibility for any code he/she writes. Your name is not to be mentioned. If you are responsible for web developement, you'll need to be involved in the review process. You'll need to be more demanding in your views being implemented.
Some things can be handled by using exceptable practices (Passwords are considered sensitive data about 100% of the time.), but the others should be driven by requirments and specifications.
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
add a comment |Â
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
up vote
73
down vote
accepted
The central thing here is when he "forces me through argument into a position where I say okay". The solution is: don't say "okay".
Assuming you are helping him out as a peer and that you are not formally reviewing his code, the next time he says he is going to do something against your advice say "I think it should be done this way but if you want to do it that way it's up to you". If he explains again why he thinks it should be done his way, just repeat your view. Don't let him try to force you into a position where you agree with him - just keep stating that it's his responsibility. Then walk away.
If this is part of a formal review, don't approve his way of doing things if you think its wrong.
If you are questioned later you can say you didn't approve of his way of doing it. (The fact that you haven't been questioned indicates to me that his attempts to stick you with the blame aren't working.)
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
add a comment |Â
up vote
73
down vote
accepted
The central thing here is when he "forces me through argument into a position where I say okay". The solution is: don't say "okay".
Assuming you are helping him out as a peer and that you are not formally reviewing his code, the next time he says he is going to do something against your advice say "I think it should be done this way but if you want to do it that way it's up to you". If he explains again why he thinks it should be done his way, just repeat your view. Don't let him try to force you into a position where you agree with him - just keep stating that it's his responsibility. Then walk away.
If this is part of a formal review, don't approve his way of doing things if you think its wrong.
If you are questioned later you can say you didn't approve of his way of doing it. (The fact that you haven't been questioned indicates to me that his attempts to stick you with the blame aren't working.)
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
add a comment |Â
up vote
73
down vote
accepted
up vote
73
down vote
accepted
The central thing here is when he "forces me through argument into a position where I say okay". The solution is: don't say "okay".
Assuming you are helping him out as a peer and that you are not formally reviewing his code, the next time he says he is going to do something against your advice say "I think it should be done this way but if you want to do it that way it's up to you". If he explains again why he thinks it should be done his way, just repeat your view. Don't let him try to force you into a position where you agree with him - just keep stating that it's his responsibility. Then walk away.
If this is part of a formal review, don't approve his way of doing things if you think its wrong.
If you are questioned later you can say you didn't approve of his way of doing it. (The fact that you haven't been questioned indicates to me that his attempts to stick you with the blame aren't working.)
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
The central thing here is when he "forces me through argument into a position where I say okay". The solution is: don't say "okay".
Assuming you are helping him out as a peer and that you are not formally reviewing his code, the next time he says he is going to do something against your advice say "I think it should be done this way but if you want to do it that way it's up to you". If he explains again why he thinks it should be done his way, just repeat your view. Don't let him try to force you into a position where you agree with him - just keep stating that it's his responsibility. Then walk away.
If this is part of a formal review, don't approve his way of doing things if you think its wrong.
If you are questioned later you can say you didn't approve of his way of doing it. (The fact that you haven't been questioned indicates to me that his attempts to stick you with the blame aren't working.)
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
edited Oct 19 '16 at 3:15
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
answered May 29 '13 at 15:51
DJClayworth
41.6k989147
41.6k989147
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
add a comment |Â
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
I would also advise that you don't take too much blame for the review. Competent senior developers reviewing your colleague knows that just because you say OK, the responsibility is still on him. Many people claim someone else "approved" their actions for many serious crimes. They went to jail just the same. If they instead said "Sorry, I was wrong. I won't do it again.", then it's different.
– Nelson
Oct 19 '16 at 7:24
add a comment |Â
up vote
26
down vote
Whenever I have had a coworker who puts blame on me for helping him, I've stopped helping him. No matter how pleasant they are, blaming others is a sign of incompetence or malevolence: they aren't responsible for the failure - you are. It is possible that by using your name to his superiors, he could be setting you up for discipline, or perhaps he grew up believing that any failure could be waved away with a suitable excuse to parents & teachers. If he's setting you up for failure, keep this old joke in mind:
Steve and Mark are camping when a bear suddenly comes out and growls. Steve starts putting on his tennis shoes.
Mark says, "What are you doing? You can't outrun a bear!"
Steve says, "I don’t have to outrun the bear-I just have to outrun you!"
Source.
When dealing with this person in the future, avoid saying "OK". Depending on context, that word is understood to be a social noise that substantially means "I hear you, keep talking." Your coworker only seems to be hearing it as an affirmative blessing. To help mitigate these sorts of communication failures in the future, I recommend reading How to Disagree Without Being Disagreeable. While this book is aimed more at handling hostile language in the workplace, it gives a framework for understanding what the other person is really trying to say.
answered May 29 '13 at 16:54
Tangurena
5,0401936
2
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
1
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
add a comment |Â
up vote
26
down vote
Whenever I have had a coworker who puts blame on me for helping him, I've stopped helping him. No matter how pleasant they are, blaming others is a sign of incompetence or malevolence: they aren't responsible for the failure - you are. It is possible that by using your name to his superiors, he could be setting you up for discipline, or perhaps he grew up believing that any failure could be waved away with a suitable excuse to parents & teachers. If he's setting you up for failure, keep this old joke in mind:
Steve and Mark are camping when a bear suddenly comes out and growls. Steve starts putting on his tennis shoes.
Mark says, "What are you doing? You can't outrun a bear!"
Steve says, "I don’t have to outrun the bear-I just have to outrun you!"
Source.
When dealing with this person in the future, avoid saying "OK". Depending on context, that word is understood to be a social noise that substantially means "I hear you, keep talking." Your coworker only seems to be hearing it as an affirmative blessing. To help mitigate these sorts of communication failures in the future, I recommend reading How to Disagree Without Being Disagreeable. While this book is aimed more at handling hostile language in the workplace, it gives a framework for understanding what the other person is really trying to say.
answered May 29 '13 at 16:54
Tangurena
5,0401936
2
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
1
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
add a comment |Â
up vote
26
down vote
up vote
26
down vote
Whenever I have had a coworker who puts blame on me for helping him, I've stopped helping him. No matter how pleasant they are, blaming others is a sign of incompetence or malevolence: they aren't responsible for the failure - you are. It is possible that by using your name to his superiors, he could be setting you up for discipline, or perhaps he grew up believing that any failure could be waved away with a suitable excuse to parents & teachers. If he's setting you up for failure, keep this old joke in mind:
Steve and Mark are camping when a bear suddenly comes out and growls. Steve starts putting on his tennis shoes.
Mark says, "What are you doing? You can't outrun a bear!"
Steve says, "I don’t have to outrun the bear-I just have to outrun you!"
Source.
When dealing with this person in the future, avoid saying "OK". Depending on context, that word is understood to be a social noise that substantially means "I hear you, keep talking." Your coworker only seems to be hearing it as an affirmative blessing. To help mitigate these sorts of communication failures in the future, I recommend reading How to Disagree Without Being Disagreeable. While this book is aimed more at handling hostile language in the workplace, it gives a framework for understanding what the other person is really trying to say.
answered May 29 '13 at 16:54
Tangurena
5,0401936
Whenever I have had a coworker who puts blame on me for helping him, I've stopped helping him. No matter how pleasant they are, blaming others is a sign of incompetence or malevolence: they aren't responsible for the failure - you are. It is possible that by using your name to his superiors, he could be setting you up for discipline, or perhaps he grew up believing that any failure could be waved away with a suitable excuse to parents & teachers. If he's setting you up for failure, keep this old joke in mind:
Steve and Mark are camping when a bear suddenly comes out and growls. Steve starts putting on his tennis shoes.
Mark says, "What are you doing? You can't outrun a bear!"
Steve says, "I don’t have to outrun the bear-I just have to outrun you!"
Source.
When dealing with this person in the future, avoid saying "OK". Depending on context, that word is understood to be a social noise that substantially means "I hear you, keep talking." Your coworker only seems to be hearing it as an affirmative blessing. To help mitigate these sorts of communication failures in the future, I recommend reading How to Disagree Without Being Disagreeable. While this book is aimed more at handling hostile language in the workplace, it gives a framework for understanding what the other person is really trying to say.
answered May 29 '13 at 16:54
Tangurena
5,0401936
answered May 29 '13 at 16:54
Tangurena
5,0401936
answered May 29 '13 at 16:54
Tangurena
5,0401936
answered May 29 '13 at 16:54
Tangurena
5,0401936
5,0401936
2
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
1
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
add a comment |Â
2
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
1
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
2
2
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
I disagree with your first paragraph because you are there to provide service to your employer and refusing to help your coworker does not meet that objective. But I think your second paragraph is quite on target.
– IDrinkandIKnowThings
May 29 '13 at 17:49
1
1
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
You can't help your employer if you get fired or even devalued to your colleagues because someone screws your reputation.
– Amy Blankenship
May 31 '13 at 23:34
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
@IDrinkandIKnowThings I'm guessing this is more a case of "here's some search terms that can help you" type help and not explicit "no, I won't help you". There's a difference between helping a coworker and doing their work for them.
– iheanyi
Jun 30 '17 at 20:51
add a comment |Â
up vote
8
down vote
Why does he ask you?
He could be asking you for a variety of reasons. Each will have a different way to deal with them appropriately:
- He is legitimately stuck and you're approachable
- He is a help vampire
- He is looking for someone to defer responsibility when something goes wrong
Generally if it's case 2 or case 3, you shouldn't waste your time (company resources) aiding a horrible habit. But perhaps you're the type of person who can't say no. If that's the case, the following tactic will likely work for you regardless of the reason he's asking.
Give a Man a Fish...
This is the wrong way to help him:
You should encrypt values before sending it to the UI
This teaches him absolutely nothing. It tells him what he should do, but not why he should do it. Here is a parable to demonstrate the principle from another answer:
If you ask me what the current rate between JPY and USD is, I can tell
you (about 95 JPY/USD). If you need to know the same thing again next
week, or next month, and I'm not around, what will you do?
It may be efficient in the short-term to just tell you to use 95, but
long-term if an important part of your work is knowing what the JPY to
USD rate is, it's much better for me to teach you how to figure it out
rather than just telling you the answer.
Now many people may assume this means I should just give you a link
and then it will all be okay because you can find it next time.
Problem solved, right?
What happens if you need to know the rate between USD and EUR? What
will you do then? Of course I can give you another link, but then you
will just have two separate links, and run in to the exact same
problem if another currency is required.
If you guide him through the thought process, rather than just giving the answer, it will have the following effect:
If he is legitimately stuck
It will give him a tool on how to think through the situation on his own, and help him ask fewer questions in the future. You win. He wins. The company wins. And you look like an awesome mentor, which is always good.
If he is a Help Vampire
It will get him to say things like, "Yes, but what's the answer?" or "But I don't have time for this?" in which case you can easily see that he is just mooching off your brains to do his job for him. I would respond to future requests with something like this:
I'm a bit busy working on a project right now, but if you absolutely need help would you mind running it by my boss first?
If he is a responsibility-evader
It will get him to say things like, "What would you choose?" or "Is it okay if I...?" in which case you can understand what he's after. I would respond to future requests with something like:
I can tell you what the concepts are as far as I understand them, but for the specific requirements you'd be better off discussing it with your boss.
The Curse of Competence
The problem with competent people in virtually any workplace is that they think the ability to do more work is a universal benefit. "I can do it better than they can, therefore I should do it" is going to come to bite you in the end.
You can either view this as an opportunity to become a better teacher (rather than a supplier of results), or as an opportunity to become better at saying no. Don't just blindly do whatever work is thrown at you -- with great competence comes great responsibility to use that ability where it will have the greatest impact.
Wasting your time on help vampires will end up having people call in to question your judgment, rather than have people congratulating your talent.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 4 '13 at 1:51
jmac
19.4k763137
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
add a comment |Â
up vote
8
down vote
Why does he ask you?
He could be asking you for a variety of reasons. Each will have a different way to deal with them appropriately:
- He is legitimately stuck and you're approachable
- He is a help vampire
- He is looking for someone to defer responsibility when something goes wrong
Generally if it's case 2 or case 3, you shouldn't waste your time (company resources) aiding a horrible habit. But perhaps you're the type of person who can't say no. If that's the case, the following tactic will likely work for you regardless of the reason he's asking.
Give a Man a Fish...
This is the wrong way to help him:
You should encrypt values before sending it to the UI
This teaches him absolutely nothing. It tells him what he should do, but not why he should do it. Here is a parable to demonstrate the principle from another answer:
If you ask me what the current rate between JPY and USD is, I can tell
you (about 95 JPY/USD). If you need to know the same thing again next
week, or next month, and I'm not around, what will you do?
It may be efficient in the short-term to just tell you to use 95, but
long-term if an important part of your work is knowing what the JPY to
USD rate is, it's much better for me to teach you how to figure it out
rather than just telling you the answer.
Now many people may assume this means I should just give you a link
and then it will all be okay because you can find it next time.
Problem solved, right?
What happens if you need to know the rate between USD and EUR? What
will you do then? Of course I can give you another link, but then you
will just have two separate links, and run in to the exact same
problem if another currency is required.
If you guide him through the thought process, rather than just giving the answer, it will have the following effect:
If he is legitimately stuck
It will give him a tool on how to think through the situation on his own, and help him ask fewer questions in the future. You win. He wins. The company wins. And you look like an awesome mentor, which is always good.
If he is a Help Vampire
It will get him to say things like, "Yes, but what's the answer?" or "But I don't have time for this?" in which case you can easily see that he is just mooching off your brains to do his job for him. I would respond to future requests with something like this:
I'm a bit busy working on a project right now, but if you absolutely need help would you mind running it by my boss first?
If he is a responsibility-evader
It will get him to say things like, "What would you choose?" or "Is it okay if I...?" in which case you can understand what he's after. I would respond to future requests with something like:
I can tell you what the concepts are as far as I understand them, but for the specific requirements you'd be better off discussing it with your boss.
The Curse of Competence
The problem with competent people in virtually any workplace is that they think the ability to do more work is a universal benefit. "I can do it better than they can, therefore I should do it" is going to come to bite you in the end.
You can either view this as an opportunity to become a better teacher (rather than a supplier of results), or as an opportunity to become better at saying no. Don't just blindly do whatever work is thrown at you -- with great competence comes great responsibility to use that ability where it will have the greatest impact.
Wasting your time on help vampires will end up having people call in to question your judgment, rather than have people congratulating your talent.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 4 '13 at 1:51
jmac
19.4k763137
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
add a comment |Â
up vote
8
down vote
up vote
8
down vote
Why does he ask you?
He could be asking you for a variety of reasons. Each will have a different way to deal with them appropriately:
- He is legitimately stuck and you're approachable
- He is a help vampire
- He is looking for someone to defer responsibility when something goes wrong
Generally if it's case 2 or case 3, you shouldn't waste your time (company resources) aiding a horrible habit. But perhaps you're the type of person who can't say no. If that's the case, the following tactic will likely work for you regardless of the reason he's asking.
Give a Man a Fish...
This is the wrong way to help him:
You should encrypt values before sending it to the UI
This teaches him absolutely nothing. It tells him what he should do, but not why he should do it. Here is a parable to demonstrate the principle from another answer:
If you ask me what the current rate between JPY and USD is, I can tell
you (about 95 JPY/USD). If you need to know the same thing again next
week, or next month, and I'm not around, what will you do?
It may be efficient in the short-term to just tell you to use 95, but
long-term if an important part of your work is knowing what the JPY to
USD rate is, it's much better for me to teach you how to figure it out
rather than just telling you the answer.
Now many people may assume this means I should just give you a link
and then it will all be okay because you can find it next time.
Problem solved, right?
What happens if you need to know the rate between USD and EUR? What
will you do then? Of course I can give you another link, but then you
will just have two separate links, and run in to the exact same
problem if another currency is required.
If you guide him through the thought process, rather than just giving the answer, it will have the following effect:
If he is legitimately stuck
It will give him a tool on how to think through the situation on his own, and help him ask fewer questions in the future. You win. He wins. The company wins. And you look like an awesome mentor, which is always good.
If he is a Help Vampire
It will get him to say things like, "Yes, but what's the answer?" or "But I don't have time for this?" in which case you can easily see that he is just mooching off your brains to do his job for him. I would respond to future requests with something like this:
I'm a bit busy working on a project right now, but if you absolutely need help would you mind running it by my boss first?
If he is a responsibility-evader
It will get him to say things like, "What would you choose?" or "Is it okay if I...?" in which case you can understand what he's after. I would respond to future requests with something like:
I can tell you what the concepts are as far as I understand them, but for the specific requirements you'd be better off discussing it with your boss.
The Curse of Competence
The problem with competent people in virtually any workplace is that they think the ability to do more work is a universal benefit. "I can do it better than they can, therefore I should do it" is going to come to bite you in the end.
You can either view this as an opportunity to become a better teacher (rather than a supplier of results), or as an opportunity to become better at saying no. Don't just blindly do whatever work is thrown at you -- with great competence comes great responsibility to use that ability where it will have the greatest impact.
Wasting your time on help vampires will end up having people call in to question your judgment, rather than have people congratulating your talent.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 4 '13 at 1:51
jmac
19.4k763137
Why does he ask you?
He could be asking you for a variety of reasons. Each will have a different way to deal with them appropriately:
- He is legitimately stuck and you're approachable
- He is a help vampire
- He is looking for someone to defer responsibility when something goes wrong
Generally if it's case 2 or case 3, you shouldn't waste your time (company resources) aiding a horrible habit. But perhaps you're the type of person who can't say no. If that's the case, the following tactic will likely work for you regardless of the reason he's asking.
Give a Man a Fish...
This is the wrong way to help him:
You should encrypt values before sending it to the UI
This teaches him absolutely nothing. It tells him what he should do, but not why he should do it. Here is a parable to demonstrate the principle from another answer:
If you ask me what the current rate between JPY and USD is, I can tell
you (about 95 JPY/USD). If you need to know the same thing again next
week, or next month, and I'm not around, what will you do?
It may be efficient in the short-term to just tell you to use 95, but
long-term if an important part of your work is knowing what the JPY to
USD rate is, it's much better for me to teach you how to figure it out
rather than just telling you the answer.
Now many people may assume this means I should just give you a link
and then it will all be okay because you can find it next time.
Problem solved, right?
What happens if you need to know the rate between USD and EUR? What
will you do then? Of course I can give you another link, but then you
will just have two separate links, and run in to the exact same
problem if another currency is required.
If you guide him through the thought process, rather than just giving the answer, it will have the following effect:
If he is legitimately stuck
It will give him a tool on how to think through the situation on his own, and help him ask fewer questions in the future. You win. He wins. The company wins. And you look like an awesome mentor, which is always good.
If he is a Help Vampire
It will get him to say things like, "Yes, but what's the answer?" or "But I don't have time for this?" in which case you can easily see that he is just mooching off your brains to do his job for him. I would respond to future requests with something like this:
I'm a bit busy working on a project right now, but if you absolutely need help would you mind running it by my boss first?
If he is a responsibility-evader
It will get him to say things like, "What would you choose?" or "Is it okay if I...?" in which case you can understand what he's after. I would respond to future requests with something like:
I can tell you what the concepts are as far as I understand them, but for the specific requirements you'd be better off discussing it with your boss.
The Curse of Competence
The problem with competent people in virtually any workplace is that they think the ability to do more work is a universal benefit. "I can do it better than they can, therefore I should do it" is going to come to bite you in the end.
You can either view this as an opportunity to become a better teacher (rather than a supplier of results), or as an opportunity to become better at saying no. Don't just blindly do whatever work is thrown at you -- with great competence comes great responsibility to use that ability where it will have the greatest impact.
Wasting your time on help vampires will end up having people call in to question your judgment, rather than have people congratulating your talent.
edited Apr 13 '17 at 12:48
Community♦
1
answered Jun 4 '13 at 1:51
jmac
19.4k763137
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
edited Apr 13 '17 at 12:48
Community♦
1
1
answered Jun 4 '13 at 1:51
jmac
19.4k763137
answered Jun 4 '13 at 1:51
jmac
19.4k763137
answered Jun 4 '13 at 1:51
jmac
19.4k763137
19.4k763137
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
add a comment |Â
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
Regarding your last paragraph, why do you say that people would "question your judgment" if you continue helping?
– Pacerier
May 28 '15 at 10:44
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
@Pacerier time is a limited resource. If you keep using it on folks who don't really want to learn, then people will question your judgment on how you use that limited resource.
– jmac
May 28 '15 at 15:04
add a comment |Â
up vote
5
down vote
I am sorry to say this: you're in the wrong here.
You should never say Okay to something that you don't agree with be it in your personal or professional life.
Strong communication is the key for every people related issue you'll have, and brushing off people with an 'Okay', is the opposite of strong communication, you're not communicating your intent, and if you want to remain political about it, you can always communicate a different intent which won't hurt the person.
"If I were you, I'd implement that encryption"
"I don't really have the time to discuss this issue right now, I'm sorry"
answered Jun 2 '13 at 10:22
itaitay
22827
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
add a comment |Â
up vote
5
down vote
I am sorry to say this: you're in the wrong here.
You should never say Okay to something that you don't agree with be it in your personal or professional life.
Strong communication is the key for every people related issue you'll have, and brushing off people with an 'Okay', is the opposite of strong communication, you're not communicating your intent, and if you want to remain political about it, you can always communicate a different intent which won't hurt the person.
"If I were you, I'd implement that encryption"
"I don't really have the time to discuss this issue right now, I'm sorry"
answered Jun 2 '13 at 10:22
itaitay
22827
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
add a comment |Â
up vote
5
down vote
up vote
5
down vote
I am sorry to say this: you're in the wrong here.
You should never say Okay to something that you don't agree with be it in your personal or professional life.
Strong communication is the key for every people related issue you'll have, and brushing off people with an 'Okay', is the opposite of strong communication, you're not communicating your intent, and if you want to remain political about it, you can always communicate a different intent which won't hurt the person.
"If I were you, I'd implement that encryption"
"I don't really have the time to discuss this issue right now, I'm sorry"
answered Jun 2 '13 at 10:22
itaitay
22827
I am sorry to say this: you're in the wrong here.
You should never say Okay to something that you don't agree with be it in your personal or professional life.
Strong communication is the key for every people related issue you'll have, and brushing off people with an 'Okay', is the opposite of strong communication, you're not communicating your intent, and if you want to remain political about it, you can always communicate a different intent which won't hurt the person.
"If I were you, I'd implement that encryption"
"I don't really have the time to discuss this issue right now, I'm sorry"
answered Jun 2 '13 at 10:22
itaitay
22827
answered Jun 2 '13 at 10:22
itaitay
22827
answered Jun 2 '13 at 10:22
itaitay
22827
answered Jun 2 '13 at 10:22
itaitay
22827
22827
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
add a comment |Â
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
Regarding "I don't really have the time to discuss this issue right now, I'm sorry", what if he insist?
– Pacerier
May 28 '15 at 10:49
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
@Pacerier, then you repeat you do not have time to discuss and refer him to his boss for an answer. Then physically turn away and start working.
– HLGEM
Jan 18 '17 at 18:42
add a comment |Â
up vote
4
down vote
This is very profession specific..
But browsing code and reviewing code are two entirely different activities.
When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?
If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.
If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.
Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.
If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.
answered May 30 '13 at 6:55
JustinC
320111
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
add a comment |Â
up vote
4
down vote
This is very profession specific..
But browsing code and reviewing code are two entirely different activities.
When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?
If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.
If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.
Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.
If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.
answered May 30 '13 at 6:55
JustinC
320111
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
add a comment |Â
up vote
4
down vote
up vote
4
down vote
This is very profession specific..
But browsing code and reviewing code are two entirely different activities.
When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?
If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.
If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.
Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.
If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.
answered May 30 '13 at 6:55
JustinC
320111
This is very profession specific..
But browsing code and reviewing code are two entirely different activities.
When working with them in the future establish better, clearer expectations of each other. First, make sure its in the scope of your responsibilities. You have your own work to do and reviews and mentoring take time. Are you helping to pass a review, or helping him to get past a small bump in the road?
If they are looking for a review, even if its merely as a sanity check before thy proceed with a formal review, insist on the requirements or bug reports they based this work around, the style-conformance reports, the tests, and the test reports. Evaluate those before even looking at the code in question. Even if they haven't completed the feature and not all the tests are written and passing, the style and test reports show the level of detail and effort thus far applied, where they are having success, and where they are perhaps falling a bit short. The tests will show how well they are exercising the different aspects of their feature, to know whether it is robust and usable, or fragile and too naïve.
If they have questions about some implementation issue, then look at their actual system code. If you see something that can be improved in that aspect, offer a technique and maybe a couple of tips on how to apply it, but let them do the research. Point out that they have research to do because there are consequences to that technique that they need to know about (as there is with any technique). Some of the consequences you may not remember, and may not know how it fits with the rest of what they are doing. When looking for information on that technique they may come across alternatives that fit even better. That is why they need to do their own research.
Make it clear you do not have all the answers. This is where you both had problems: they were treating you as an authority, an authority that could be pliable. Don't be the authority, and you can be as pliable as you want. Or be the authority, and expect nothing less than for them to respect it.
If they, on the other hand, need help understanding what something is doing, help them isolate the 'extra stuff' from the 'critical parts' so they can see for themselves what is going on. Make it clear the 'extra stuff' matters, but look past it to appreciate the larger intent of the 'critical stuff'. Its a fair concern that looking at a section of code or a group of modules for so long can easily get you lost in the forest. Sometimes it takes an outside view to regain perspective.
answered May 30 '13 at 6:55
JustinC
320111
edited May 30 '13 at 7:14
answered May 30 '13 at 6:55
JustinC
320111
answered May 30 '13 at 6:55
JustinC
320111
answered May 30 '13 at 6:55
JustinC
320111
320111
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
add a comment |Â
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
What do you mean by "expect nothing less than for them to respect it"? How would you actually go about doing that?
– Pacerier
May 28 '15 at 10:47
add a comment |Â
up vote
1
down vote
This situation needs to be clarified by your supervisor. Get specific expectations about your helping this person with web development. Are you a resource for help (i.e. a glorified Google) or are you responsible for how web apps are developed in your company?
Once you've clarified this with your supervisor make sure your coworker understands the relationship.
If you are a resource, your coworker takes full responsibility for any code he/she writes. Your name is not to be mentioned. If you are responsible for web developement, you'll need to be involved in the review process. You'll need to be more demanding in your views being implemented.
Some things can be handled by using exceptable practices (Passwords are considered sensitive data about 100% of the time.), but the others should be driven by requirments and specifications.
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
add a comment |Â
up vote
1
down vote
This situation needs to be clarified by your supervisor. Get specific expectations about your helping this person with web development. Are you a resource for help (i.e. a glorified Google) or are you responsible for how web apps are developed in your company?
Once you've clarified this with your supervisor make sure your coworker understands the relationship.
If you are a resource, your coworker takes full responsibility for any code he/she writes. Your name is not to be mentioned. If you are responsible for web developement, you'll need to be involved in the review process. You'll need to be more demanding in your views being implemented.
Some things can be handled by using exceptable practices (Passwords are considered sensitive data about 100% of the time.), but the others should be driven by requirments and specifications.
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
add a comment |Â
up vote
1
down vote
up vote
1
down vote
This situation needs to be clarified by your supervisor. Get specific expectations about your helping this person with web development. Are you a resource for help (i.e. a glorified Google) or are you responsible for how web apps are developed in your company?
Once you've clarified this with your supervisor make sure your coworker understands the relationship.
If you are a resource, your coworker takes full responsibility for any code he/she writes. Your name is not to be mentioned. If you are responsible for web developement, you'll need to be involved in the review process. You'll need to be more demanding in your views being implemented.
Some things can be handled by using exceptable practices (Passwords are considered sensitive data about 100% of the time.), but the others should be driven by requirments and specifications.
This situation needs to be clarified by your supervisor. Get specific expectations about your helping this person with web development. Are you a resource for help (i.e. a glorified Google) or are you responsible for how web apps are developed in your company?
Once you've clarified this with your supervisor make sure your coworker understands the relationship.
If you are a resource, your coworker takes full responsibility for any code he/she writes. Your name is not to be mentioned. If you are responsible for web developement, you'll need to be involved in the review process. You'll need to be more demanding in your views being implemented.
Some things can be handled by using exceptable practices (Passwords are considered sensitive data about 100% of the time.), but the others should be driven by requirments and specifications.
answered May 31 '13 at 13:01
user8365
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
add a comment |Â
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
Is "glorified Google" supposed to be good or bad?
– Pacerier
May 28 '15 at 10:52
add a comment |Â
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f12081%2fhow-can-i-deal-with-a-coworker-who-keeps-trying-to-put-blame-on-my-shoulders%23new-answer', 'question_page');
);
Post as a guest
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
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
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
22
Simple fix, dont let him argue you into saying ok, just drop it and let him do things his own way. Is there a manager you could talk to about this?
– Rhys
May 29 '13 at 15:47
Who conducted the code review? your manager or the client?
– acolyte
May 29 '13 at 17:52
What makes you think it is your responsibility to tell your coworker his responsibilities?
– IDrinkandIKnowThings
May 29 '13 at 17:52
43
Never say okay for something that is not okay. Say, "In my opinion encryption is required; please implement it as you see fit, or discuss with your team." okay is ambiguous. Okay could mean "Look, do whatever you want, just go away, I'm busy" or it could mean "Ah, I see the unassailable logic of your arguments and I agree that it's okay not to use encryption".
– Kaz
May 29 '13 at 21:42
5
Consider doing all this by email, and/or summarizing meetings afterwards. Including your reservations.
– Thorbjørn Ravn Andersen
May 30 '13 at 9:53