Mixing
How should I communicate serious programming flaws to someone so they do not take it personally?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
I am a developer with only a couple of years of experience, working in a small company of eight developers, on a Java project. Our team leader, also one of the managers, is older, and very productive, and says he has about fifteen years of experience in Java.
Last month, while we were discussing some source code modules he wrote, I noticed in the source code that one the classes overrode method equals(), but not method hashCode() - I am referring to the two methods declared in the very basic Java class Object. When I pointed this out to the team leader, in a very calm and polite manner, he denied that a class should override both methods. The issue would finish there, but I found it immoral to let such a flaw (bug) to hurt the product later.
A few days later, I approached him in person and in private and I quietly, without being disrespectful, explained to him about the issue, and used external references (such as Joshua Bloch's book 'Effective Java'). Well, he said he would look at it, and eventually he did. However, ever since, he gives me the cold shoulder.
Even worse, I recently saw a serious issue in the source code. Some classes he has written implement the Serializable interface, but the field serialVersionUID is not a fixed (constant) number. Instead it varies. I mean, we get a different number each time we run the application.
Again with the motivation of delivering a sane product, I would like to communicate this properly. But I do not know how to properly do so, without him taking it personally. You see, my previous approaches failed. How could I do so?
Any advice would be welcome.
Edit: The purpose of this question is to find effective, productive, polite, respectful, collaborative ways to communicate improvements over serious code issues, and not to question the authority or management decisions, made by peers, or even superiors.
software-industry communication company-culture
edited Mar 16 '16 at 1:07
Greenonline
151119
asked Mar 15 '16 at 6:47
pek
305
 |Â
show 15 more comments
up vote
4
down vote
favorite
I am a developer with only a couple of years of experience, working in a small company of eight developers, on a Java project. Our team leader, also one of the managers, is older, and very productive, and says he has about fifteen years of experience in Java.
Last month, while we were discussing some source code modules he wrote, I noticed in the source code that one the classes overrode method equals(), but not method hashCode() - I am referring to the two methods declared in the very basic Java class Object. When I pointed this out to the team leader, in a very calm and polite manner, he denied that a class should override both methods. The issue would finish there, but I found it immoral to let such a flaw (bug) to hurt the product later.
A few days later, I approached him in person and in private and I quietly, without being disrespectful, explained to him about the issue, and used external references (such as Joshua Bloch's book 'Effective Java'). Well, he said he would look at it, and eventually he did. However, ever since, he gives me the cold shoulder.
Even worse, I recently saw a serious issue in the source code. Some classes he has written implement the Serializable interface, but the field serialVersionUID is not a fixed (constant) number. Instead it varies. I mean, we get a different number each time we run the application.
Again with the motivation of delivering a sane product, I would like to communicate this properly. But I do not know how to properly do so, without him taking it personally. You see, my previous approaches failed. How could I do so?
Any advice would be welcome.
Edit: The purpose of this question is to find effective, productive, polite, respectful, collaborative ways to communicate improvements over serious code issues, and not to question the authority or management decisions, made by peers, or even superiors.
software-industry communication company-culture
edited Mar 16 '16 at 1:07
Greenonline
151119
asked Mar 15 '16 at 6:47
pek
305
9
What actual, rather than theoretical, problems are these issues causing in your code?
– Philip Kendall
Mar 15 '16 at 6:53
3
@Philip The problems described are those that may often not result in actual bugs, but if/when they do result in bugs they are usually difficult to fix. Even if that were not the case here, the question applies equally well to questions of code style and cleanliness; whether or not actual bugs have been identified is not relevant.
– Rob
Mar 15 '16 at 8:13
2
How long has your colleague been giving you the 'cold shoulder' for? It sounds like you were able to convince him, so you might not have been as unsuccessful as you think - it might just take a little time for his pride to recover.
– Rob
Mar 15 '16 at 8:21
5
"I noticed in the source code, that one the classes overrode method equals, but not method hashCode." -- if you want to effectively communicate to a programmer why something like this is bad, find instances of actual bugs in the code that can be directly traced back to this bad practice. Then you can definitively say "if we adopt practice X, bugs of this type will not occur."
– Brandin
Mar 15 '16 at 9:08
4
@pek Best would be to find an actual demonstrable bug, file it in the bug tracker, fix it, and then point out. Hey, I fixed bug #1234. If we make sure we always do X, bugs like this won't happen again. I recommend we make it part of the coding standard from now. The rest is up to the team lead really.
– Brandin
Mar 15 '16 at 9:30
 |Â
show 15 more comments
up vote
4
down vote
favorite
up vote
4
down vote
favorite
I am a developer with only a couple of years of experience, working in a small company of eight developers, on a Java project. Our team leader, also one of the managers, is older, and very productive, and says he has about fifteen years of experience in Java.
Last month, while we were discussing some source code modules he wrote, I noticed in the source code that one the classes overrode method equals(), but not method hashCode() - I am referring to the two methods declared in the very basic Java class Object. When I pointed this out to the team leader, in a very calm and polite manner, he denied that a class should override both methods. The issue would finish there, but I found it immoral to let such a flaw (bug) to hurt the product later.
A few days later, I approached him in person and in private and I quietly, without being disrespectful, explained to him about the issue, and used external references (such as Joshua Bloch's book 'Effective Java'). Well, he said he would look at it, and eventually he did. However, ever since, he gives me the cold shoulder.
Even worse, I recently saw a serious issue in the source code. Some classes he has written implement the Serializable interface, but the field serialVersionUID is not a fixed (constant) number. Instead it varies. I mean, we get a different number each time we run the application.
Again with the motivation of delivering a sane product, I would like to communicate this properly. But I do not know how to properly do so, without him taking it personally. You see, my previous approaches failed. How could I do so?
Any advice would be welcome.
Edit: The purpose of this question is to find effective, productive, polite, respectful, collaborative ways to communicate improvements over serious code issues, and not to question the authority or management decisions, made by peers, or even superiors.
software-industry communication company-culture
edited Mar 16 '16 at 1:07
Greenonline
151119
asked Mar 15 '16 at 6:47
pek
305
I am a developer with only a couple of years of experience, working in a small company of eight developers, on a Java project. Our team leader, also one of the managers, is older, and very productive, and says he has about fifteen years of experience in Java.
Last month, while we were discussing some source code modules he wrote, I noticed in the source code that one the classes overrode method equals(), but not method hashCode() - I am referring to the two methods declared in the very basic Java class Object. When I pointed this out to the team leader, in a very calm and polite manner, he denied that a class should override both methods. The issue would finish there, but I found it immoral to let such a flaw (bug) to hurt the product later.
A few days later, I approached him in person and in private and I quietly, without being disrespectful, explained to him about the issue, and used external references (such as Joshua Bloch's book 'Effective Java'). Well, he said he would look at it, and eventually he did. However, ever since, he gives me the cold shoulder.
Even worse, I recently saw a serious issue in the source code. Some classes he has written implement the Serializable interface, but the field serialVersionUID is not a fixed (constant) number. Instead it varies. I mean, we get a different number each time we run the application.
Again with the motivation of delivering a sane product, I would like to communicate this properly. But I do not know how to properly do so, without him taking it personally. You see, my previous approaches failed. How could I do so?
Any advice would be welcome.
Edit: The purpose of this question is to find effective, productive, polite, respectful, collaborative ways to communicate improvements over serious code issues, and not to question the authority or management decisions, made by peers, or even superiors.
software-industry communication company-culture
edited Mar 16 '16 at 1:07
Greenonline
151119
asked Mar 15 '16 at 6:47
pek
305
edited Mar 16 '16 at 1:07
Greenonline
151119
edited Mar 16 '16 at 1:07
Greenonline
151119
edited Mar 16 '16 at 1:07
Greenonline
151119
151119
asked Mar 15 '16 at 6:47
pek
305
asked Mar 15 '16 at 6:47
pek
305
asked Mar 15 '16 at 6:47
pek
305
305
9
What actual, rather than theoretical, problems are these issues causing in your code?
– Philip Kendall
Mar 15 '16 at 6:53
3
@Philip The problems described are those that may often not result in actual bugs, but if/when they do result in bugs they are usually difficult to fix. Even if that were not the case here, the question applies equally well to questions of code style and cleanliness; whether or not actual bugs have been identified is not relevant.
– Rob
Mar 15 '16 at 8:13
2
How long has your colleague been giving you the 'cold shoulder' for? It sounds like you were able to convince him, so you might not have been as unsuccessful as you think - it might just take a little time for his pride to recover.
– Rob
Mar 15 '16 at 8:21
5
"I noticed in the source code, that one the classes overrode method equals, but not method hashCode." -- if you want to effectively communicate to a programmer why something like this is bad, find instances of actual bugs in the code that can be directly traced back to this bad practice. Then you can definitively say "if we adopt practice X, bugs of this type will not occur."
– Brandin
Mar 15 '16 at 9:08
4
@pek Best would be to find an actual demonstrable bug, file it in the bug tracker, fix it, and then point out. Hey, I fixed bug #1234. If we make sure we always do X, bugs like this won't happen again. I recommend we make it part of the coding standard from now. The rest is up to the team lead really.
– Brandin
Mar 15 '16 at 9:30
 |Â
show 15 more comments
9
What actual, rather than theoretical, problems are these issues causing in your code?
– Philip Kendall
Mar 15 '16 at 6:53
3
@Philip The problems described are those that may often not result in actual bugs, but if/when they do result in bugs they are usually difficult to fix. Even if that were not the case here, the question applies equally well to questions of code style and cleanliness; whether or not actual bugs have been identified is not relevant.
– Rob
Mar 15 '16 at 8:13
2
How long has your colleague been giving you the 'cold shoulder' for? It sounds like you were able to convince him, so you might not have been as unsuccessful as you think - it might just take a little time for his pride to recover.
– Rob
Mar 15 '16 at 8:21
5
"I noticed in the source code, that one the classes overrode method equals, but not method hashCode." -- if you want to effectively communicate to a programmer why something like this is bad, find instances of actual bugs in the code that can be directly traced back to this bad practice. Then you can definitively say "if we adopt practice X, bugs of this type will not occur."
– Brandin
Mar 15 '16 at 9:08
4
@pek Best would be to find an actual demonstrable bug, file it in the bug tracker, fix it, and then point out. Hey, I fixed bug #1234. If we make sure we always do X, bugs like this won't happen again. I recommend we make it part of the coding standard from now. The rest is up to the team lead really.
– Brandin
Mar 15 '16 at 9:30
9
9
What actual, rather than theoretical, problems are these issues causing in your code?
– Philip Kendall
Mar 15 '16 at 6:53
What actual, rather than theoretical, problems are these issues causing in your code?
– Philip Kendall
Mar 15 '16 at 6:53
3
3
@Philip The problems described are those that may often not result in actual bugs, but if/when they do result in bugs they are usually difficult to fix. Even if that were not the case here, the question applies equally well to questions of code style and cleanliness; whether or not actual bugs have been identified is not relevant.
– Rob
Mar 15 '16 at 8:13
@Philip The problems described are those that may often not result in actual bugs, but if/when they do result in bugs they are usually difficult to fix. Even if that were not the case here, the question applies equally well to questions of code style and cleanliness; whether or not actual bugs have been identified is not relevant.
– Rob
Mar 15 '16 at 8:13
2
2
How long has your colleague been giving you the 'cold shoulder' for? It sounds like you were able to convince him, so you might not have been as unsuccessful as you think - it might just take a little time for his pride to recover.
– Rob
Mar 15 '16 at 8:21
How long has your colleague been giving you the 'cold shoulder' for? It sounds like you were able to convince him, so you might not have been as unsuccessful as you think - it might just take a little time for his pride to recover.
– Rob
Mar 15 '16 at 8:21
5
5
"I noticed in the source code, that one the classes overrode method equals, but not method hashCode." -- if you want to effectively communicate to a programmer why something like this is bad, find instances of actual bugs in the code that can be directly traced back to this bad practice. Then you can definitively say "if we adopt practice X, bugs of this type will not occur."
– Brandin
Mar 15 '16 at 9:08
"I noticed in the source code, that one the classes overrode method equals, but not method hashCode." -- if you want to effectively communicate to a programmer why something like this is bad, find instances of actual bugs in the code that can be directly traced back to this bad practice. Then you can definitively say "if we adopt practice X, bugs of this type will not occur."
– Brandin
Mar 15 '16 at 9:08
4
4
@pek Best would be to find an actual demonstrable bug, file it in the bug tracker, fix it, and then point out. Hey, I fixed bug #1234. If we make sure we always do X, bugs like this won't happen again. I recommend we make it part of the coding standard from now. The rest is up to the team lead really.
– Brandin
Mar 15 '16 at 9:30
@pek Best would be to find an actual demonstrable bug, file it in the bug tracker, fix it, and then point out. Hey, I fixed bug #1234. If we make sure we always do X, bugs like this won't happen again. I recommend we make it part of the coding standard from now. The rest is up to the team lead really.
– Brandin
Mar 15 '16 at 9:30
 |Â
show 15 more comments
4 Answers
4
active
oldest
votes
up vote
17
down vote
General reminder: it's always better to avoid a critical or lecturing tone. Either make it a simple observation ("you seem to have forgotten to implement hashcode here") or make it a question ("is there a reason you didn't implement hashcode?"). Let their response drive drive the why-it-matters discussion, if necessary, but start from the assumption that they know the principles and that the oddity was either a simple oversight/typo or had some rational reason behind it which can be discussed rather than beaten upon.
People listen better if you treat them with respect.
And remember, sometimes the misunderstanding is going to be yours. You'll embarrass yourself a lot less this way than if you make a more absolute or didactic statement.
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
suggest improvements |Â
up vote
14
down vote
Maybe looking at this from the other perspective might give you a better view.
I am a team leader and also a manager in a small company of eight developers. I have 15 years of experience programming in Java. I have one new person in my team who is much younger than me with only a couple of years of experience.
Last month, while we were discussing about some source code modules I wrote, he started to belittle my code. Even though he has far less experience than I do, he claimed to see bugs in code which was working completely fine. After a short argument it seemed as if I was able to explain this to him.
But unfortunately he just can't rest that matter. He keeps undermining my authority by demanding that we do everything by textbooks (such as Joshua Bloch's book 'Effective Java') even in those cases where it would just be a waste of our time and not result in a tangible benefit for our product. How can I get this junior developer to trust my experience?
It is hard as a junior to convince a senior to change their practices. Also, as a manager he has to maintain an aura of superiority to be able to lead effectively.
So when you want to improve the quality standards in your workplace without the authority to do so, lead by example. Do right what others do wrong and show that your way is better because it results in a better product in less time. When you point out errors in other peoples code, don't do so by nitpicking at the sourcecode files. Do so by presenting a reproducible defect in the product itself and a way to fix it by following best practices.
By the way, one of the most common occupational disease for programmers is an inflated ego. He might have one already, but you are starting to show symptoms of the early stages too.
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
1
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
suggest improvements |Â
up vote
3
down vote
A way to mitigate against this sort of problem is 'give and take' I've been successful with this strategy many times. People are more amenable to your suggestions and criticisms when it's two way. So I would ask questions and advice when I got a chance and take their answers seriously. (To be honest sometimes I already knew the answer, but you never know, I've also learnt some cool things that way as well.)
Eventually you build a rapport where you support each other and things go a lot better in many ways. And if he's got 15 years experience, I bet there is a lot he could tell you that's worth knowing.
I wouldn't worry about him and his cold shoulder, that is normal enough after what happened. In all likelihood he will have taken your input onboard and is being careful around you, and you probably have upset him a bit. But it's not a popularity contest, so unless he gets out of control over it, give him some space. Remain friendly and supportive and he'll come around.
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
suggest improvements |Â
up vote
-1
down vote
Super good question. I love learning but when someone harshes my mellow I feel like I should quit. I recommend reviewing your coworkers "coding style" and identify his strengths so he doesn't feel like all that time he spent learning was pointless. THEN identify OPPORTUNITIES. That way you display strengths going forward that are helping the company and also working on those "opportunities" that you have already identified. I lead teams by giving a 30-60-90 day timetable and then praise the tweaks where we capitalized on "opportunities". It works very well and is a fair way to identify leaders vs people who are not and should not be leaders.
answered Mar 15 '16 at 10:09
HotBreakfast
7
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
suggest improvements |Â
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();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
17
down vote
General reminder: it's always better to avoid a critical or lecturing tone. Either make it a simple observation ("you seem to have forgotten to implement hashcode here") or make it a question ("is there a reason you didn't implement hashcode?"). Let their response drive drive the why-it-matters discussion, if necessary, but start from the assumption that they know the principles and that the oddity was either a simple oversight/typo or had some rational reason behind it which can be discussed rather than beaten upon.
People listen better if you treat them with respect.
And remember, sometimes the misunderstanding is going to be yours. You'll embarrass yourself a lot less this way than if you make a more absolute or didactic statement.
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
suggest improvements |Â
up vote
17
down vote
General reminder: it's always better to avoid a critical or lecturing tone. Either make it a simple observation ("you seem to have forgotten to implement hashcode here") or make it a question ("is there a reason you didn't implement hashcode?"). Let their response drive drive the why-it-matters discussion, if necessary, but start from the assumption that they know the principles and that the oddity was either a simple oversight/typo or had some rational reason behind it which can be discussed rather than beaten upon.
People listen better if you treat them with respect.
And remember, sometimes the misunderstanding is going to be yours. You'll embarrass yourself a lot less this way than if you make a more absolute or didactic statement.
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
suggest improvements |Â
up vote
17
down vote
up vote
17
down vote
General reminder: it's always better to avoid a critical or lecturing tone. Either make it a simple observation ("you seem to have forgotten to implement hashcode here") or make it a question ("is there a reason you didn't implement hashcode?"). Let their response drive drive the why-it-matters discussion, if necessary, but start from the assumption that they know the principles and that the oddity was either a simple oversight/typo or had some rational reason behind it which can be discussed rather than beaten upon.
People listen better if you treat them with respect.
And remember, sometimes the misunderstanding is going to be yours. You'll embarrass yourself a lot less this way than if you make a more absolute or didactic statement.
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
General reminder: it's always better to avoid a critical or lecturing tone. Either make it a simple observation ("you seem to have forgotten to implement hashcode here") or make it a question ("is there a reason you didn't implement hashcode?"). Let their response drive drive the why-it-matters discussion, if necessary, but start from the assumption that they know the principles and that the oddity was either a simple oversight/typo or had some rational reason behind it which can be discussed rather than beaten upon.
People listen better if you treat them with respect.
And remember, sometimes the misunderstanding is going to be yours. You'll embarrass yourself a lot less this way than if you make a more absolute or didactic statement.
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
answered Mar 15 '16 at 9:54
keshlam
41.5k1267144
41.5k1267144
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
suggest improvements |Â
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
The question approach is very good!
– jwsc
Mar 15 '16 at 10:47
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
@keshlam True, you are right in the three topics you covered in your detailed answer. Especially, the first paragraph, the idea to follow a "question based approach", opens a totally brand new perpective into the topic, and into communication methods, more general. Really, thank you very much
– pek
Mar 15 '16 at 13:15
suggest improvements |Â
up vote
14
down vote
Maybe looking at this from the other perspective might give you a better view.
I am a team leader and also a manager in a small company of eight developers. I have 15 years of experience programming in Java. I have one new person in my team who is much younger than me with only a couple of years of experience.
Last month, while we were discussing about some source code modules I wrote, he started to belittle my code. Even though he has far less experience than I do, he claimed to see bugs in code which was working completely fine. After a short argument it seemed as if I was able to explain this to him.
But unfortunately he just can't rest that matter. He keeps undermining my authority by demanding that we do everything by textbooks (such as Joshua Bloch's book 'Effective Java') even in those cases where it would just be a waste of our time and not result in a tangible benefit for our product. How can I get this junior developer to trust my experience?
It is hard as a junior to convince a senior to change their practices. Also, as a manager he has to maintain an aura of superiority to be able to lead effectively.
So when you want to improve the quality standards in your workplace without the authority to do so, lead by example. Do right what others do wrong and show that your way is better because it results in a better product in less time. When you point out errors in other peoples code, don't do so by nitpicking at the sourcecode files. Do so by presenting a reproducible defect in the product itself and a way to fix it by following best practices.
By the way, one of the most common occupational disease for programmers is an inflated ego. He might have one already, but you are starting to show symptoms of the early stages too.
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
1
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
suggest improvements |Â
up vote
14
down vote
Maybe looking at this from the other perspective might give you a better view.
I am a team leader and also a manager in a small company of eight developers. I have 15 years of experience programming in Java. I have one new person in my team who is much younger than me with only a couple of years of experience.
Last month, while we were discussing about some source code modules I wrote, he started to belittle my code. Even though he has far less experience than I do, he claimed to see bugs in code which was working completely fine. After a short argument it seemed as if I was able to explain this to him.
But unfortunately he just can't rest that matter. He keeps undermining my authority by demanding that we do everything by textbooks (such as Joshua Bloch's book 'Effective Java') even in those cases where it would just be a waste of our time and not result in a tangible benefit for our product. How can I get this junior developer to trust my experience?
It is hard as a junior to convince a senior to change their practices. Also, as a manager he has to maintain an aura of superiority to be able to lead effectively.
So when you want to improve the quality standards in your workplace without the authority to do so, lead by example. Do right what others do wrong and show that your way is better because it results in a better product in less time. When you point out errors in other peoples code, don't do so by nitpicking at the sourcecode files. Do so by presenting a reproducible defect in the product itself and a way to fix it by following best practices.
By the way, one of the most common occupational disease for programmers is an inflated ego. He might have one already, but you are starting to show symptoms of the early stages too.
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
1
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
suggest improvements |Â
up vote
14
down vote
up vote
14
down vote
Maybe looking at this from the other perspective might give you a better view.
I am a team leader and also a manager in a small company of eight developers. I have 15 years of experience programming in Java. I have one new person in my team who is much younger than me with only a couple of years of experience.
Last month, while we were discussing about some source code modules I wrote, he started to belittle my code. Even though he has far less experience than I do, he claimed to see bugs in code which was working completely fine. After a short argument it seemed as if I was able to explain this to him.
But unfortunately he just can't rest that matter. He keeps undermining my authority by demanding that we do everything by textbooks (such as Joshua Bloch's book 'Effective Java') even in those cases where it would just be a waste of our time and not result in a tangible benefit for our product. How can I get this junior developer to trust my experience?
It is hard as a junior to convince a senior to change their practices. Also, as a manager he has to maintain an aura of superiority to be able to lead effectively.
So when you want to improve the quality standards in your workplace without the authority to do so, lead by example. Do right what others do wrong and show that your way is better because it results in a better product in less time. When you point out errors in other peoples code, don't do so by nitpicking at the sourcecode files. Do so by presenting a reproducible defect in the product itself and a way to fix it by following best practices.
By the way, one of the most common occupational disease for programmers is an inflated ego. He might have one already, but you are starting to show symptoms of the early stages too.
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
Maybe looking at this from the other perspective might give you a better view.
I am a team leader and also a manager in a small company of eight developers. I have 15 years of experience programming in Java. I have one new person in my team who is much younger than me with only a couple of years of experience.
Last month, while we were discussing about some source code modules I wrote, he started to belittle my code. Even though he has far less experience than I do, he claimed to see bugs in code which was working completely fine. After a short argument it seemed as if I was able to explain this to him.
But unfortunately he just can't rest that matter. He keeps undermining my authority by demanding that we do everything by textbooks (such as Joshua Bloch's book 'Effective Java') even in those cases where it would just be a waste of our time and not result in a tangible benefit for our product. How can I get this junior developer to trust my experience?
It is hard as a junior to convince a senior to change their practices. Also, as a manager he has to maintain an aura of superiority to be able to lead effectively.
So when you want to improve the quality standards in your workplace without the authority to do so, lead by example. Do right what others do wrong and show that your way is better because it results in a better product in less time. When you point out errors in other peoples code, don't do so by nitpicking at the sourcecode files. Do so by presenting a reproducible defect in the product itself and a way to fix it by following best practices.
By the way, one of the most common occupational disease for programmers is an inflated ego. He might have one already, but you are starting to show symptoms of the early stages too.
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
edited Mar 15 '16 at 10:40
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
answered Mar 15 '16 at 10:29
Philipp
20.3k34884
20.3k34884
1
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
suggest improvements |Â
1
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
1
1
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Thank for your response, it is great in the way it tries to put me into his shoes. About the storytelling part: I really hope that the first discussion was really not perceived as an argument, and the quality concerns were not really perceived as "undermining ones authority". If not, there has been a really huge misunderstanding. For the rest, I think your approach of "show by good example" and "show by test cases" is very practical, scientific, and can eventually help building a better product and perhaps relationships... so, yes, I like it. Really, thanks a lot
– pek
Mar 15 '16 at 13:20
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
Wow. Preach it, brotha.
– MealyPotatoes
Mar 16 '16 at 4:57
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
I am not a Java developer, but it seems quite possible that the senior developer here might have good reasons for doing things the way they were done. As (from in my own experience) not doing something the way you did it in school gives order-of-magnitude (or more) speed increase in a time-critical application... So why not start by simply asking why it was done this way? It's possible you might learn something.
– jamesqf
Mar 16 '16 at 19:44
suggest improvements |Â
up vote
3
down vote
A way to mitigate against this sort of problem is 'give and take' I've been successful with this strategy many times. People are more amenable to your suggestions and criticisms when it's two way. So I would ask questions and advice when I got a chance and take their answers seriously. (To be honest sometimes I already knew the answer, but you never know, I've also learnt some cool things that way as well.)
Eventually you build a rapport where you support each other and things go a lot better in many ways. And if he's got 15 years experience, I bet there is a lot he could tell you that's worth knowing.
I wouldn't worry about him and his cold shoulder, that is normal enough after what happened. In all likelihood he will have taken your input onboard and is being careful around you, and you probably have upset him a bit. But it's not a popularity contest, so unless he gets out of control over it, give him some space. Remain friendly and supportive and he'll come around.
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
suggest improvements |Â
up vote
3
down vote
A way to mitigate against this sort of problem is 'give and take' I've been successful with this strategy many times. People are more amenable to your suggestions and criticisms when it's two way. So I would ask questions and advice when I got a chance and take their answers seriously. (To be honest sometimes I already knew the answer, but you never know, I've also learnt some cool things that way as well.)
Eventually you build a rapport where you support each other and things go a lot better in many ways. And if he's got 15 years experience, I bet there is a lot he could tell you that's worth knowing.
I wouldn't worry about him and his cold shoulder, that is normal enough after what happened. In all likelihood he will have taken your input onboard and is being careful around you, and you probably have upset him a bit. But it's not a popularity contest, so unless he gets out of control over it, give him some space. Remain friendly and supportive and he'll come around.
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
suggest improvements |Â
up vote
3
down vote
up vote
3
down vote
A way to mitigate against this sort of problem is 'give and take' I've been successful with this strategy many times. People are more amenable to your suggestions and criticisms when it's two way. So I would ask questions and advice when I got a chance and take their answers seriously. (To be honest sometimes I already knew the answer, but you never know, I've also learnt some cool things that way as well.)
Eventually you build a rapport where you support each other and things go a lot better in many ways. And if he's got 15 years experience, I bet there is a lot he could tell you that's worth knowing.
I wouldn't worry about him and his cold shoulder, that is normal enough after what happened. In all likelihood he will have taken your input onboard and is being careful around you, and you probably have upset him a bit. But it's not a popularity contest, so unless he gets out of control over it, give him some space. Remain friendly and supportive and he'll come around.
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
A way to mitigate against this sort of problem is 'give and take' I've been successful with this strategy many times. People are more amenable to your suggestions and criticisms when it's two way. So I would ask questions and advice when I got a chance and take their answers seriously. (To be honest sometimes I already knew the answer, but you never know, I've also learnt some cool things that way as well.)
Eventually you build a rapport where you support each other and things go a lot better in many ways. And if he's got 15 years experience, I bet there is a lot he could tell you that's worth knowing.
I wouldn't worry about him and his cold shoulder, that is normal enough after what happened. In all likelihood he will have taken your input onboard and is being careful around you, and you probably have upset him a bit. But it's not a popularity contest, so unless he gets out of control over it, give him some space. Remain friendly and supportive and he'll come around.
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
edited Mar 15 '16 at 9:02
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
answered Mar 15 '16 at 8:56
Kilisi
94.6k50216376
94.6k50216376
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
suggest improvements |Â
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
Good point, good strategy! This may lead to a stronger bond (rapport) indeed. Thank you!
– pek
Mar 15 '16 at 9:20
suggest improvements |Â
up vote
-1
down vote
Super good question. I love learning but when someone harshes my mellow I feel like I should quit. I recommend reviewing your coworkers "coding style" and identify his strengths so he doesn't feel like all that time he spent learning was pointless. THEN identify OPPORTUNITIES. That way you display strengths going forward that are helping the company and also working on those "opportunities" that you have already identified. I lead teams by giving a 30-60-90 day timetable and then praise the tweaks where we capitalized on "opportunities". It works very well and is a fair way to identify leaders vs people who are not and should not be leaders.
answered Mar 15 '16 at 10:09
HotBreakfast
7
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
suggest improvements |Â
up vote
-1
down vote
Super good question. I love learning but when someone harshes my mellow I feel like I should quit. I recommend reviewing your coworkers "coding style" and identify his strengths so he doesn't feel like all that time he spent learning was pointless. THEN identify OPPORTUNITIES. That way you display strengths going forward that are helping the company and also working on those "opportunities" that you have already identified. I lead teams by giving a 30-60-90 day timetable and then praise the tweaks where we capitalized on "opportunities". It works very well and is a fair way to identify leaders vs people who are not and should not be leaders.
answered Mar 15 '16 at 10:09
HotBreakfast
7
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
suggest improvements |Â
up vote
-1
down vote
up vote
-1
down vote
Super good question. I love learning but when someone harshes my mellow I feel like I should quit. I recommend reviewing your coworkers "coding style" and identify his strengths so he doesn't feel like all that time he spent learning was pointless. THEN identify OPPORTUNITIES. That way you display strengths going forward that are helping the company and also working on those "opportunities" that you have already identified. I lead teams by giving a 30-60-90 day timetable and then praise the tweaks where we capitalized on "opportunities". It works very well and is a fair way to identify leaders vs people who are not and should not be leaders.
answered Mar 15 '16 at 10:09
HotBreakfast
7
Super good question. I love learning but when someone harshes my mellow I feel like I should quit. I recommend reviewing your coworkers "coding style" and identify his strengths so he doesn't feel like all that time he spent learning was pointless. THEN identify OPPORTUNITIES. That way you display strengths going forward that are helping the company and also working on those "opportunities" that you have already identified. I lead teams by giving a 30-60-90 day timetable and then praise the tweaks where we capitalized on "opportunities". It works very well and is a fair way to identify leaders vs people who are not and should not be leaders.
answered Mar 15 '16 at 10:09
HotBreakfast
7
answered Mar 15 '16 at 10:09
HotBreakfast
7
answered Mar 15 '16 at 10:09
HotBreakfast
7
answered Mar 15 '16 at 10:09
HotBreakfast
7
7
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
suggest improvements |Â
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Well, thank you for answering, but I am not sure I comprehend you. Just for making it clear from my part: I am not questioning ones leadership. Neither wish to take ones leadership role, either.
– pek
Mar 15 '16 at 13:29
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
Someone has to lead. I'm speaking from personal experience. I didn't mean to confuse you.
– HotBreakfast
Mar 21 '16 at 15:10
suggest improvements |Â
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%2f63646%2fhow-should-i-communicate-serious-programming-flaws-to-someone-so-they-do-not-tak%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
9
What actual, rather than theoretical, problems are these issues causing in your code?
– Philip Kendall
Mar 15 '16 at 6:53
3
@Philip The problems described are those that may often not result in actual bugs, but if/when they do result in bugs they are usually difficult to fix. Even if that were not the case here, the question applies equally well to questions of code style and cleanliness; whether or not actual bugs have been identified is not relevant.
– Rob
Mar 15 '16 at 8:13
2
How long has your colleague been giving you the 'cold shoulder' for? It sounds like you were able to convince him, so you might not have been as unsuccessful as you think - it might just take a little time for his pride to recover.
– Rob
Mar 15 '16 at 8:21
5
"I noticed in the source code, that one the classes overrode method equals, but not method hashCode." -- if you want to effectively communicate to a programmer why something like this is bad, find instances of actual bugs in the code that can be directly traced back to this bad practice. Then you can definitively say "if we adopt practice X, bugs of this type will not occur."
– Brandin
Mar 15 '16 at 9:08
4
@pek Best would be to find an actual demonstrable bug, file it in the bug tracker, fix it, and then point out. Hey, I fixed bug #1234. If we make sure we always do X, bugs like this won't happen again. I recommend we make it part of the coding standard from now. The rest is up to the team lead really.
– Brandin
Mar 15 '16 at 9:30