Iyfjky

Question

I've got a message from a peer programmer (over a conflict happened due to his changes in the code I'm responsible for, done over my head). He wrote that they (he and PM) already decided to do it this way, aren't going to change anything and my opinion means nothing. That guy is in the same position, and I wasn't told about any promotions. The PM is elusive and I couldn't get any certain statements from him.

Any ideas how to resolve this situation? Because I see only 2 solutions - bow or resign, and I don't like either.

UPD I wasn't told about any problems on my side before this happened. These changes don't address any specific problems, it's just a "slight refactoring". The problem is that this refactoring is not small at all, and it breaks things.

UPD2 this question is not about a senior colleague. It's about a peer.

UPD3 so, I talked to the manager and explained him that the situation when another guy rewrites my code without asking me anything is not how the things should be done. However, if he really wants to keep his changes - he has to take full responsibility for the project from now on. Some time later, I was kicked out of the company "in a process of working teams optimization".

Possible duplicate of How to handle a senior colleague who is overstepping their authority? — Apr 21 '16 at 22:40
The coworker was out of line saying that, which shows he's quite happy to proactively antagonise you, be careful around this chap, he doesn't like you or respect you. That is the 'real' issue you need to deal with. — Apr 22 '16 at 6:06
<sarcasm>I wish everyone relying on the software produced by your company the best of luck. </sarcasm> Good luck for the future. Hope you find a company that is run by people with a bit more sense. — Jul 10 '16 at 20:44

score 5 · Accepted Answer · 2016-04-21 17:35:25Z

I get you are getting beat up over this but I would consider quitting also.

In summary

Code you are responsible for

You had not been informed of any problems

Peer meets with PM over refactoring code you are responsible for

You are not included nor informed

According to peer an executive decision is made to refactor the code you are responsible for

You are not included in this decision

You are informed of the executive decision by peer not PM
At a minimum this executive decision should have come from the PM

The change is characterized as "slight refactoring"

In the opinion of the OP responsible for the code it is not slight and breaks a lot of stuff

This not proper. If you are responsible for the code then you deserve to be part of design decision. Even if you are shot down on every detail you should have a say. If they characterize as "slight refactoring" and you say it is not slight and breaks stuff then clearly there is a major disconnect. At a minimum they should explain to you how this "slight". Maybe you are missing something and maybe they are wrong. This is not how to manage a software team. This not how to manage software design.

You have couple problems:

Change is not minor

Process going forward

On the first I would outline in writing that the change is not minor. Outline how it effects the code overall and the stuff it would break. Ask for a meeting to discuss the matter.

On the second you need to have a heart to heart with the PM. Tell him straight up you think you deserve to be involved in design decisions regarding your code. If he tells you no I will make executive decision and may or may not include you then just tell him don't agree that is effective but you will follow orders. From there make a decision to suck it up look for another job. If the PM refuses to even have a process meeting with you then need to make a decision to suck it up or look for another job. Don't threaten to quit - nothing good would come from that. I personally would look for another job. I don't mind losing an architecture decision about code I am responsible for but I feel like I deserve to be part of the discussion.

Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit? — Apr 21 '16 at 14:56
@enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you. — Apr 21 '16 at 15:05

Wesley Long 44.6k15100159 · Answer 2 · 2016-04-22 04:57:59Z

Is your pride more important than your job?

Also, it's not "Your code," it's "The company's code."

The way you avoid this problem is constructively disagreeing. It seems like you disagreed to the point the other programmer went to the PM to get their input and then a decision was made without you. This suggests a fair bit of dysfunctionality on your team. My speculation is you are not someone who handles confrontation well (perhaps not, something to consider at least).

If you disagree, you should do the following:

Discuss with the team (as you and your coworker did not seem to do)

If you can't agree, escalate to a decision maker who can make the decision

Any ideas how to resolve this situation?

Go with what the PM said. Work to improve your relationships with both the PM and your coworker.

Much of work is doing things we don't want to do. Sometimes that means setting aside personal pride.

If you want bonus points here, try to address the problem proactively for the future. Talk with the PM and this coworker along the lines of, "how can we improve communication over subjects like this in the future? I felt like you went over my head and forced changes on me. Can we make a process to avoid this?" or something like this.

UPD I wasn't told about any problems on my side before this happened. These changes don't address any specific problems, it's just a "slight refactoring". The problem is that this refactoring is not small at all, and it breaks things.

If someone breaks things, then the normal response is to discuss with them:

