Mixing
![Is it a problem that I am never considered for new opportunities at work? [closed]](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjbpfN9tAutmK93bJRC3ZoROZzi2TJDms5n8_qJuhgE0a9b52OOHayv3NGT8igAdFL7byXNst-_1DZK5SjrIJ28_6RQPUpBROqMs5s6jo-ZsjX8kjDwfxJufIitH3TaQRXWaGSQKRQib-f/s72-c/1.jpg)
How do I correct something a colleague did wrong without going over his head?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
I'm currently working in a project with 3 other developers. One of them isn't really experienced with one of the technologies we are using (an ORM), but he is higher in the hierarchy and doesn't take criticism well, specially from those below him in the ranks (like myself).
He is unhappy with how the technology is supposed to work and is setting up all kinds of workarounds to not use the tool the way it's meant to be used.
I can see how those workarounds are going to be harmful to the project in the long term, I have already told him, but he simply disagreed, said I'm wrong and continued on doing it.
I have thought about just waiting for him to push the code to the repository and then changing it anyway, but I don't want to go around him like that. I have considered going to the manager and telling him what's happening, but I don't want to be that guy. In all honesty, I am currently thinking about doing something I hate -- saving the chat logs to prove I objected and letting things take its course. I know it's going to harm the project, but all other options seem to harm me.
What is worse? To be unprofessional and let the project be negatively affected or to be professional and be hated by my colleague(s)? He is going to hate me if I either change what he did (after he explicitly rejected my corrections) or tell the manager on him.
Edit: Some people are skeptical, apparently. Dude's using an ORM (Doctrine2), which has a few limitations concerning multi-level inheritance. All 'leafs' have to be in the top-most class DiscriminatorMap, and therefore their IDs are FKs that points to the top-most class in the hierarchy, not to the class' imediate parents. He figured it's more important to have leafs pointing to their parents and keep the mapping wrong (he doesn't agree that an ORM's job is to handle the database, he wants to do it manually -- "no, this way the database will be wrong"). Obviously, having a broken mapping broke some of Doctrine's repositories native functions (such as findOneBy). His solution was to keep the broken mapping and override Doctrine's native functions to "fix" the issue. This is absolutely insane.
professionalism colleagues employer-relations
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
 |Â
show 2 more comments
up vote
0
down vote
favorite
I'm currently working in a project with 3 other developers. One of them isn't really experienced with one of the technologies we are using (an ORM), but he is higher in the hierarchy and doesn't take criticism well, specially from those below him in the ranks (like myself).
He is unhappy with how the technology is supposed to work and is setting up all kinds of workarounds to not use the tool the way it's meant to be used.
I can see how those workarounds are going to be harmful to the project in the long term, I have already told him, but he simply disagreed, said I'm wrong and continued on doing it.
I have thought about just waiting for him to push the code to the repository and then changing it anyway, but I don't want to go around him like that. I have considered going to the manager and telling him what's happening, but I don't want to be that guy. In all honesty, I am currently thinking about doing something I hate -- saving the chat logs to prove I objected and letting things take its course. I know it's going to harm the project, but all other options seem to harm me.
What is worse? To be unprofessional and let the project be negatively affected or to be professional and be hated by my colleague(s)? He is going to hate me if I either change what he did (after he explicitly rejected my corrections) or tell the manager on him.
Edit: Some people are skeptical, apparently. Dude's using an ORM (Doctrine2), which has a few limitations concerning multi-level inheritance. All 'leafs' have to be in the top-most class DiscriminatorMap, and therefore their IDs are FKs that points to the top-most class in the hierarchy, not to the class' imediate parents. He figured it's more important to have leafs pointing to their parents and keep the mapping wrong (he doesn't agree that an ORM's job is to handle the database, he wants to do it manually -- "no, this way the database will be wrong"). Obviously, having a broken mapping broke some of Doctrine's repositories native functions (such as findOneBy). His solution was to keep the broken mapping and override Doctrine's native functions to "fix" the issue. This is absolutely insane.
professionalism colleagues employer-relations
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
What is your position compared to the other 3 developers? If you are the team lead it is different than if you are their peer.
– IDrinkandIKnowThings
Sep 10 '13 at 14:06
I think that the question might be better if you present it as I think X dev B did Y how should I communicate that Y is the wrong way.
– IDrinkandIKnowThings
Sep 10 '13 at 14:16
You might find this answer worth reading. This question really reads like, "my colleague is an idiot."
– Elysian Fields♦
Sep 10 '13 at 14:23
@Chad, I'm not a team leader, I'm just a developer.
– Pedro Cordeiro
Sep 10 '13 at 14:37
@enderland, I don't know how you got that from my question. I just said he doesn't handle criticism well and is not experienced with the tool at hand.
– Pedro Cordeiro
Sep 10 '13 at 14:38
 |Â
