How to handle micromanaging coworker [closed]

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
1
down vote

favorite

I read another question on this site about dealing with a micromanaging coworker that got a pretty good answer, so I'm hoping someone can share their expertise and apply it to my circumstances.

I've been working here for almost two and a half years, and a few months ago was promoted to a higher position. I have one coworker who is quite good at what he does, and I respect him and his work. He's extremely detail-oriented, a bit OCD really, and while in general we could probably use a bit more detail-orientedness in this office, his detail-orientedness is definitely a bit much. He is self-aware, and will say things like "I'm sorry to micromanage you," and makes an effort to say something positive before giving me a big laundry list of changes he wants. I think he really struggles to cede control of something to someone else.

When I was promoted, I was more officially added to his team to lighten his workload. But, I really don't feel like I'm lightening his workload at all because he's just with me, every. step. of the way. Being right there over my shoulder (metaphorically, though occasionally literally.) Inserting his opinion on everything and making sure everything is done his way. And then at the end, once I've finally gone through nine drafts and gotten it approved by everyone, he'll just take my project anyway and re-edit it himself.

I find it incredibly frustrating. But I'm not good at confrontational discussions. Any tips on how to handle working with him?

Update: Thank you everyone for the advice. A couple of clarifications - it's video production, so in many cases there isn't a right or wrong way of doing things. Regarding if he's my manager - no he isn't, but he is sort of the team lead on this project (I think?). My work is divided between this project and another project where I'm the sole producer. The other guy on this project seems to be able to do all his videos mostly independently, so I should probably ask him how he managed to work out that arrangement with team leader-ish person.

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

asked Apr 28 '16 at 22:06

user49886

122

closed as off-topic by IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101 May 2 '16 at 0:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." â€“ IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101

If this question can be reworded to fit the rules in the help center, please edit the question.

1

Please link the relevant question and answer you mention.
â€“Â jpatokal
Apr 29 '16 at 1:25

Also, is this person just your coworker, or do they have some managerial authority over you? If the former, have you discussed this with your manager yet?
â€“Â jpatokal
Apr 29 '16 at 1:26

You need to clarify if this person is the team leader or if he's an equal.
â€“Â user41761
Apr 30 '16 at 1:43

A manager can be micromanaging you. A coworker can't. He can only try if you let him.
â€“Â gnasher729
May 6 '16 at 11:35

suggest improvementsÂ |Â

up vote
1
down vote

favorite

I read another question on this site about dealing with a micromanaging coworker that got a pretty good answer, so I'm hoping someone can share their expertise and apply it to my circumstances.

I find it incredibly frustrating. But I'm not good at confrontational discussions. Any tips on how to handle working with him?

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

asked Apr 28 '16 at 22:06

user49886

122

closed as off-topic by IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101 May 2 '16 at 0:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." â€“ IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101

If this question can be reworded to fit the rules in the help center, please edit the question.

1

Please link the relevant question and answer you mention.
â€“Â jpatokal
Apr 29 '16 at 1:25

Also, is this person just your coworker, or do they have some managerial authority over you? If the former, have you discussed this with your manager yet?
â€“Â jpatokal
Apr 29 '16 at 1:26

You need to clarify if this person is the team leader or if he's an equal.
â€“Â user41761
Apr 30 '16 at 1:43

A manager can be micromanaging you. A coworker can't. He can only try if you let him.
â€“Â gnasher729
May 6 '16 at 11:35

suggest improvementsÂ |Â

up vote
1
down vote

favorite

I read another question on this site about dealing with a micromanaging coworker that got a pretty good answer, so I'm hoping someone can share their expertise and apply it to my circumstances.

I find it incredibly frustrating. But I'm not good at confrontational discussions. Any tips on how to handle working with him?

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

asked Apr 28 '16 at 22:06

user49886

122

I read another question on this site about dealing with a micromanaging coworker that got a pretty good answer, so I'm hoping someone can share their expertise and apply it to my circumstances.

I find it incredibly frustrating. But I'm not good at confrontational discussions. Any tips on how to handle working with him?

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

asked Apr 28 '16 at 22:06

user49886

122

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

edited May 6 '16 at 11:14

Jan Doggen

11.5k145066

asked Apr 28 '16 at 22:06

user49886

122

asked Apr 28 '16 at 22:06