"Hey, this refactor broke a bunch of things, we need to revert it until it addresses them"
- did you not have any tests?
- Do you have API versioning if this was another internal API

Make changes
- Review them (you do have code review?)

Address the concerns

Instead you could also approach this with the coworker and the PM, "hey this refactor you did caused X, Y, and Z to occur too. What is the plan to fix those and how can we prevent this from happening with future refactors?"

Another option is to talk with your manager and ask how they think you should proceed. If your manager is remotely competent they will ask what your efforts to resolve this situation have been.

Also, consider that you seem to not know why this change was made. Maybe it was to fix a bug somewhere else that was affecting customers. Maybe it's because they hate you. Who knows? Going to war over this without knowing that has some serious potential to make you look bad.

If you want to go quit because someone else made changes to your code, by all means do.

@XenoMind you realize your post reads like you are creating conflict over nothing, right? — Apr 21 '16 at 13:07
@XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team. — Apr 21 '16 at 13:28
@XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you. — Apr 21 '16 at 13:44
@Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows. — Apr 21 '16 at 14:02
@Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit. — Apr 21 '16 at 14:10

score 4 · Answer 3 · 2016-04-22 04:51:18Z

There are two things which need to be addressed in this situation:

1. Speak to the Project Manager

Do as many of these people have told you and go speak to the PM in person (and alone). Explain - in no uncertain terms - that the proposed changes have big implications. Make sure you get your say and express what the problems are.

Also ask the PM whether your colleague has received a promotion you were not aware of. I'm expecting the answer to be "No", which is when you get to ask why it is that it's this person and not the PM announcing you about decisions made without your input.

In other words I would call the PM out for going around your back and passing the buck on who told you about it.

2. Establish Boundaries

Go have a chat with your coworker. Tell him straight up that you won't be spoken to in that manner, or be bypassed in the decision making process when it's your project on the line.

If you don't establish boundaries and slap him down when he acts like a jerk then he's going to simply keep coming after you in the future.

I too have had to deal with a couple of workplace bullies in my (relatively short) career - one of them was a senior dev, the other a fellow programmer that had been there much longer than I. In both cases they felt that their seniority allowed them to ride over me and my opinions rough-shod (going as far as to tell me to "fuck off").

With people like these it is vitally important that you establish right away whether you're going to be the type to just take it and "let them win" (in their eyes you backing down is a win), or stand up to them.

In my own case both devs started to simply ignore or avoid me, which was fine by me. They never tried to meddle with my projects again either. When we had to interact we kept it short and professional, but neither of them dared to try and push me around again.

In my opinion you need to confront this fellow developer sooner rather than later.

Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line. — Apr 22 '16 at 0:33
Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom. — Apr 22 '16 at 6:10

ventsyv 1,243313 · Answer 4 · 2016-04-21 14:23:18Z

Send an email to him and the PM, including your co-workers original message and ask for a meeting. If you company's culture allows it, go ahead and schedule the meeting for a time convenient to all.

In your email, include that you were not aware that the design has been changed and that you have concerns that the new design could break A,B, and C.

Your PM will not be likely to ignore the issue if your concerns are presented in writing. Further, including the original rude email will probably make him sympathetic to your cause - nobody likes rude people.

At the meeting, present your arguments. Make sure your are civil and polite but make your case clearly.

In most cases a compromised will be reached and your coworker will probably be told to be more respectful.

+1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?" — Apr 22 '16 at 6:16

Kurt Tappe 73135 · Answer 5 · 2016-04-21 19:46:44Z

I want to stress something: You need to cover your *ss in writing. Compose an email (yes, email, not an IM that can go away) officially stating that 1) The code change was done by your colleague, 2) That it breaks the product, 3) That in your professional opinion the change should be reverted. You need to get all of this on the record now, because it sounds like poop will hit the fan and you will get blamed. Do not revert the code without permission. Just go on the record with the above info. Then you have performed due diligence.

EDIT: Also seriously consider 2A) The code was apparently not tested. In this day & age, you do not test in Production, you test in UAT/Dev. If your colleague had tested in Production where I work, he'd be in big trouble.

gnasher729 70.7k31131222 · Answer 6 · 2016-04-21 13:14:07Z

There are two possibilities: Either this programmer has bamboozled the PM into believing that he is the hottest programmer on earth, or he has done no such think and is just full of it. Either way, what he is doing is unacceptable: "Slight refactoring" and then messing it up (which means he committed changes without any code review, which is generally considered a deadly sin) is unacceptable.