show 2 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm currently working in a project with 3 other developers. One of them isn't really experienced with one of the technologies we are using (an ORM), but he is higher in the hierarchy and doesn't take criticism well, specially from those below him in the ranks (like myself).
He is unhappy with how the technology is supposed to work and is setting up all kinds of workarounds to not use the tool the way it's meant to be used.
I can see how those workarounds are going to be harmful to the project in the long term, I have already told him, but he simply disagreed, said I'm wrong and continued on doing it.
I have thought about just waiting for him to push the code to the repository and then changing it anyway, but I don't want to go around him like that. I have considered going to the manager and telling him what's happening, but I don't want to be that guy. In all honesty, I am currently thinking about doing something I hate -- saving the chat logs to prove I objected and letting things take its course. I know it's going to harm the project, but all other options seem to harm me.
What is worse? To be unprofessional and let the project be negatively affected or to be professional and be hated by my colleague(s)? He is going to hate me if I either change what he did (after he explicitly rejected my corrections) or tell the manager on him.
Edit: Some people are skeptical, apparently. Dude's using an ORM (Doctrine2), which has a few limitations concerning multi-level inheritance. All 'leafs' have to be in the top-most class DiscriminatorMap, and therefore their IDs are FKs that points to the top-most class in the hierarchy, not to the class' imediate parents. He figured it's more important to have leafs pointing to their parents and keep the mapping wrong (he doesn't agree that an ORM's job is to handle the database, he wants to do it manually -- "no, this way the database will be wrong"). Obviously, having a broken mapping broke some of Doctrine's repositories native functions (such as findOneBy). His solution was to keep the broken mapping and override Doctrine's native functions to "fix" the issue. This is absolutely insane.
professionalism colleagues employer-relations
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
I'm currently working in a project with 3 other developers. One of them isn't really experienced with one of the technologies we are using (an ORM), but he is higher in the hierarchy and doesn't take criticism well, specially from those below him in the ranks (like myself).
He is unhappy with how the technology is supposed to work and is setting up all kinds of workarounds to not use the tool the way it's meant to be used.
I can see how those workarounds are going to be harmful to the project in the long term, I have already told him, but he simply disagreed, said I'm wrong and continued on doing it.
I have thought about just waiting for him to push the code to the repository and then changing it anyway, but I don't want to go around him like that. I have considered going to the manager and telling him what's happening, but I don't want to be that guy. In all honesty, I am currently thinking about doing something I hate -- saving the chat logs to prove I objected and letting things take its course. I know it's going to harm the project, but all other options seem to harm me.
What is worse? To be unprofessional and let the project be negatively affected or to be professional and be hated by my colleague(s)? He is going to hate me if I either change what he did (after he explicitly rejected my corrections) or tell the manager on him.
Edit: Some people are skeptical, apparently. Dude's using an ORM (Doctrine2), which has a few limitations concerning multi-level inheritance. All 'leafs' have to be in the top-most class DiscriminatorMap, and therefore their IDs are FKs that points to the top-most class in the hierarchy, not to the class' imediate parents. He figured it's more important to have leafs pointing to their parents and keep the mapping wrong (he doesn't agree that an ORM's job is to handle the database, he wants to do it manually -- "no, this way the database will be wrong"). Obviously, having a broken mapping broke some of Doctrine's repositories native functions (such as findOneBy). His solution was to keep the broken mapping and override Doctrine's native functions to "fix" the issue. This is absolutely insane.
professionalism colleagues employer-relations
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
edited Sep 11 '13 at 11:19
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
asked Sep 10 '13 at 13:56
Pedro Cordeiro
493613
493613
What is your position compared to the other 3 developers? If you are the team lead it is different than if you are their peer.
– IDrinkandIKnowThings
Sep 10 '13 at 14:06
I think that the question might be better if you present it as I think X dev B did Y how should I communicate that Y is the wrong way.
– IDrinkandIKnowThings
Sep 10 '13 at 14:16
You might find this answer worth reading. This question really reads like, "my colleague is an idiot."
– Elysian Fields♦
Sep 10 '13 at 14:23
@Chad, I'm not a team leader, I'm just a developer.
– Pedro Cordeiro
Sep 10 '13 at 14:37
@enderland, I don't know how you got that from my question. I just said he doesn't handle criticism well and is not experienced with the tool at hand.
– Pedro Cordeiro
Sep 10 '13 at 14:38
 |Â