user49886

122

asked Apr 28 '16 at 22:06

user49886

122

closed as off-topic by IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101 May 2 '16 at 0:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." â€“ IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101

If this question can be reworded to fit the rules in the help center, please edit the question.

closed as off-topic by IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101 May 2 '16 at 0:55

This question appears to be off-topic. The users who voted to close gave this specific reason:

"Questions asking for advice on what to do are not practical answerable questions (e.g. "what job should I take?", or "what skills should I learn?"). Questions should get answers explaining why and how to make a decision, not advice on what to do. For more information, click here." â€“ IDrinkandIKnowThings, Dawny33, gnat, HopelessN00b, jimm101

If this question can be reworded to fit the rules in the help center, please edit the question.

1

Please link the relevant question and answer you mention.
â€“Â jpatokal
Apr 29 '16 at 1:25

Also, is this person just your coworker, or do they have some managerial authority over you? If the former, have you discussed this with your manager yet?
â€“Â jpatokal
Apr 29 '16 at 1:26

You need to clarify if this person is the team leader or if he's an equal.
â€“Â user41761
Apr 30 '16 at 1:43

A manager can be micromanaging you. A coworker can't. He can only try if you let him.
â€“Â gnasher729
May 6 '16 at 11:35

suggest improvementsÂ |Â

1

Please link the relevant question and answer you mention.
â€“Â jpatokal
Apr 29 '16 at 1:25

Also, is this person just your coworker, or do they have some managerial authority over you? If the former, have you discussed this with your manager yet?
â€“Â jpatokal
Apr 29 '16 at 1:26

You need to clarify if this person is the team leader or if he's an equal.
â€“Â user41761
Apr 30 '16 at 1:43

A manager can be micromanaging you. A coworker can't. He can only try if you let him.
â€“Â gnasher729
May 6 '16 at 11:35

Please link the relevant question and answer you mention.
â€“Â jpatokal
Apr 29 '16 at 1:25

Also, is this person just your coworker, or do they have some managerial authority over you? If the former, have you discussed this with your manager yet?
â€“Â jpatokal
Apr 29 '16 at 1:26

You need to clarify if this person is the team leader or if he's an equal.
â€“Â user41761
Apr 30 '16 at 1:43

A manager can be micromanaging you. A coworker can't. He can only try if you let him.
â€“Â gnasher729
May 6 '16 at 11:35

suggest improvementsÂ |Â

5 Answers
5

active

oldest

votes

up vote
7
down vote

I can imagine it is frustrating you. I had the same thing, but in my case this co-worker was much more senior than me. "It's okay, but if you just... " - and then he changed almost everything, and not even making it better, just different. While I really respected his authority and knowledge, I sometimes wondered why I was actually working on his project, when in the end almost everything was his work.

It took me a while, but then I actually felt confident enough to ask him about the changes. Why my way wasn't the right way. I figured maybe I could learn from his ideas. Most of the time, he just wanted it to look more like his style (I'm in software development). I made it clear to him that I don't want everything changed just because we have a different style of coding. Sometimes he had a good point about the way I solved issues and I actually learned a lot from him. And we're still friendly, although we both have a different job now.

So, my answer, I would evaluate which of these problems are better off with his approach and which ones are just as good, but different when he re-does your work. You can be a little protective of your work. You don't have to fight over this at all, it's not even a discussion. Just get your points across. Some changes you are okay with, some you aren't. Explain to him why you don't think his solution is really adding anything.

If he is the sole person responsible for the project, take extra care to make sure he 'understands' that your solution is just as good. It might be a hassle in the beginning but hopefully he will get that his way isn't the only way of getting things done.

edited Apr 29 '16 at 9:45

answered Apr 29 '16 at 9:09

Sabine

2,6252617

suggest improvementsÂ |Â

up vote
4
down vote

This is something you will likely need to get used to if you aren't in the business of ranking higher or worry about offending colleagues. If the latter doesn't apply, then in my experience people should be very responsive to an honest sit down, like: "Hey, can I talk to you privately?", and then later: "I appreciate your input, but...", and you generally just let the person know how you feel.

I'd then hope that he respects you enough that he will try to tone it down. This doesn't mean that the micro-managing will go away completely. You don't just erase a personality trait overnight!