No matter how elusive your PM is, you need to get hold of him and sort this out. Since your opponent isn't exactly a shrinking violet, your conversation should start with "xxx made some completely unnecessary changes and messed it up. He tells me that you agreed with this, without consulting anyone who actually knows the code base, which I find hard to believe. Is that true? "

Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it. — Apr 21 '16 at 13:17
If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work? — Apr 21 '16 at 13:32
Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"". — Apr 21 '16 at 14:15
No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff. — Apr 21 '16 at 14:25

score 1 · Answer 7 · 2016-04-22 13:59:38Z

All great opinions but I didn't hear anyone mention about this happening to them. I wanted to share I had this happen to me as well before. I would write code and submit, then a peer - who is not a manager - decided to meet with his manager to discuss changing my code. I discovered this and went to my boss who then agreed with the other and basically told me to deal with it. The peer's changes would break something or remove very key logic. My boss would accept it but then when it breaks would get upset at us even though we anticipated/voiced those concerns on the refactoring. Ultimately the key product was lost and the code was basically converted to legacy.

I eventually got into the idea that it's not my code, but theirs. I left it like that and ultimately decided to leave the company with this being one of many problems. I understand your frustration but ultimately it isn't your code but theirs. You can attempt to ask them if they can notify you when your code is changed, but ultimately it is about the culture of the place and deciding if that is something you want to accept. You shouldn't take it personally either.

"that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created. — Apr 23 '16 at 7:06

score 5 · Accepted Answer · 2016-04-21 17:35:25Z

I get you are getting beat up over this but I would consider quitting also.

In summary

Code you are responsible for

You had not been informed of any problems

Peer meets with PM over refactoring code you are responsible for

You are not included nor informed

According to peer an executive decision is made to refactor the code you are responsible for

You are not included in this decision

You are informed of the executive decision by peer not PM
At a minimum this executive decision should have come from the PM

The change is characterized as "slight refactoring"

In the opinion of the OP responsible for the code it is not slight and breaks a lot of stuff

This not proper. If you are responsible for the code then you deserve to be part of design decision. Even if you are shot down on every detail you should have a say. If they characterize as "slight refactoring" and you say it is not slight and breaks stuff then clearly there is a major disconnect. At a minimum they should explain to you how this "slight". Maybe you are missing something and maybe they are wrong. This is not how to manage a software team. This not how to manage software design.

You have couple problems:

Change is not minor

Process going forward

On the first I would outline in writing that the change is not minor. Outline how it effects the code overall and the stuff it would break. Ask for a meeting to discuss the matter.

On the second you need to have a heart to heart with the PM. Tell him straight up you think you deserve to be involved in design decisions regarding your code. If he tells you no I will make executive decision and may or may not include you then just tell him don't agree that is effective but you will follow orders. From there make a decision to suck it up look for another job. If the PM refuses to even have a process meeting with you then need to make a decision to suck it up or look for another job. Don't threaten to quit - nothing good would come from that. I personally would look for another job. I don't mind losing an architecture decision about code I am responsible for but I feel like I deserve to be part of the discussion.

Only a few weeks ago our test framework team broke my test running application by making upgrades. I had to refactor my app in order to get it working again. They did not realize their changes would significantly affect how others interacted with the system. Should I quit? — Apr 21 '16 at 14:56
@enderland You will need to make that decision for yourself. You should quit mis-characterizing. If you want to equate a test breaking code by making an upgrade to the OP's situation then so be it. I don't care to debate it with you. — Apr 21 '16 at 15:05

Wesley Long 44.6k15100159 · Answer 9 · 2016-04-22 04:57:59Z

Is your pride more important than your job?

Also, it's not "Your code," it's "The company's code."

The way you avoid this problem is constructively disagreeing. It seems like you disagreed to the point the other programmer went to the PM to get their input and then a decision was made without you. This suggests a fair bit of dysfunctionality on your team. My speculation is you are not someone who handles confrontation well (perhaps not, something to consider at least).

If you disagree, you should do the following:

Discuss with the team (as you and your coworker did not seem to do)

If you can't agree, escalate to a decision maker who can make the decision

Any ideas how to resolve this situation?

Go with what the PM said. Work to improve your relationships with both the PM and your coworker.

Much of work is doing things we don't want to do. Sometimes that means setting aside personal pride.

If you want bonus points here, try to address the problem proactively for the future. Talk with the PM and this coworker along the lines of, "how can we improve communication over subjects like this in the future? I felt like you went over my head and forced changes on me. Can we make a process to avoid this?" or something like this.