show 2 more comments
What is your position compared to the other 3 developers? If you are the team lead it is different than if you are their peer.
– IDrinkandIKnowThings
Sep 10 '13 at 14:06
I think that the question might be better if you present it as I think X dev B did Y how should I communicate that Y is the wrong way.
– IDrinkandIKnowThings
Sep 10 '13 at 14:16
You might find this answer worth reading. This question really reads like, "my colleague is an idiot."
– Elysian Fields♦
Sep 10 '13 at 14:23
@Chad, I'm not a team leader, I'm just a developer.
– Pedro Cordeiro
Sep 10 '13 at 14:37
@enderland, I don't know how you got that from my question. I just said he doesn't handle criticism well and is not experienced with the tool at hand.
– Pedro Cordeiro
Sep 10 '13 at 14:38
What is your position compared to the other 3 developers? If you are the team lead it is different than if you are their peer.
– IDrinkandIKnowThings
Sep 10 '13 at 14:06
What is your position compared to the other 3 developers? If you are the team lead it is different than if you are their peer.
– IDrinkandIKnowThings
Sep 10 '13 at 14:06
I think that the question might be better if you present it as I think X dev B did Y how should I communicate that Y is the wrong way.
– IDrinkandIKnowThings
Sep 10 '13 at 14:16
I think that the question might be better if you present it as I think X dev B did Y how should I communicate that Y is the wrong way.
– IDrinkandIKnowThings
Sep 10 '13 at 14:16
You might find this answer worth reading. This question really reads like, "my colleague is an idiot."
– Elysian Fields♦
Sep 10 '13 at 14:23
You might find this answer worth reading. This question really reads like, "my colleague is an idiot."
– Elysian Fields♦
Sep 10 '13 at 14:23
@Chad, I'm not a team leader, I'm just a developer.
– Pedro Cordeiro
Sep 10 '13 at 14:37
@Chad, I'm not a team leader, I'm just a developer.
– Pedro Cordeiro
Sep 10 '13 at 14:37
@enderland, I don't know how you got that from my question. I just said he doesn't handle criticism well and is not experienced with the tool at hand.
– Pedro Cordeiro
Sep 10 '13 at 14:38
@enderland, I don't know how you got that from my question. I just said he doesn't handle criticism well and is not experienced with the tool at hand.
– Pedro Cordeiro
Sep 10 '13 at 14:38
 |Â