Next time he comes to micro-manage you: pause in your task, smile and explain to him that you're 100% certain what you're doing. If he doesn't buy it, explain your protocol to a level of detail that makes him go away. You'll only need to do this a few times probably before you're left to yourself completely. There are other ways, but the key is to build other peoples' confidence in you.

IMO some good tips: Don't get frustrated. Understand the motivation behind the micro-managing: maybe he realistically just always has to baby other coworkers. Keep it professional, and the coworker should too.

answered Apr 28 '16 at 22:33

CKM

1,866311

suggest improvementsÂ |Â

up vote
4
down vote

You can't change him. This is just who he is, and he is not going to change to suit you. But unless he is your superior, you don't have to enable him (do everything he says) either. When he gives you a task, put in a good effort to do it well the first time, and give it back to him.

Then be a little bit of a brat. If he wants you to revise, accommodate him half the time (or less) on the first revision. The rest of the time simply say, "sorry, I've already moved on to my next task. However, it won't hurt my feelings if you want to make some improvements." You know that no matter how many times you revise it, he is going to redo it anyway, so who cares?

On additional (third, fourth) revisions, try to accommodate him infrequently to never. Let him do his thing. Stay cordial but firm, and move on.

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

2

you realise that this his team lead right? First time someone tried this with me I would have them manually checking data validity for a week.
â€“Â IDrinkandIKnowThings
Apr 29 '16 at 21:33

@Chad: question is unclear. When I first read, I interpreted "on his team," as they are peers on the same team. However, I can see how it could be interpreted as meaning that colleague is team lead. If so, I agree. A much gentler approach is required. I think he still needs to push back a little, but very gently and over time. And, indeed, realize that he may just have to accept his lead's quirks and realize leader may not change.
â€“Â MealyPotatoes
Apr 29 '16 at 22:41

-1 Avoiding confrontation like this is not professional. It is childish.
â€“Â Eric
Apr 30 '16 at 20:59

suggest improvementsÂ |Â

up vote
2
down vote

I'm quite fond of "the other side of the coin" answers, so I'm letting you know in advance that's what this is. Let's think about some reasons your coworker may be doing this:

He has more domain knowledge than you, and his way may set up better for future requirements. It's not always possible to explain why your gut tells you that doing something this way rather than that way is going to provide a better foundation for something you know is coming (or suspect might be coming given experience with a client/project manager), but that doesn't stop that gut feeling from being valid.

Your code may work, but have problems (tight coupling, unnecessary logic, other code smells) that shouldn't be allowed to continue in the code base. It doesn't lighten his load to let the code quality of the codebase to decline. Think of it this way: a new carpenter can meet the requirement to shut the light out of a room by nailing a board over the window, and the homeowner may be happy with that for a while. A more experienced carpenter won't wait for the homeowner to complain before taking down the board and installing shutters.

He may value consistency more than you do. If you and he are the only people to ever touch the codebase, it may not matter if you take different approaches to every task. However, as soon as you start training new people, it matters more--especially if each of them, in turn, just does things however they want.

He probably shares your feeling that you're not currently lightening his load. The only way to learn is to do, and he may hope that as he continues to show you the "right" way (as he sees it) that you may indeed be able to do that.

Maybe you're right. Maybe "your way" is perfectly fine. However, the reason you're on the project is to lighten his load, and as you've said, you're not doing that. It's possible that you can convince him that he should let you just go your own way using some of the other feedback. But it's also possible that you'd be more effective at lightening his load (whether "his way" is right or wrong) if you implement his suggestions to the best of your ability. When he rewrites your code, look at it really hard and see if you can figure out the common thread so that next time he doesn't have to.

The only exception I'd give to this is if "his way" is truly bad practice or will introduce long-term flaws into the project. If that is the case, I'd go with one of the other answers. But that didn't seem to be one of your concerns.

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

I agree, but the question makes it sound more like the frustration may be more around project artifacts than the code itself.
â€“Â Eric
Apr 30 '16 at 21:03

suggest improvementsÂ |Â

up vote
0
down vote

He'll never know you don't like it until you tell him. It is a bit confrontational, but this is what it is going to come to. Maybe you can have a casual discussion in some off time like first thing in the morning. These things are better discussed when you're not in the heat of the moment. If you don't want someone sitting over your shoulder while you work, don't start working until they leave. You shouldn't be forced to suffer because of his issues.