UPD I wasn't told about any problems on my side before this happened. These changes don't address any specific problems, it's just a "slight refactoring". The problem is that this refactoring is not small at all, and it breaks things.

If someone breaks things, then the normal response is to discuss with them:

"Hey, this refactor broke a bunch of things, we need to revert it until it addresses them"
- did you not have any tests?
- Do you have API versioning if this was another internal API

Make changes
- Review them (you do have code review?)

Address the concerns

Instead you could also approach this with the coworker and the PM, "hey this refactor you did caused X, Y, and Z to occur too. What is the plan to fix those and how can we prevent this from happening with future refactors?"

Another option is to talk with your manager and ask how they think you should proceed. If your manager is remotely competent they will ask what your efforts to resolve this situation have been.

Also, consider that you seem to not know why this change was made. Maybe it was to fix a bug somewhere else that was affecting customers. Maybe it's because they hate you. Who knows? Going to war over this without knowing that has some serious potential to make you look bad.

If you want to go quit because someone else made changes to your code, by all means do.

@XenoMind you realize your post reads like you are creating conflict over nothing, right? — Apr 21 '16 at 13:07
@XenoMind I've done that before too. It happens. Anyone who programs on a team will at some point break someone else's code. It's part of working on a team. — Apr 21 '16 at 13:28
@XenoMind shrug. Your mind is 100% made up that you are right and your coworker is clueless. You don't want to try to constructively address it with either your coworker or PM. You don't seem to want to try to understand why the coworker did this (only to bash him for being an idiot). You instead want to quit. I... guess I am not sure what to tell you. — Apr 21 '16 at 13:44
@Paparazzi you mean that he wants to quit because a coworker talked to the PM instead of talking to him? The coworker and PM are not saints here. But reacting and wanting to quit over something like this is not exactly reflective of a proper response. The proper response is to address the issue directly and carefully. It seems pretty obvious the OP is missing some context for how/why this happened - this could be that they are marginalized for some reason, the other coworker is just better in the PM's eyes, a hotfix bug fix, who knows. — Apr 21 '16 at 14:02
@Paparazzi according to the OP the following happened. 0) coworker made changes (for unknown reasons). 1) OP and coworker had conflict about these (we don't know what conflict means here since OP hasn't said, presumably a heated email exchange). 2) coworker responds that PM has said the coworkers changes are final. 3) OP writes post here asking if he should quit. — Apr 21 '16 at 14:10

score 4 · Answer 10 · 2016-04-22 04:51:18Z

There are two things which need to be addressed in this situation:

1. Speak to the Project Manager

Do as many of these people have told you and go speak to the PM in person (and alone). Explain - in no uncertain terms - that the proposed changes have big implications. Make sure you get your say and express what the problems are.

Also ask the PM whether your colleague has received a promotion you were not aware of. I'm expecting the answer to be "No", which is when you get to ask why it is that it's this person and not the PM announcing you about decisions made without your input.

In other words I would call the PM out for going around your back and passing the buck on who told you about it.

2. Establish Boundaries

Go have a chat with your coworker. Tell him straight up that you won't be spoken to in that manner, or be bypassed in the decision making process when it's your project on the line.

If you don't establish boundaries and slap him down when he acts like a jerk then he's going to simply keep coming after you in the future.

I too have had to deal with a couple of workplace bullies in my (relatively short) career - one of them was a senior dev, the other a fellow programmer that had been there much longer than I. In both cases they felt that their seniority allowed them to ride over me and my opinions rough-shod (going as far as to tell me to "fuck off").

With people like these it is vitally important that you establish right away whether you're going to be the type to just take it and "let them win" (in their eyes you backing down is a win), or stand up to them.

In my own case both devs started to simply ignore or avoid me, which was fine by me. They never tried to meddle with my projects again either. When we had to interact we kept it short and professional, but neither of them dared to try and push me around again.

In my opinion you need to confront this fellow developer sooner rather than later.