show 2 more comments
3 Answers
3
active
oldest
votes
up vote
10
down vote
In general, you simply need to do your job.
If you job is reviewing the work of others on your team (perhaps through a formal code review), then you need to review it, present your findings, and live with the consequences.
If your job is not to review the work of others, then you need to let it go.
Often, there are many roads leading to "good enough" in the software world. While your colleague's approach may be different than yours (and may or may not be "wrong"), the approach he chooses may be outside your control. If so, let it go and move on with whatever work is really your job.
The exception here is if someone is making a critical mistake that will potentially harm others physically, or financially. In that case, you should consider being the whistleblower, talking with the manager, and accepting the consequences (ostracism from your colleagues, etc). If you take that route, make sure you are right in your conclusion, and make sure that the risk of remaining silent is too high.
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
1
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
add a comment |Â
up vote
2
down vote
In addition to what Joe Strazzere answered, if you feel so passionately about using your favorite ORM correctly, how about taking a use case and showing your co worker how things can get blown ? And if things are moving smoothly teach the guy how to use the thing.
One of the most important things that you can do IMO - You can point out the issues you foresee in code review meetings and propose solutions for it.Obviously if other reviewers don't see the problem, you have to be ready with a use case for problems you see. I know from ORM experience that if you don't do it right, it can be the single most traumatic thing to debug/fix. Right from application response time to corrupt data.
As a developer, end of the day, my top most priority is the well being of the application/project am working on writing efficient code that performs at its peak and doesn't break. That is what I am paid to do and that is my top most interest at work.
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
add a comment |Â
up vote
2
down vote
You will need to lay out a good argument on paper of why using the ORM the way it is intended will be better. This needs to specify the immediate benefits, and the long term benefits. You also need to address every one of his concerns he has about letting the ORM do it the way it was intended to work. You need to put at ease his fears, this is why he is changing it. If you can write all of these things down in an organized fashion, and go over it in a meeting with the other two developers, then you may have a shot at convincing him of your approach.
Make sure you include that you've worked with this technology before. Elaborate on how you used it correctly, and no issues arised. Also, show him that the developer community around this tool highly encourages you to let the ORM do it's magic.
answered Sep 11 '13 at 16:04
aglassman
24615
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();
);
);
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
In general, you simply need to do your job.
If you job is reviewing the work of others on your team (perhaps through a formal code review), then you need to review it, present your findings, and live with the consequences.
If your job is not to review the work of others, then you need to let it go.
Often, there are many roads leading to "good enough" in the software world. While your colleague's approach may be different than yours (and may or may not be "wrong"), the approach he chooses may be outside your control. If so, let it go and move on with whatever work is really your job.
The exception here is if someone is making a critical mistake that will potentially harm others physically, or financially. In that case, you should consider being the whistleblower, talking with the manager, and accepting the consequences (ostracism from your colleagues, etc). If you take that route, make sure you are right in your conclusion, and make sure that the risk of remaining silent is too high.
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
1
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
add a comment |Â
up vote
10
down vote
In general, you simply need to do your job.
If you job is reviewing the work of others on your team (perhaps through a formal code review), then you need to review it, present your findings, and live with the consequences.
If your job is not to review the work of others, then you need to let it go.
Often, there are many roads leading to "good enough" in the software world. While your colleague's approach may be different than yours (and may or may not be "wrong"), the approach he chooses may be outside your control. If so, let it go and move on with whatever work is really your job.
The exception here is if someone is making a critical mistake that will potentially harm others physically, or financially. In that case, you should consider being the whistleblower, talking with the manager, and accepting the consequences (ostracism from your colleagues, etc). If you take that route, make sure you are right in your conclusion, and make sure that the risk of remaining silent is too high.
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
1
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
add a comment |Â
up vote
10
down vote
up vote
10
down vote
In general, you simply need to do your job.
If you job is reviewing the work of others on your team (perhaps through a formal code review), then you need to review it, present your findings, and live with the consequences.
If your job is not to review the work of others, then you need to let it go.
Often, there are many roads leading to "good enough" in the software world. While your colleague's approach may be different than yours (and may or may not be "wrong"), the approach he chooses may be outside your control. If so, let it go and move on with whatever work is really your job.
The exception here is if someone is making a critical mistake that will potentially harm others physically, or financially. In that case, you should consider being the whistleblower, talking with the manager, and accepting the consequences (ostracism from your colleagues, etc). If you take that route, make sure you are right in your conclusion, and make sure that the risk of remaining silent is too high.
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
In general, you simply need to do your job.
If you job is reviewing the work of others on your team (perhaps through a formal code review), then you need to review it, present your findings, and live with the consequences.
If your job is not to review the work of others, then you need to let it go.
Often, there are many roads leading to "good enough" in the software world. While your colleague's approach may be different than yours (and may or may not be "wrong"), the approach he chooses may be outside your control. If so, let it go and move on with whatever work is really your job.
The exception here is if someone is making a critical mistake that will potentially harm others physically, or financially. In that case, you should consider being the whistleblower, talking with the manager, and accepting the consequences (ostracism from your colleagues, etc). If you take that route, make sure you are right in your conclusion, and make sure that the risk of remaining silent is too high.
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
answered Sep 10 '13 at 15:43
Joe Strazzere
224k107661930
224k107661930
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
1
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
add a comment |Â
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
1
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
+1 - and based on the edit, I'd be inclined to agree with your lead to some degree. Having members reference some global root rather their direct parents seems odd and dangerous.
– Telastyn
Sep 11 '13 at 15:29
1
1
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
I agree that "good enough" does usually end up being the result in a lot of projects. The big issue is of course maintainability. If someone else comes along in 5 years, they are going to have a heck of a time figuring out what the heck the original developers did since it was not in line with the ORM's documentation. So while bad coding practices may not impact others physically or financially, it could break them mentally!
– aglassman
Sep 11 '13 at 16:09
add a comment |Â
up vote
2
down vote
In addition to what Joe Strazzere answered, if you feel so passionately about using your favorite ORM correctly, how about taking a use case and showing your co worker how things can get blown ? And if things are moving smoothly teach the guy how to use the thing.
One of the most important things that you can do IMO - You can point out the issues you foresee in code review meetings and propose solutions for it.Obviously if other reviewers don't see the problem, you have to be ready with a use case for problems you see. I know from ORM experience that if you don't do it right, it can be the single most traumatic thing to debug/fix. Right from application response time to corrupt data.
As a developer, end of the day, my top most priority is the well being of the application/project am working on writing efficient code that performs at its peak and doesn't break. That is what I am paid to do and that is my top most interest at work.
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
add a comment |Â
up vote
2
down vote
In addition to what Joe Strazzere answered, if you feel so passionately about using your favorite ORM correctly, how about taking a use case and showing your co worker how things can get blown ? And if things are moving smoothly teach the guy how to use the thing.
One of the most important things that you can do IMO - You can point out the issues you foresee in code review meetings and propose solutions for it.Obviously if other reviewers don't see the problem, you have to be ready with a use case for problems you see. I know from ORM experience that if you don't do it right, it can be the single most traumatic thing to debug/fix. Right from application response time to corrupt data.
As a developer, end of the day, my top most priority is the well being of the application/project am working on writing efficient code that performs at its peak and doesn't break. That is what I am paid to do and that is my top most interest at work.
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
add a comment |Â
up vote
2
down vote
up vote
2
down vote
In addition to what Joe Strazzere answered, if you feel so passionately about using your favorite ORM correctly, how about taking a use case and showing your co worker how things can get blown ? And if things are moving smoothly teach the guy how to use the thing.
One of the most important things that you can do IMO - You can point out the issues you foresee in code review meetings and propose solutions for it.Obviously if other reviewers don't see the problem, you have to be ready with a use case for problems you see. I know from ORM experience that if you don't do it right, it can be the single most traumatic thing to debug/fix. Right from application response time to corrupt data.
As a developer, end of the day, my top most priority is the well being of the application/project am working on writing efficient code that performs at its peak and doesn't break. That is what I am paid to do and that is my top most interest at work.
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
In addition to what Joe Strazzere answered, if you feel so passionately about using your favorite ORM correctly, how about taking a use case and showing your co worker how things can get blown ? And if things are moving smoothly teach the guy how to use the thing.
One of the most important things that you can do IMO - You can point out the issues you foresee in code review meetings and propose solutions for it.Obviously if other reviewers don't see the problem, you have to be ready with a use case for problems you see. I know from ORM experience that if you don't do it right, it can be the single most traumatic thing to debug/fix. Right from application response time to corrupt data.
As a developer, end of the day, my top most priority is the well being of the application/project am working on writing efficient code that performs at its peak and doesn't break. That is what I am paid to do and that is my top most interest at work.
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
answered Sep 11 '13 at 15:20
happybuddha
4,31152752
4,31152752
add a comment |Â
add a comment |Â
up vote
2
down vote
You will need to lay out a good argument on paper of why using the ORM the way it is intended will be better. This needs to specify the immediate benefits, and the long term benefits. You also need to address every one of his concerns he has about letting the ORM do it the way it was intended to work. You need to put at ease his fears, this is why he is changing it. If you can write all of these things down in an organized fashion, and go over it in a meeting with the other two developers, then you may have a shot at convincing him of your approach.
Make sure you include that you've worked with this technology before. Elaborate on how you used it correctly, and no issues arised. Also, show him that the developer community around this tool highly encourages you to let the ORM do it's magic.
answered Sep 11 '13 at 16:04
aglassman
24615
add a comment |Â
up vote
2
down vote
You will need to lay out a good argument on paper of why using the ORM the way it is intended will be better. This needs to specify the immediate benefits, and the long term benefits. You also need to address every one of his concerns he has about letting the ORM do it the way it was intended to work. You need to put at ease his fears, this is why he is changing it. If you can write all of these things down in an organized fashion, and go over it in a meeting with the other two developers, then you may have a shot at convincing him of your approach.
Make sure you include that you've worked with this technology before. Elaborate on how you used it correctly, and no issues arised. Also, show him that the developer community around this tool highly encourages you to let the ORM do it's magic.
answered Sep 11 '13 at 16:04
aglassman
24615
add a comment |Â
up vote
2
down vote
up vote
2
down vote
You will need to lay out a good argument on paper of why using the ORM the way it is intended will be better. This needs to specify the immediate benefits, and the long term benefits. You also need to address every one of his concerns he has about letting the ORM do it the way it was intended to work. You need to put at ease his fears, this is why he is changing it. If you can write all of these things down in an organized fashion, and go over it in a meeting with the other two developers, then you may have a shot at convincing him of your approach.
Make sure you include that you've worked with this technology before. Elaborate on how you used it correctly, and no issues arised. Also, show him that the developer community around this tool highly encourages you to let the ORM do it's magic.
answered Sep 11 '13 at 16:04
aglassman
24615
You will need to lay out a good argument on paper of why using the ORM the way it is intended will be better. This needs to specify the immediate benefits, and the long term benefits. You also need to address every one of his concerns he has about letting the ORM do it the way it was intended to work. You need to put at ease his fears, this is why he is changing it. If you can write all of these things down in an organized fashion, and go over it in a meeting with the other two developers, then you may have a shot at convincing him of your approach.
Make sure you include that you've worked with this technology before. Elaborate on how you used it correctly, and no issues arised. Also, show him that the developer community around this tool highly encourages you to let the ORM do it's magic.
answered Sep 11 '13 at 16:04
aglassman
24615
answered Sep 11 '13 at 16:04
aglassman
24615
answered Sep 11 '13 at 16:04
aglassman
24615
answered Sep 11 '13 at 16:04
aglassman
24615
24615
add a comment |Â
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%2f14327%2fhow-do-i-correct-something-a-colleague-did-wrong-without-going-over-his-head%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
What is your position compared to the other 3 developers? If you are the team lead it is different than if you are their peer.
– IDrinkandIKnowThings
Sep 10 '13 at 14:06
I think that the question might be better if you present it as I think X dev B did Y how should I communicate that Y is the wrong way.
– IDrinkandIKnowThings
Sep 10 '13 at 14:16
You might find this answer worth reading. This question really reads like, "my colleague is an idiot."
– Elysian Fields♦
Sep 10 '13 at 14:23
@Chad, I'm not a team leader, I'm just a developer.
– Pedro Cordeiro
Sep 10 '13 at 14:37
@enderland, I don't know how you got that from my question. I just said he doesn't handle criticism well and is not experienced with the tool at hand.
– Pedro Cordeiro
Sep 10 '13 at 14:38