Set a time for him to come and review if you think it will benefit. If he comes before then, stop working and don't let him see your work. You make an agreement; he should stick to it. Continue to stretch these out over longer periods of time.

@MeatyPotatos has a good strategy to just let him make changes. It doesn't appear you have any control of what he does with your work afterwards. However, you need to have this discussion with your supervisor as well. You don't want him to think you aren't doing your part. Hopefully he'll understand.

answered Apr 29 '16 at 20:30

user8365

suggest improvementsÂ |Â

5 Answers
5

active

oldest

votes

5 Answers
5

active

oldest

votes

up vote
7
down vote

edited Apr 29 '16 at 9:45

answered Apr 29 '16 at 9:09

Sabine

2,6252617

suggest improvementsÂ |Â

up vote
7
down vote

edited Apr 29 '16 at 9:45

answered Apr 29 '16 at 9:09

Sabine

2,6252617

suggest improvementsÂ |Â

up vote
7
down vote

edited Apr 29 '16 at 9:45

answered Apr 29 '16 at 9:09

Sabine

2,6252617

edited Apr 29 '16 at 9:45

answered Apr 29 '16 at 9:09

Sabine

2,6252617

edited Apr 29 '16 at 9:45

answered Apr 29 '16 at 9:09

Sabine

2,6252617

answered Apr 29 '16 at 9:09

Sabine

2,6252617

answered Apr 29 '16 at 9:09

Sabine

2,6252617

suggest improvementsÂ |Â

up vote
4
down vote

I'd then hope that he respects you enough that he will try to tone it down. This doesn't mean that the micro-managing will go away completely. You don't just erase a personality trait overnight!

answered Apr 28 '16 at 22:33

CKM

1,866311

suggest improvementsÂ |Â

up vote
4
down vote

I'd then hope that he respects you enough that he will try to tone it down. This doesn't mean that the micro-managing will go away completely. You don't just erase a personality trait overnight!

answered Apr 28 '16 at 22:33

CKM

1,866311

suggest improvementsÂ |Â

up vote
4
down vote

I'd then hope that he respects you enough that he will try to tone it down. This doesn't mean that the micro-managing will go away completely. You don't just erase a personality trait overnight!

answered Apr 28 '16 at 22:33

CKM

1,866311

I'd then hope that he respects you enough that he will try to tone it down. This doesn't mean that the micro-managing will go away completely. You don't just erase a personality trait overnight!

answered Apr 28 '16 at 22:33

CKM

1,866311

answered Apr 28 '16 at 22:33

CKM

1,866311

answered Apr 28 '16 at 22:33

CKM

1,866311

answered Apr 28 '16 at 22:33

CKM

1,866311

suggest improvementsÂ |Â

up vote
4
down vote

On additional (third, fourth) revisions, try to accommodate him infrequently to never. Let him do his thing. Stay cordial but firm, and move on.

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

2

you realise that this his team lead right? First time someone tried this with me I would have them manually checking data validity for a week.
â€“Â IDrinkandIKnowThings
Apr 29 '16 at 21:33

@Chad: question is unclear. When I first read, I interpreted "on his team," as they are peers on the same team. However, I can see how it could be interpreted as meaning that colleague is team lead. If so, I agree. A much gentler approach is required. I think he still needs to push back a little, but very gently and over time. And, indeed, realize that he may just have to accept his lead's quirks and realize leader may not change.
â€“Â MealyPotatoes
Apr 29 '16 at 22:41

-1 Avoiding confrontation like this is not professional. It is childish.
â€“Â Eric
Apr 30 '16 at 20:59

suggest improvementsÂ |Â

up vote
4
down vote

On additional (third, fourth) revisions, try to accommodate him infrequently to never. Let him do his thing. Stay cordial but firm, and move on.

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

2

you realise that this his team lead right? First time someone tried this with me I would have them manually checking data validity for a week.
â€“Â IDrinkandIKnowThings
Apr 29 '16 at 21:33

@Chad: question is unclear. When I first read, I interpreted "on his team," as they are peers on the same team. However, I can see how it could be interpreted as meaning that colleague is team lead. If so, I agree. A much gentler approach is required. I think he still needs to push back a little, but very gently and over time. And, indeed, realize that he may just have to accept his lead's quirks and realize leader may not change.
â€“Â MealyPotatoes
Apr 29 '16 at 22:41

-1 Avoiding confrontation like this is not professional. It is childish.
â€“Â Eric
Apr 30 '16 at 20:59

suggest improvementsÂ |Â

up vote
4
down vote

On additional (third, fourth) revisions, try to accommodate him infrequently to never. Let him do his thing. Stay cordial but firm, and move on.

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

On additional (third, fourth) revisions, try to accommodate him infrequently to never. Let him do his thing. Stay cordial but firm, and move on.

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

answered Apr 28 '16 at 22:35

MealyPotatoes

4,76621220

2

you realise that this his team lead right? First time someone tried this with me I would have them manually checking data validity for a week.
â€“Â IDrinkandIKnowThings
Apr 29 '16 at 21:33

@Chad: question is unclear. When I first read, I interpreted "on his team," as they are peers on the same team. However, I can see how it could be interpreted as meaning that colleague is team lead. If so, I agree. A much gentler approach is required. I think he still needs to push back a little, but very gently and over time. And, indeed, realize that he may just have to accept his lead's quirks and realize leader may not change.
â€“Â MealyPotatoes
Apr 29 '16 at 22:41

-1 Avoiding confrontation like this is not professional. It is childish.
â€“Â Eric
Apr 30 '16 at 20:59

suggest improvementsÂ |Â

2

you realise that this his team lead right? First time someone tried this with me I would have them manually checking data validity for a week.
â€“Â IDrinkandIKnowThings
Apr 29 '16 at 21:33

@Chad: question is unclear. When I first read, I interpreted "on his team," as they are peers on the same team. However, I can see how it could be interpreted as meaning that colleague is team lead. If so, I agree. A much gentler approach is required. I think he still needs to push back a little, but very gently and over time. And, indeed, realize that he may just have to accept his lead's quirks and realize leader may not change.
â€“Â MealyPotatoes
Apr 29 '16 at 22:41

-1 Avoiding confrontation like this is not professional. It is childish.
â€“Â Eric
Apr 30 '16 at 20:59

you realise that this his team lead right? First time someone tried this with me I would have them manually checking data validity for a week.
â€“Â IDrinkandIKnowThings
Apr 29 '16 at 21:33

@Chad: question is unclear. When I first read, I interpreted "on his team," as they are peers on the same team. However, I can see how it could be interpreted as meaning that colleague is team lead. If so, I agree. A much gentler approach is required. I think he still needs to push back a little, but very gently and over time. And, indeed, realize that he may just have to accept his lead's quirks and realize leader may not change.
â€“Â MealyPotatoes
Apr 29 '16 at 22:41

-1 Avoiding confrontation like this is not professional. It is childish.
â€“Â Eric
Apr 30 '16 at 20:59

suggest improvementsÂ |Â

up vote
2
down vote

I'm quite fond of "the other side of the coin" answers, so I'm letting you know in advance that's what this is. Let's think about some reasons your coworker may be doing this:

He has more domain knowledge than you, and his way may set up better for future requirements. It's not always possible to explain why your gut tells you that doing something this way rather than that way is going to provide a better foundation for something you know is coming (or suspect might be coming given experience with a client/project manager), but that doesn't stop that gut feeling from being valid.

Your code may work, but have problems (tight coupling, unnecessary logic, other code smells) that shouldn't be allowed to continue in the code base. It doesn't lighten his load to let the code quality of the codebase to decline. Think of it this way: a new carpenter can meet the requirement to shut the light out of a room by nailing a board over the window, and the homeowner may be happy with that for a while. A more experienced carpenter won't wait for the homeowner to complain before taking down the board and installing shutters.

He may value consistency more than you do. If you and he are the only people to ever touch the codebase, it may not matter if you take different approaches to every task. However, as soon as you start training new people, it matters more--especially if each of them, in turn, just does things however they want.

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

I agree, but the question makes it sound more like the frustration may be more around project artifacts than the code itself.
â€“Â Eric
Apr 30 '16 at 21:03

suggest improvementsÂ |Â

up vote
2
down vote

I'm quite fond of "the other side of the coin" answers, so I'm letting you know in advance that's what this is. Let's think about some reasons your coworker may be doing this:

He has more domain knowledge than you, and his way may set up better for future requirements. It's not always possible to explain why your gut tells you that doing something this way rather than that way is going to provide a better foundation for something you know is coming (or suspect might be coming given experience with a client/project manager), but that doesn't stop that gut feeling from being valid.

Your code may work, but have problems (tight coupling, unnecessary logic, other code smells) that shouldn't be allowed to continue in the code base. It doesn't lighten his load to let the code quality of the codebase to decline. Think of it this way: a new carpenter can meet the requirement to shut the light out of a room by nailing a board over the window, and the homeowner may be happy with that for a while. A more experienced carpenter won't wait for the homeowner to complain before taking down the board and installing shutters.

He may value consistency more than you do. If you and he are the only people to ever touch the codebase, it may not matter if you take different approaches to every task. However, as soon as you start training new people, it matters more--especially if each of them, in turn, just does things however they want.

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

I agree, but the question makes it sound more like the frustration may be more around project artifacts than the code itself.
â€“Â Eric
Apr 30 '16 at 21:03

suggest improvementsÂ |Â

up vote
2
down vote

I'm quite fond of "the other side of the coin" answers, so I'm letting you know in advance that's what this is. Let's think about some reasons your coworker may be doing this:

He has more domain knowledge than you, and his way may set up better for future requirements. It's not always possible to explain why your gut tells you that doing something this way rather than that way is going to provide a better foundation for something you know is coming (or suspect might be coming given experience with a client/project manager), but that doesn't stop that gut feeling from being valid.

Your code may work, but have problems (tight coupling, unnecessary logic, other code smells) that shouldn't be allowed to continue in the code base. It doesn't lighten his load to let the code quality of the codebase to decline. Think of it this way: a new carpenter can meet the requirement to shut the light out of a room by nailing a board over the window, and the homeowner may be happy with that for a while. A more experienced carpenter won't wait for the homeowner to complain before taking down the board and installing shutters.

He may value consistency more than you do. If you and he are the only people to ever touch the codebase, it may not matter if you take different approaches to every task. However, as soon as you start training new people, it matters more--especially if each of them, in turn, just does things however they want.

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

I'm quite fond of "the other side of the coin" answers, so I'm letting you know in advance that's what this is. Let's think about some reasons your coworker may be doing this:

He has more domain knowledge than you, and his way may set up better for future requirements. It's not always possible to explain why your gut tells you that doing something this way rather than that way is going to provide a better foundation for something you know is coming (or suspect might be coming given experience with a client/project manager), but that doesn't stop that gut feeling from being valid.

Your code may work, but have problems (tight coupling, unnecessary logic, other code smells) that shouldn't be allowed to continue in the code base. It doesn't lighten his load to let the code quality of the codebase to decline. Think of it this way: a new carpenter can meet the requirement to shut the light out of a room by nailing a board over the window, and the homeowner may be happy with that for a while. A more experienced carpenter won't wait for the homeowner to complain before taking down the board and installing shutters.

He may value consistency more than you do. If you and he are the only people to ever touch the codebase, it may not matter if you take different approaches to every task. However, as soon as you start training new people, it matters more--especially if each of them, in turn, just does things however they want.

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

answered Apr 29 '16 at 17:34

Amy Blankenship

7,13711836

I agree, but the question makes it sound more like the frustration may be more around project artifacts than the code itself.
â€“Â Eric
Apr 30 '16 at 21:03

suggest improvementsÂ |Â

I agree, but the question makes it sound more like the frustration may be more around project artifacts than the code itself.
â€“Â Eric
Apr 30 '16 at 21:03

I agree, but the question makes it sound more like the frustration may be more around project artifacts than the code itself.
â€“Â Eric
Apr 30 '16 at 21:03

suggest improvementsÂ |Â

up vote
0
down vote

answered Apr 29 '16 at 20:30

user8365

suggest improvementsÂ |Â

up vote
0
down vote

answered Apr 29 '16 at 20:30

user8365

suggest improvementsÂ |Â

up vote
0
down vote

answered Apr 29 '16 at 20:30

user8365

answered Apr 29 '16 at 20:30

user8365

answered Apr 29 '16 at 20:30

user8365

answered Apr 29 '16 at 20:30

user8365

answered Apr 29 '16 at 20:30

user8365

suggest improvementsÂ |Â

Search This Blog

Iyfjky