Mostly agree with this answer but I would definite recommend NOT using the phrase "..when it's your code". It's not your code. It is never your code when you are working as part of a team for an employer. Stick to not being bypassed in the decision-making process when a project that you are responsible for it on the line. — Apr 22 '16 at 0:33
Best answer of the lot, I particularly like the slap them down bit (although you probably didn't mean it physically). It's a personal issue this chap has with the OP (active dislike and no respect), the stated problem is just a symptom. — Apr 22 '16 at 6:10

ventsyv 1,243313 · Answer 11 · 2016-04-21 14:23:18Z

Send an email to him and the PM, including your co-workers original message and ask for a meeting. If you company's culture allows it, go ahead and schedule the meeting for a time convenient to all.

In your email, include that you were not aware that the design has been changed and that you have concerns that the new design could break A,B, and C.

Your PM will not be likely to ignore the issue if your concerns are presented in writing. Further, including the original rude email will probably make him sympathetic to your cause - nobody likes rude people.

At the meeting, present your arguments. Make sure your are civil and polite but make your case clearly.

In most cases a compromised will be reached and your coworker will probably be told to be more respectful.

+1 for forward it to boss... I would do the same with a short message "Hello boss, do I have to put up with crap like this?" — Apr 22 '16 at 6:16

Kurt Tappe 73135 · Answer 12 · 2016-04-21 19:46:44Z

I want to stress something: You need to cover your *ss in writing. Compose an email (yes, email, not an IM that can go away) officially stating that 1) The code change was done by your colleague, 2) That it breaks the product, 3) That in your professional opinion the change should be reverted. You need to get all of this on the record now, because it sounds like poop will hit the fan and you will get blamed. Do not revert the code without permission. Just go on the record with the above info. Then you have performed due diligence.

EDIT: Also seriously consider 2A) The code was apparently not tested. In this day & age, you do not test in Production, you test in UAT/Dev. If your colleague had tested in Production where I work, he'd be in big trouble.

gnasher729 70.7k31131222 · Answer 13 · 2016-04-21 13:14:07Z

There are two possibilities: Either this programmer has bamboozled the PM into believing that he is the hottest programmer on earth, or he has done no such think and is just full of it. Either way, what he is doing is unacceptable: "Slight refactoring" and then messing it up (which means he committed changes without any code review, which is generally considered a deadly sin) is unacceptable.

No matter how elusive your PM is, you need to get hold of him and sort this out. Since your opponent isn't exactly a shrinking violet, your conversation should start with "xxx made some completely unnecessary changes and messed it up. He tells me that you agreed with this, without consulting anyone who actually knows the code base, which I find hard to believe. Is that true? "

Normally I would agree, but considering the OP is ready to quit over this I don't know if such a direct approach is best. I'd be very surprised if this came out of nowhere without a lot of context surrounding it. — Apr 21 '16 at 13:17
If he is willing to quit over it, then there is nothing to lose and everything to gain. Does the PM know what's going on? Does he know there's a risk that he is left with a loose gun and nobody else to do the work? — Apr 21 '16 at 13:32
Well, it doesn't seem one of those situations. "These changes don't address any specific problems, it's just "slight refactoring"". — Apr 21 '16 at 14:15
No it is characterized as "slight refactoring" by those not responsible for the code. According to the person responsible for the code it breaks a lot of stuff. — Apr 21 '16 at 14:25

score 1 · Answer 14 · 2016-04-22 13:59:38Z

All great opinions but I didn't hear anyone mention about this happening to them. I wanted to share I had this happen to me as well before. I would write code and submit, then a peer - who is not a manager - decided to meet with his manager to discuss changing my code. I discovered this and went to my boss who then agreed with the other and basically told me to deal with it. The peer's changes would break something or remove very key logic. My boss would accept it but then when it breaks would get upset at us even though we anticipated/voiced those concerns on the refactoring. Ultimately the key product was lost and the code was basically converted to legacy.

I eventually got into the idea that it's not my code, but theirs. I left it like that and ultimately decided to leave the company with this being one of many problems. I understand your frustration but ultimately it isn't your code but theirs. You can attempt to ask them if they can notify you when your code is changed, but ultimately it is about the culture of the place and deciding if that is something you want to accept. You shouldn't take it personally either.

"that it's not my code, but theirs". That's a good idea. I'll try to talk the PM into transferring project responsibility to that guy, so that he will have to deal with the bugs that he created. — Apr 23 '16 at 7:06

Search This Blog

Iyfjky

â€œI'm the boss hereâ€ attitude from a peer [closed]

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

7 Answers
7

In summary

7 Answers
7

7 Answers
7

In summary

In summary

In summary

In summary

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

â€œI'm the boss hereâ€ attitude from a peer [closed]

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

closed as off-topic by gnat, Chris E, NotMe, Jim G., Masked Manâ™¦ Apr 22 '16 at 14:28

7 Answers 7

In summary

7 Answers 7

7 Answers 7

In summary

In summary

In summary

In summary

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

â€œI'm the boss hereâ€ attitude from a peer [closed]

7 Answers
7

7 Answers
7

7 Answers
7

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor